Difference between revisions of "RealSprites"

From GRFSpecs
Jump to navigationJump to search
(→‎Type: Note that OpenTTD does not actually require 8bpp first.)
 
(24 intermediate revisions by 7 users not shown)
Line 1: Line 1:
  +
== Introduction ==
   
  +
Real sprites are the graphical part of .grf files; they are what the user actually sees in-game.
'''''Sprites that actually get drawn on the screen'''''
 
   
  +
There are two distinctly different ways to write real sprites, depending on the info version you use. TTDPatch and OpenTTD until version 1.2 only understand [[Version_numbers#GRF_container_version|GRF container version 1]] resp. [[Version_numbers#NFO_version|info version 7]].
=Real Sprites=
 
   
  +
== Info version 7 ==
The sprites that the user actually sees.
 
  +
Available in {{ottdp||}}
   
  +
=== Syntax ===
{maketoc}
 
   
  +
A real sprite has the following format:
-=Introduction=-
 
   
  +
<Sprite-number> <filename> <xpos> <ypos> <compression> <ysize> <xsize> <xrel> <yrel>
Real sprites are the business part of most GRF files; they are what the user actually sees in-game.
 
   
  +
{|
-=Format=-
 
  +
!Element!![[GRFActionsDetailed|Size]]!!Description
  +
|-
  +
|<Sprite-number>||dec||A sequential sprite number
  +
|-
  +
|<filename>||string<ref>Unlike strings in pseudo-sprites, this string should not have a terminating "00" and should not be placed in quotes.</ref>||The name of the .pcx or .png 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 upper-left corner of the sprite, relative to the "center" (usually negative)
  +
|-
  +
|<yrel>||dec||The y position of the upper-left corner of the sprite, relative to the "center" (usually negative)
  +
|}
   
  +
<references />
A real sprite has the following format:
 
   
  +
==== filename ====
<pre>-+&lt;Sprite-number&gt; &lt;filename&gt; &lt;xpos&gt; &lt;ypos&gt; &lt;compression&gt; &lt;ysize&gt; &lt;xsize&gt; &lt;xrel&gt; &lt;yrel&gt;+-</pre>
 
   
  +
This specifies the name and path of the .pcx file. The path may be specified one of two ways:
||'''Element'''|[[GRFActionsDetailed|'''Size''']]|'''Description'''
 
  +
# 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.
&lt;Sprite-number&gt;|dec|A sequential sprite number
 
   
  +
==== xpos, ypos, ysize, and xsize ====
&lt;filename&gt;|string*|The name of the PCX file in which the sprite will be found
 
   
  +
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.
&lt;xpos&gt;|dec|The x position of the upper-left corner of the sprite in the file
 
   
  +
Also, no sprite may contain zero pixels; ysize and xsize must both be at least 1.
&lt;ypos&gt;|dec|The y position of the upper-left corner of the sprite in the file
 
   
  +
Note: there is a bug in grfcodec 0.9.7 and earlier that prevents them from properly encoding a sprite with a smaller ypos value than any earlier sprite. The best way to circumvent this bug is to upgrade to the newest version.
&lt;compression&gt;|B|The &quot;compression&quot;; see below
 
   
  +
==== compression ====
&lt;ysize&gt;|dec|The y size of the sprite
 
   
  +
Unlike the other numbers, the compression is a hexadecimal bit-field. Currently, the following bits are supported:
&lt;xsize&gt;|dec|The x size of the sprite
 
   
  +
{|
&lt;xrel&gt;|dec|The x position of the center of the sprite, relative to the lower-right corner (usually negative)
 
  +
!bit!!value!!meaning
  +
|-
  +
|0||1||Color index 0 is transparent (should '''always''' be set; ignored if bit 3 is set)
  +
|-
  +
|1||2||Store compressed sprite in memory
  +
|-
  +
|3||8||Sprite is in chunked data format (aka "tile compression")
  +
|-
  +
|6||40||Sprite should not be cropped. (obeyed by GRFCodec r1604 and later)
  +
|}
   
  +
The only valid values for compression are 00, 01, 02, 03 and 09 (except the special flag 0x40 that is only important for grfcodec).
&lt;yrel&gt;|dec|The y position of the center of the sprite, relative to the lower-right corner (usually negative)||
 
  +
Values 00 - 03 are handled the same by OpenTTD. If you don't care about the difference for TTDPatch either use 01 or 09.
   
  +
The best value depends on which and how many pixels are transparent: If the non-transparent pixels are arranged to bigger blocks along the pixellines (like for ground tiles or diagonal views of vehicles) use 09 (chunked data format). If there are no transparent pixels or transparent pixels and non-transparent alternate a lot along the pixellines use 01.
<nowiki><nowiki>*</nowiki></nowiki> Unlike strings in pseudo-sprites, this string should not have a terminating &quot;00&quot; and should not be placed in quotes.
 
   
  +
If you are interested in improving drawing for TTDPatch (does not make a difference for OpenTTD): You can use 00 resp. 02 if there are NO transparent pixels at all. 00 is slightly quicker than 01. 02 is a valid value but does not make a lot of sense.
-=Filling in the Terms=-
 
   
  +
You can use 02 resp. 03 to store the sprite compressed in memory. Drawing will be slower, but the sprite needs less memory while it is not used. Useful for big sprites which are hardly used (like the newpaper "tycoon of the century" at game end)
===filename===
 
   
  +
It is generally a bad idea to use any other value, as that may cause problems. FF is an especially bad idea.
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)
 
   
  +
==== xrel and yrel ====
For most purposes, relative paths are preferred, since NFO files with relative paths are more portable than NFO files with absolute paths.
 
   
  +
These two numbers will probably become the bane of your existence.
===xpos, ypos, ysize, and xsize===
 
   
  +
TTD stores a single point for every sprite. xrel and yrel specify how far right and down (respectively) to go from the TTD point to the upper-left hand corner of the sprite.
These are pretty easy to set, as long as you remember that the order is &nbsp;X, Y, Y, X, and not X, Y, X, Y.
 
   
  +
Halving xsize and ysize and negating the results produces a decent starting point for these values, and further adjustments may be done manually, e.g within OpenTTD by activating the [http://wiki.openttd.org/NewGRF_Debugging NewGRF developer tools] and using the sprite aligner or in TTDPatch 2.0.1 alpha 69 and later with the [http://www.tt-wiki.net/wiki/GRFAuthorHelperWindow GRFAuthorHelperWindow].
Also, no sprite may contain zero pixels; ysize and xsize must both be at least 1.
 
   
  +
==== Ranges ====
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 &quot;current&quot; and &quot;other&quot;) 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.
 
   
  +
The ranges for the four numbers after the compression are as follows:
Andrex's [http://www.divxland.org/ttd/files/nfoeditor.zip|NFOEditor] can often be helpful for setting these four values (but not for ensuring that ypos is non-decreasing).
 
   
  +
ysize: 1..255
'''WARNING:''' NFOEditor is replete with bugs, limitations, &amp;c.;: You MUST specify absolute paths (decode with grfcodec 0.9.5), comments MUST NOT contain &quot;*&quot;, 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.
 
   
  +
xsize: 1..65535
===compression===
 
   
  +
xrel: -32768..32767
Unlike the other numbers, the compression is a hexadecimal bit-field. It is not fully understood, but the known bits are as follows:
 
   
  +
yrel: -32768..32767
||bit|value|meaning
 
   
  +
ysize*xsize may not exceed 65535.
0|1|Must be set.
 
   
  +
==== Other notes ====
1|2|Store compressed size internally.
 
   
  +
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 reduces the size of the .grf file when compared to replacing them with one-pixel sprites (but not when compared to splitting the action 1 and making the second one define only one sprite), but does not save real-sprite slots. If TTD ever attempts to draw one of these sprites, it will, at best, crash.
3|8|Sprite is in chunked data format (aka &quot;tile compression&quot;)||
 
   
  +
== Info version 32 ==
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.
 
  +
Available in {{ottdp|1.2|ottdrev=r23890}}
   
  +
=== Syntax ===
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.
 
   
  +
<Sprite-number> <filename> 8bpp <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> normal <flags>
===xrel and yrel===
 
   
  +
<Sprite-number> <filename> 8bpp <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> normal <flags>
These two numbers will probably become the bane of your existence.
 
  +
| <filename> 8bpp <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> <zoomlevel> <flags>
  +
| <filename> 32bpp <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> <zoomlevel> <flags>
  +
| <filename> mask <xpos> <pos>
  +
...
  +
==== Sprite-number ====
  +
This is a sequential sprite number, maximum value is 2**32
  +
==== Filename ====
  +
The graphics filename which the real sprite is found in
  +
==== Type ====
  +
Sprite type.
   
  +
The type of the 1st sprite must always be 8bpp and of 'normal' zoom level (see below). Subsequent lines for alternative sprites can be of any type and zoom level.
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.
 
   
  +
Note that OpenTTD does not enforce this requirement and is able to load and display 32bpp-only sprites. However if there is no 8bpp sprite and the player is using an 8bpp mode then the fallback "red question mark" sprite will be used instead.
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]].
 
   
  +
