Difference between revisions of "RealSprites"

From GRFSpecs
Jump to navigationJump to search
m (Beautify wiki markup)
(Added frosch's explanation on values for the compression byte)
Line 1: Line 1:
 
== Introduction ==
 
== Introduction ==
 
The sprites that the user actually sees.
 
 
 
   
 
Real sprites are the graphical part of .grf files; they are what the user actually sees in-game.
 
Real sprites are the graphical part of .grf files; they are what the user actually sees in-game.
Line 15: Line 11:
 
{|
 
{|
 
!Element!![[GRFActionsDetailed|Size]]!!Description
 
!Element!![[GRFActionsDetailed|Size]]!!Description
 
 
|-
 
|-
 
|<Sprite-number>||dec||A sequential sprite number
 
|<Sprite-number>||dec||A sequential sprite number
 
 
|-
 
|-
 
|<filename>||string*||The name of the .pcx file in which the sprite will be found
 
|<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
 
|<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
 
|<ypos>||dec||The y position of the upper-left corner of the sprite in the file
 
 
|-
 
|-
 
|<compression>||B||The "compression"; see below
 
|<compression>||B||The "compression"; see below
 
 
|-
 
|-
 
|<ysize>||dec||The y size of the sprite
 
|<ysize>||dec||The y size of the sprite
 
 
|-
 
|-
 
|<xsize>||dec||The x 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)
 
|<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)
 
|<yrel>||dec||The y position of the upper-left corner of the sprite, relative to the "center" (usually negative)
Line 74: Line 61:
 
{|
 
{|
 
!bit!!value!!meaning
 
!bit!!value!!meaning
 
 
|-
 
|-
|0||1||Color index 0 is transparent (should be '''always''' set; ignored if bit 3 is set)
+
|0||1||Color index 0 is transparent (should '''always''' be set; ignored if bit 3 is set)
 
 
|-
 
|-
 
|1||2||Store compressed sprite in memory
 
|1||2||Store compressed sprite in memory
 
 
|-
 
|-
 
|3||8||Sprite is in chunked data format (aka "tile compression")
 
|3||8||Sprite is in chunked data format (aka "tile compression")
 
 
|-
 
|-
 
|6||40||Sprite should not be cropped. (obeyed by GRFCodec r1604 and later)
 
|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).
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.
 
  +
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)
   
The most common values for the compression are 01 and 09. 03 is useful for large sprites that are infrequently used, as it reduces memory usage at the cost of slower drawing speed. It is generally a bad idea to use any other value, as that may cause problems. FF is an especially bad idea.
+
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 ===
 
=== xrel and yrel ===

Revision as of 15:32, 15 June 2011

Introduction

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

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* 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 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)

* Unlike strings in pseudo-sprites, this string should not have a terminating "00" and should not be placed in quotes.

Description

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.

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.

Andrex's [1] can often be helpful for setting these four values.

WARNING: NFOEditor is replete with bugs, limitations, &c.;: You MUST specify absolute paths, and paths must be delimited by backslashes (decode with grfcodec 0.9.5); comments MUST NOT contain "*"; and sprite numbers MUST be correct. Also, moving too far outside the size of the .pcx file will cause NFOEditor to crash, so save early and often.

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, 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 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.

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.