Sprite mode words are 32 bit values used to describe the format of the sprite data, i.e. the screen mode the sprite was created in. There are three basic formats supported by different versions of RISC OS:
Mode numbers are the only supported mode word format in versions of RISC OS prior to RISC OS 3.5.
If the mode number is one of an extension mode (i.e. a mode defined by a third-party module) then some operations on the sprite will only perform correctly if that mode (or a very similar one) is present on the host system.
RISC OS 3.5 extended the mode word format to the following:
wttt tyyy yyyy yyyy yyxx xxxx xxxx xxx1
Field | Contents |
---|---|
w (bit 31) | Wide mask flag |
t (bits 30-27) | Sprite type |
y (bits 26-14) | Vertical DPI |
x (bits 13-1) | Horizontal DPI |
Bit 0 must always contain the value ‘1’.
Note that many OS APIs will only accept a sprite mode word if the horizontal and vertical DPI fields contain DPI values that can be expressed as eigen values; i.e. 180 DPI (eigen value 0), 90 DPI (eigen value 1), 45 DPI (eigen value 2) or 22 or 23 DPI (eigen value 3).
Starting with RISC OS 5.21 a new sprite mode word format is supported, allowing for a much larger number of sprite types, at the cost of less DPI combinations.
w111 1ttt tttt 0000 ffff ffff yyxx 0001
Field | Contents |
---|---|
w (bit 31) | Wide mask flag |
t (bits 26-20) | Sprite type |
f (bits 15-8) | Contains bits 15-8 of the Mode Flags |
y (bits 7-6) | Y eigen value (0=180 DPI, 1=90 DPI, etc.) |
x (bits 5-4) | X eigen value |
Bits 30-27, 19-16 and 3-0 must always contain the fixed pattern &78000001.
The above rules are essentially just an expanded form of the set of rules presented for decoding mode specifiers, as many APIs which accept mode words actually accept all types of mode specifier. However it’s important to remember that pointers to mode selector blocks are not valid sprite mode words, as there is no way the pointer or the block can be saved out to a sprite file. Therefore if you are writing a public API which only accepts sprite mode words, you may want to implement a check for mode selectors and throw an error if one is passed in by accident.
Some APIs may also accept pointers to sprite areas – these can be distinguished from pointers to mode selector blocks by the fact that bit 0 of the first word of a sprite area will always be zero, whereas bit 0 of the first word of a mode selector block will always be one.
Also note that even if it looks like a RISC OS 3.5 or RISC OS 5 sprite mode word, other factors may mean that it’s a completely invalid mode word (e.g. DPI values of zero in a RISC OS 3.5 mode word, or the fixed bits of a RISC OS 5 mode word containing an invalid pattern).
Type | Description |
---|---|
0 | Invalid (used to identify mode numbers) |
1 | 1bpp palletised |
2 | 2bpp palletised |
3 | 4bpp palletised |
4 | 8bpp palletised |
5 | 16bpp 1:5:5:5 TBGR |
6 | 32bpp 8:8:8:8 TBGR |
7 | 32bpp CMYK |
8 | 24bpp |
9 | JPEG data |
10 | 16bpp 5:6:5 TBGR |
11-14 | Reserved |
15 | Invalid (used to identify RISC OS 5 sprite mode words) |
Types 0-15 are as above. All types are modified by the mode flags as appropriate.
Type | Description |
---|---|
16 | 16bpp 4:4:4:4 |
17 | 4:2:0 YCbCr |
18 | 4:2:2 YCbCr |
19-127 | Reserved |
See Format Of Sprite for details of how the sprite mode word affects the format of the sprite mask.