Available types are:
===Ranges===
 
  +
{|
  +
!Name!!Description
  +
|-
  +
|8bpp || Sprite with 8 bit colour depth in one of the accepted palettes
  +
|-
  +
|32bpp|| True colour sprite with 32 bit colour depth
  +
|-
  +
|mask || If used, this type must follow a '32bpp' entry immediately. Itself it is a 8bpp paletted sprite of the exact same size of the preceeding 32bpp sprite. It defines the colour translation for this preceeding 32bpp sprite: Palette entry 0 means to draw the 32bpp as usual, the other colours define a replacement colour where then the preceeding 32bpp sprite is interpreted as giving intensity and alpha channel information.
  +
|}
   
  +
==== xpos, ypos ====
The ranges for the four numbers after the compression are as follows:
 
  +
The coordinates of the upper left corner of the sprite within the graphics file.
  +
==== xsize, ysize ====
  +
The width and height of the sprite within the graphics file. The valid value range is from 1 to 65535 for both.
  +
==== xrel, yrel ====
  +
The position of the upper-left corner of the sprite, relative to the "center" (usually negative). The valid value range is from -32768 to 32767.
  +
==== zoom level ====
  +
OpenTTD supports a number of zoom levels. For 'normal' zoom level a tile has a width of 64 pixels and a height of 31 (see coordinates). Available zoom levels are:
  +
{|
  +
!name !!zoom level!!Grid size !!Groundsprite with zig-zag border!!Groundsprite with smooth border!!xrel, yrel with smooth border!!Description
  +
|-
  +
|zo8 || 8x out || 8 x 4 || 8 x 3 || 8 x 3 || -3, 0
  +
|rowspan="3"| zoomed-out
  +
|-
  +
|zo4 || 4x out || 16 x 8 || 16 x 7 || 16 x 7 || -7, 0
  +
|-
  +
|zo2 || 2x out || 32 x 16 || 32 x 15 || 32 x 15 || -15, 0
  +
|- style="background:lightblue"
  +
|normal|| (normal) || 64 x 32 || 64 x 31 || 64 x 31 || -31, 0 || The standard
  +
|-
  +
|zi2 || 2x in || 128 x 64 || 128 x 62 || 128 x 63 || -62, -1
  +
|rowspan="2"| zoomed-in
  +
|-
  +
|zi4 || 4x in || 256 x 128 || 256 x 124 || 256 x 127 || -124, -2
  +
|-
  +
|zi(X) || (X)x in || (X*32) x (X*16) || (X*32) x floor(X*15) || (X*32) x (X*16-1) || ceil(X*-31), ceil(X*-1/2) || Generalisation
  +
|}
   
  +
