Sprite Mode Word

Programmer's Reference Manuals

» Sprite Mode Word

Sprite Mode Word

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

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.

Note that it is illegal to use a mode number between 128 and 255 in a sprite mode word (i.e. a mode number with the shadow bit set).

RISC OS 3.5 sprite mode words

RISC OS 3.5 extended the mode word format to the following:

wttt tyyy yyyy yyyy yyxx xxxx xxxx xxx1

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).

RISC OS 5 sprite mode words

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

Bits 27-30, 16-19 and 0-3 must always contain the fixed pattern &78000001.

Determining mode word format

• Is the mode word an unsigned value less than 256?
  • Yes: It’s a mode number
• Is the bottom bit zero?
  • Yes: It’s a pointer to a Mode Selector Block.
• Are bits 27-30 all set to 1?
  • Yes: It’s a RISC OS 5 style sprite mode word
  • No: It’s a RISC OS 3.5 style sprite mode word

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).

RISC OS 3.5 sprite types

Note that for sprite type 4, the values returned by the kernel are for a sprite with a 64 entry palette instead of a full 256 entry palette.

RISC OS 5 sprite types

Types 0-15 are as above.

When reading the mode flags, bits 8-15 of the sprite mode word directly specify bits 8-15 of the mode flags. The other flags (e.g. bit 7) are as specified in the tables above.

Handling of unknown sprite types

On RISC OS 3.5 and above, attempting to use OS_ReadModeVariable to read the details of an unknown or unsupported sprite type will generally result in the kernel acting as if it was given a type 6 (i.e. 32bpp) sprite mode word. By comparing the values returned by the kernel against the expected values for a given mode word, this can be used as a method of determining if the kernel/OS supports that sprite type.

Mask types

See Format Of Sprite for details of how the sprite mode word affects the format of the sprite mask.

See also

• Screen Modes
• Mode Flags
• Mode Variable Numbers
• Mode Selector Block
• Mode Specifier
• Format Of Sprite

Other languages documentation

Français