Sprite Mode bpp

Hi all,

I’m trying to get my head around how to determine the number of bits per pixel for each Sprite Mode.

I’m starting on trying to work out the bpp for numbered Screen Modes here: https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes

I was looking at the memory for each mode in the table. Using the formula

memory_in_bytes = (x_pixels * y_pixels * log_base_2(num_of_colours)) / 8

and most of the modes calculate correctly, but some don’t.
For example, mode 2 in the table says it uses 40KB but

(160 * 256 * 4) / 8 = 20 480B = 20KB

while mode 16 is said to use 132KB and

(1056 * 256 * 4) / 8 = 135 168B = 132KB.

So either there are mistakes in the table or some modes are using more bits per pixel than required. Can anyone help shed some light on what’s going on? Or have I just made a fundamental misunderstanding?

Many thanks,
Simon

MODE 2 works on the Beeb and that only had 32KiB RAM installed, so 40KiB just wouldn’t work.

Yup, it is definitely 20KiB for MODE 2 on the Beeb – http://beebwiki.mdfs.net/MODE
However every source I can see for MODE 2 on RISC OS quotes 40K… Must be doing something differently.

Edit: RISC OS itself agrees with the table – it is 40KiB. https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/s/vdu/vdumodes?rev=4.5.2.13#l1135

Mode 2 is a compatibility mode. On the original BBC it was 160*256, which would need 20k, and the hardware stretched out the pixels horizontally to give the right aspect ratio. On RISC OS, the hardware couldn’t do this, so instead each pixel is duplicated by the OS, so it’s actually 320*256 pixels, which would need 40k. The size in OS units is 1280×1024 regardless. Modes 5 and 10 are similar.

so it’s actually 320*256 pixels, which would need 40k.

…only a screendump of a MODE 2 sprite, which claims to be 160×256, also says it is 40K in size (and yes, the file is 40K)…

Thanks for the replies. So am I right in thinking that compatibility modes effectively fake non-square pixels by rendering them as two adjacent square pixels?

For the moment I’ve just made a simple table that maps the mode numbers to the mode’s bpp value (only for ‘Mode Numbers’ 0 – 53 so far). I’ve yet to finish working on decoding the more recent Sprite types.

I’ve had a bit of a look through the documentation here. I don’t know if such a thing exists but is there any reference to how the various colours for the various modes are mapped to RRGGBB values. For example, in the photo above, some of the ToolSprites are in Mode 12 and have 16 colours, but what colours are they exactly? Does something like that exist, or should I just spend some time in an emulator taking colour samples of the various modes?

Basically, I want to try and write a Windows application that will let me view and edit Sprites files.

Thanks again,
Simon

some of the ToolSprites are in Mode 12 and have 16 colours, but what colours are they exactly?

That depends on whether or not the sprite has a palette.

And note, the Wimp tools 256 colour palettes on RISC OS 5 can be…weird. Looks like gibberish in !Paint – https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Desktop/Wimp/Doc/ToolTables?rev=1.1;content-type=text%2Fplain

Thanks for the replies. So am I right in thinking that compatibility modes effectively fake non-square pixels by rendering them as two adjacent square pixels?

It’s only a handful of modes which make use of the software pixel doubling trick. Most other modes which have rectangular pixels (e.g. mode 0, 640×256) assume that the hardware will be displaying the mode correctly.

The key to working out the pixel aspect ratio is to look at the ratio eigen values – e.g. mode 0 is EX1 EY2 and so each pixel is 1 unit wide and 2 units tall. If your software is running on RISC OS then you’d use OS_ReadModeVariable to get the eigen values (it will accept a sprite mode word as input, so it will work with both numbered and “new-style” sprites). But if you’re writing something for another OS then you’d have to have a hardcoded list for the numbered modes (for new-style sprite mode words the information is encoded in the mode word itself).

You can also use the mode variables to detect which modes are using the software pixel doubling trick (see the notes on the mode variables page).

I’ve had a bit of a look through the documentation here. I don’t know if such a thing exists but is there any reference to how the various colours for the various modes are mapped to RRGGBB values. For example, in the photo above, some of the ToolSprites are in Mode 12 and have 16 colours, but what colours are they exactly? Does something like that exist, or should I just spend some time in an emulator taking colour samples of the various modes?

As Rick says, that will depend quite a bit on whether the sprites have palettes. If a sprite has a palette then that will be used. If there isn’t a palette then the behaviour can vary quite a bit – for most cases (e.g. sprites designed to be used in the Wimp) it would be best to assume that the sprite is to be used with the default Wimp palette for the mode (it’s probably easiest to grab those palettes from an emulator).