Hint:
ysize: 1..255
 
  +
If you have a normal-zoom sprite with (xrel, yel), the 2x zoom-in sprite will have (2*xrel, 2*yrel-1), and the 4x zoom-in sprite will have (4*xrel, 4*yrel-2).
   
  +
These conversions are implied by how OpenTTD draws foundations, in particular half-tile foundations. At 1x zoom the vertical slope edge is between two pixels, and the horizontal slope edge is in the middle of a pixel. That is: The middle of the tiles (green line) needs to line up, the top of the tiles (red line) then does not line up:
xsize: 1..65535
 
  +
[[File:Groundsprites_4x.png]]
   
  +
==== Flags ====
xrel: -32768..32767
 
  +
Flags allow to describe certain special treatment of the sprites:
  +
{|
  +
!name!!Description
  +
|-
  +
|nocrop || Disallow grfcodec to crop transparent pixels off the sprite to the minimum size possible without loosing information. Use this when the actual sprite size matters (i.e. when child sprites rely on it).
  +
|-
  +
|chunked || Store the sprite compressed. It saves space for 'diagonal' sprites with lots of transparency like diagonal views of vehicles.
  +
|}
   
yrel: -32768..32767
 
   
ysize*xsize may not exceed 65535.
 
   
  +
== Transparency and glass effect ==
===Other notes===
 
   
  +
