A Sprite Table Binary file has no header and contains an array of 52-byte sprite records. Multi-byte fields use little-endian byte ordering.
Each sprite record defines a single sprite. It associates a unique name with a sub-image inside a texture map.
|char||32||name||Unique name of the sprite|
|char||8||texture||MAP texture file to use for the sprite|
|unsigned short||2||u||Position of the left edge of the sprite rectangle in pixels/texels|
|unsigned short||2||v||Position of the top edge of the sprite rectangle in pixels/texels|
|unsigned short||2||width||Width of the sprite rectangle in pixels/texels|
|unsigned short||2||height||Height of the sprite rectangle in pixels/texels|
|unsigned long||4||flags||Extra data associated with the sprite (see below)|
The flags property is a bitfield. The four least significant bits contain a colorization index. The rest is unused.
Each colorization index corresponds to a predefined color ramp.
Software rendering tacks a non-zero index onto the end of the texture name after an underscore. A white smoke puff sprite with "smoke" texture and color index 0 would use smoke.map, while a black smoke puff sprite with "smoke" texture and color index 3 would use smoke_3.map.
Hardware rendering uses the index to look up a texture modulate color from a table compiled into the game executable. Color indices A through F are white since their color ramps cannot be reduced to single texture modulate color. Effects using those color ramps have the color pre-baked into the texture instead.