RealSprites
Sprites that actually get drawn on the screen
Real Sprites
The sprites that the user actually sees.
{maketoc}
-=Introduction=-
Real sprites are the business part of most GRF files; they are what the user actually sees in-game.
-=Format=-
A real sprite has the following format:
-+<Sprite-number> <filename> <xpos> <ypos> <compression> <ysize> <xsize> <xrel> <yrel>+-
||Element|Size|Description
<Sprite-number>|dec|A sequential sprite number
<filename>|string*|The name of the PCX file in which the sprite will be found
<xpos>|dec|The x position of the upper-left corner of the sprite in the file
<ypos>|dec|The y position of the upper-left corner of the sprite in the file
<compression>|B|The "compression"; see below
<ysize>|dec|The y size of the sprite
<xsize>|dec|The x size of the sprite
<xrel>|dec|The x position of the center of the sprite, relative to the lower-right corner (usually negative)
<yrel>|dec|The y position of the center of the sprite, relative to the lower-right corner (usually negative)||
<nowiki>*</nowiki> Unlike strings in pseudo-sprites, this string should not have a terminating "00" and should not be placed in quotes.
-=Filling in the Terms=-
filename
This specifies the name and path of the PCX file. The path may be specified one of two ways:
- An absolute path. (eg C:\GRF\sprites\filename.pcx)
- A relative path; these are specified relative to the location of the GRF file. (eg sprites\filename.pcx)
For most purposes, relative paths are preferred, since NFO files with relative paths are more portable than NFO files with absolute paths.
xpos, ypos, ysize, and xsize
These are pretty easy to set, as long as you remember that the order is X, Y, Y, X, and not X, Y, X, Y.
Also, no sprite may contain zero pixels; ysize and xsize must both be at least 1.
There is a bug in grfcodec that prevents it from properly encoding sprites that have a smaller ypos than any previous sprite. The best way to circumvent this bug is to make a copy of your PCX, and switch from the current PCX to the other PCX (thus swapping "current" and "other") every time ypos needs to decrease. Switching more often than required will make the encoding slightly slower, but is often far easier than switching only when necessary.
Andrex's [1] can often be helpful for setting these four values (but not for ensuring that ypos is non-decreasing).
WARNING: NFOEditor is replete with bugs, limitations, &c.;: You MUST specify absolute paths (decode with grfcodec 0.9.5), comments MUST NOT contain "*", and sprite numbers MUST be correct. Also, moving to far outside the size of the PCX will cause NFOEditor to crash, so save early and often.
compression
Unlike the other numbers, the compression is a hexadecimal bit-field. It is not fully understood, but the known bits are as follows:
||bit|value|meaning
0|1|Must be set.
1|2|Store compressed size internally.
3|8|Sprite is in chunked data format (aka "tile compression")||
The chunked data format is designed to compress tiles and diagonal views of vehicles; things with lots of transparency around the edges, and a contiguous block of non-transparent pixels in the middle. Using the chunked data format may provide advantages in drawing speed.
The most common values for the compression are 01 and 09. 03 and 0B are also used, but more rarely. It is generally a bad idea to use any other value, as that may cause problems. FF is an especially bad idea.
xrel and yrel
These two numbers will probably become the bane of your existence.
TTD stores a single point for every sprite. These two numbers specify how far left and up (respectively) to go from the TTD point to the lower-right hand corner of the sprite.
Halving xsize and ysize and negating the results produces a decent starting point for these values, and further adjustments may be done manually, with NFOEditor, or (in TTDPatch 2.0.1 alpha 69 and later) with the GRFAuthorHelperWindow.
Ranges
The ranges for the four numbers after the compression are as follows:
ysize: 1..255
xsize: 1..65535
xrel: -32768..32767
yrel: -32768..32767
ysize*xsize may not exceed 65535.
Other notes
It is a common practice, in action 1 blocks, to use the pseudosprite "-1 * 1 00" to take the place of a real sprite that will never be used. The most common use is for vehicle sets that will only be used in the purchase window. This saves a real-sprite space, but if TTD ever attempts to draw one of these sprites, it will likely crash.
-=Example=-
The best way to see real sprites is to decode one of TTD's standard GRF files. With very few exceptions, all sprites in those files are real sprites; the few that are not are RecolorSprites.
Example real sprites can also be found at the bottom of Action1 or ActionA.
Those sprites use absolute paths. Removing the C:\TTD\ part of each filename would work just as well, assuming you want the grf file to appear in C:\TTD.