RecolorSprites

From GRFSpecs
Revision as of 06:33, 5 January 2006 by dmccoy (talk)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Changing how other sprites are drawn

Recolor Sprites

Changing how other sprites are drawn

-=Introduction=-

Recolor sprites are psedosprites used to recolor other sprites, most often to apply company colors.

-=Format=-

A recolor sprite has the following format:

 -+<Sprite-number> * 257 00 <recolor-table>+-

||Element|Size|Description

<Sprite-number>|dec|A sequential sprite number

257|dec|The total number of bytes used in this action, always 257

00|B|literal 00

<recolor-table>|256*B|See below||

-=Filling in the Terms=-

00

At first glance, it is easy to confuse a recolor sprite with an action 0, most often for trains. Attempting to read the recolor sprite as an action 0 will usually reveal that there are far too many bytes. Another clue is that recolor sprites are always 257 bytes long.

The correct method to distinguish recolor sprites and action 0s is to note that recolor sprites can only appear in an Action5 or ActionA block, and action 0s can only appear outside such a block.

recolor-table

A 256-byte recolor table. When a pixel of $COLOR appears in a real-sprite, the byte at that offset specifies the color to be drawn.

Note that the offsets and bytes are different depending on whether the GRF is being loaded in TTD DOS or TTD Win. If you create a grf that contains recolor sprites, you may find it necessary to maintain two separate versions, or use an Action7 that checks variable 83 to guard the introducing action 5/A and the recolor sprite(s).

-=Usage=-

Recolor sprites are applied in one of two ways.

Non transparently
Each pixel in the sprite is looked up in the recolor table, and then the color specified at that offset is drawn on the screen. (Unless, of course, the resultant color is 00 (transparent blue), in which case nothing is drawn.)
Transparently
For each sprite pixel that is not transparent blue, the current (on-screen) color of the pixel at the location where the sprite pixel would be drawn is looked up in the recolor table, and then redrawn in the new color. I am unclear on the result when the recolor lookup returns transparent blue. Either nothing could happen, or bad things could happen. Other than is-transparent-blue/not-transparent-blue, the actual colors of the pixels in a sprite that is drawn transparently are meaningless.