Transparency and glass effects can be achieved by means of [[RecolorSprites]]
It is a common practice, in action 1 blocks, to use the pseudosprite &quot;-1 * 1 00&quot; 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=-
 
   
  +
== 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.
 
  +
  +
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]].
 
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.
+
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.
  +
  +
Info version 32:
  +
3 sprites/58_8.png 8bpp 0 0 128 64 -63 -23 normal nocrop
  +
| sprites/58_x2_8.png 8bpp 0 0 256 128 -127 -46 zi2 chunked nocrop // comment
  +
| sprites/58_x2_32.png 32bpp 0 0 256 128 -127 -46 zi2 chunked nocrop
  +
| sprites/58_x2_32m.png mask 0 0

Latest revision as of 18:22, 12 December 2023

Introduction

Real sprites are the graphical part of .grf files; they are what the user actually sees in-game.

There are two distinctly different ways to write real sprites, depending on the info version you use. TTDPatch and OpenTTD until version 1.2 only understand GRF container version 1 resp. info version 7.

Info version 7

Available in Supported by OpenTTD Supported by TTDPatch

Syntax

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[1] The name of the .pcx or .png 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 upper-left corner of the sprite, relative to the "center" (usually negative)
<yrel> dec The y position of the upper-left corner of the sprite, relative to the "center" (usually negative)
  1. Unlike strings in pseudo-sprites, this string should not have a terminating "00" and should not be placed in quotes.

filename

This specifies the name and path of the .pcx file. The path may be specified one of two ways:

  1. An absolute path. (eg C:\GRF\sprites\filename.pcx)
  2. 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.

Note: there is a bug in grfcodec 0.9.7 and earlier that prevents them from properly encoding a sprite with a smaller ypos value than any earlier sprite. The best way to circumvent this bug is to upgrade to the newest version.

compression

Unlike the other numbers, the compression is a hexadecimal bit-field. Currently, the following bits are supported:

bit value meaning
0 1 Color index 0 is transparent (should always be set; ignored if bit 3 is set)
1 2 Store compressed sprite in memory
3 8 Sprite is in chunked data format (aka "tile compression")
6 40 Sprite should not be cropped. (obeyed by GRFCodec r1604 and later)

The only valid values for compression are 00, 01, 02, 03 and 09 (except the special flag 0x40 that is only important for grfcodec). Values 00 - 03 are handled the same by OpenTTD. If you don't care about the difference for TTDPatch either use 01 or 09.

The best value depends on which and how many pixels are transparent: If the non-transparent pixels are arranged to bigger blocks along the pixellines (like for ground tiles or diagonal views of vehicles) use 09 (chunked data format). If there are no transparent pixels or transparent pixels and non-transparent alternate a lot along the pixellines use 01.

If you are interested in improving drawing for TTDPatch (does not make a difference for OpenTTD): You can use 00 resp. 02 if there are NO transparent pixels at all. 00 is slightly quicker than 01. 02 is a valid value but does not make a lot of sense.

You can use 02 resp. 03 to store the sprite compressed in memory. Drawing will be slower, but the sprite needs less memory while it is not used. Useful for big sprites which are hardly used (like the newpaper "tycoon of the century" at game end)

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. xrel and yrel specify how far right and down (respectively) to go from the TTD point to the upper-left 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, e.g within OpenTTD by activating the NewGRF developer tools and using the sprite aligner 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 reduces the size of the .grf file when compared to replacing them with one-pixel sprites (but not when compared to splitting the action 1 and making the second one define only one sprite), but does not save real-sprite slots. If TTD ever attempts to draw one of these sprites, it will, at best, crash.

Info version 32

