Format Of Sprite

Programmer's Reference Manuals

» Format Of Sprite Area

» Format Of Sprite

Format Of Sprite

Sprites have a fixed size-header followed by a varying amount of data.

Header format

Sprite headers are 44 bytes long, with the following format.

All offsets are in bytes, relative to the start of the sprite header. If the sprite has no mask, the mask offset should be set to the same value as the image offset. If the sprite is the last sprite in the area, the offset to the next sprite must be set to the first byte after this sprite (i.e. to the total size of the sprite).

If this is a new format sprite (i.e. the mode word does not contain a mode number), the first bit used (word 6) must be zero. This is recommended for all sprites.

Palette data

If a sprite has a palette, the palette data immediately follows the sprite header. Each palette entry is two words long, allowing for flashing colours to be stored. Colours are stored in the standard &BBGGRR00 format.

Because the palette is stored immediately after the header, the presence and size of the palette can be determined by examining words 8 and 9 of the sprite header:

palette_entries = (min(offset_to_image,offset_to_mask)-44)/8

If the palette length is not a multiple of 8 the palette should be ignored. This is reserved for future expansion.

Note that 256 colour sprites that are designed to be VIDC1 compatible may only have 64 or 16 entry palettes instead of the full 256 entries.

Although SpriteExtend and ColourTrans do not use palettes attached to ‘deep colour’ sprites (>256 colours) some third party software can make use of such palettes.

Image data

Each row of image data is word-aligned. The byte length/stride of the rows can be easily determined from the sprite width value of the sprite header. However to correctly calculate the pixel width, the bits per pixel of the sprite mode must be known. Pixel width can be calculated as follows:

pixel_width = (word_width_minus_one*32 + right_bit + 1 - left_bit) / bpp

Although each row is word aligned, the first pixel of each row may not start on a word boundary. Use word 6 of the sprite header to determine which bit of the word constitutes the first bit of the image. This is known as ‘left-hand wastage’.

For a sprite to be considered valid, the first used bit and last used bit (plus one) must be multiples of the sprite bits per pixel, i.e. sprite data must begin and end on a pixel boundary.

Both image and mask data is stored top-down, left-to-right. I.e. the first row is the topmost row of the sprite, and the first pixel of a row is from the leftmost column of the sprite.

Mask data

For old format sprites (those where the mode specifies a numbered mode), each mask pixel is at the same BPP as the image pixels. However the OS only treats the mask as a binary on/off value (0=invisible pixel, non-zero=visible). Words 6 and 7 of the header must be used to determine where the valid mask pixels start and stop within the mask data.

For new format sprites, the mask width is typically 1bpp (0=invisible, 1=visible). However if the ‘wide mask’ bit of the mode word is set then an 8bpp mask is used, with the mask treated as an alpha channel to allow for smooth blending with the background (0=0% alpha, 255=100% alpha). Note that wide masks are not supported for sprite type 0 (i.e. mode numbers). The first valid mask pixel will always start at bit 0 of the mask data. The end of the last valid mask pixel (and the length/stride of the mask rows) must be calculated manually, based around the pixel width of the sprite and the BPP of the mask.

As with sprites, mask rows are always a multiple of 4 bytes in length.

Additional notes

Image and mask data may appear in any order.

SpriteOps that modify the byte size of the sprite (such as adding rows or creating a palette) require that the “offset to next sprite” is the actual length of the sprite. This is the recommended format.

See also

• Format Of Sprite Area
• Sprite Mode Word