Available in Supported by OpenTTD 1.2 (r23890)1.2 Not supported by TTDPatch

Syntax

<Sprite-number> <filename> 8bpp <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> normal <flags>
 <Sprite-number> <filename> 8bpp  <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> normal      <flags>
 |               <filename> 8bpp  <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> <zoomlevel> <flags>
 |               <filename> 32bpp <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> <zoomlevel> <flags>
 |               <filename> mask  <xpos> <pos>
                 ...

Sprite-number

This is a sequential sprite number, maximum value is 2**32

Filename

The graphics filename which the real sprite is found in

Type

Sprite type.

The type of the 1st sprite must always be 8bpp and of 'normal' zoom level (see below). Subsequent lines for alternative sprites can be of any type and zoom level.

Note that OpenTTD does not enforce this requirement and is able to load and display 32bpp-only sprites. However if there is no 8bpp sprite and the player is using an 8bpp mode then the fallback "red question mark" sprite will be used instead.

Available types are:

Name Description
8bpp Sprite with 8 bit colour depth in one of the accepted palettes
32bpp True colour sprite with 32 bit colour depth
mask If used, this type must follow a '32bpp' entry immediately. Itself it is a 8bpp paletted sprite of the exact same size of the preceeding 32bpp sprite. It defines the colour translation for this preceeding 32bpp sprite: Palette entry 0 means to draw the 32bpp as usual, the other colours define a replacement colour where then the preceeding 32bpp sprite is interpreted as giving intensity and alpha channel information.

xpos, ypos

The coordinates of the upper left corner of the sprite within the graphics file.

xsize, ysize

The width and height of the sprite within the graphics file. The valid value range is from 1 to 65535 for both.

xrel, yrel

The position of the upper-left corner of the sprite, relative to the "center" (usually negative). The valid value range is from -32768 to 32767.

zoom level

OpenTTD supports a number of zoom levels. For 'normal' zoom level a tile has a width of 64 pixels and a height of 31 (see coordinates). Available zoom levels are:

name zoom level Grid size Groundsprite with zig-zag border Groundsprite with smooth border xrel, yrel with smooth border Description
zo8 8x out 8 x 4 8 x 3 8 x 3 -3, 0 zoomed-out
zo4 4x out 16 x 8 16 x 7 16 x 7 -7, 0
zo2 2x out 32 x 16 32 x 15 32 x 15 -15, 0
normal (normal) 64 x 32 64 x 31 64 x 31 -31, 0 The standard
zi2 2x in 128 x 64 128 x 62 128 x 63 -62, -1 zoomed-in
zi4 4x in 256 x 128 256 x 124 256 x 127 -124, -2
zi(X) (X)x in (X*32) x (X*16) (X*32) x floor(X*15) (X*32) x (X*16-1) ceil(X*-31), ceil(X*-1/2) Generalisation

Hint: If you have a normal-zoom sprite with (xrel, yel), the 2x zoom-in sprite will have (2*xrel, 2*yrel-1), and the 4x zoom-in sprite will have (4*xrel, 4*yrel-2).

These conversions are implied by how OpenTTD draws foundations, in particular half-tile foundations. At 1x zoom the vertical slope edge is between two pixels, and the horizontal slope edge is in the middle of a pixel. That is: The middle of the tiles (green line) needs to line up, the top of the tiles (red line) then does not line up: Groundsprites 4x.png

Flags

Flags allow to describe certain special treatment of the sprites:

name Description
nocrop Disallow grfcodec to crop transparent pixels off the sprite to the minimum size possible without loosing information. Use this when the actual sprite size matters (i.e. when child sprites rely on it).
chunked Store the sprite compressed. It saves space for 'diagonal' sprites with lots of transparency like diagonal views of vehicles.


Transparency and glass effect

Transparency and glass effects can be achieved by means of RecolorSprites


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.

Info version 32:

   3 sprites/58_8.png 8bpp 0 0 128 64 -63 -23 normal nocrop
   | sprites/58_x2_8.png 8bpp 0 0 256 128 -127 -46 zi2 chunked nocrop // comment
   | sprites/58_x2_32.png 32bpp 0 0 256 128 -127 -46 zi2 chunked nocrop 
   | sprites/58_x2_32m.png mask 0 0