PalettesAndCoordinates

From GRFSpecs
Revision as of 09:28, 17 June 2011 by George (talk | contribs) (fixed layout)
Jump to navigationJump to search

Palettes

Since TTD is a palette-based game, you have to be careful that the graphics program you use can deal with that properly. Also, TTD uses some palette entries for palette cycling to do some colour-animation, don't use these as regular colours. These entries are often called "action colours".

Below is an explanation by Oskar Eisemuth of the various colour ranges in the DOS and Windows palettes. Both palettes work similarly, but some of the colours are in different places. If unsure which palette to use, use the DOS palette as it contains a handful of additional colours over the windows palette.

Windowspal.png Dospal.png

Info on the image: The colors you can use normally are marked in green. The colors which have special purposes/are color cycles are marked yellow. Don't use the red marked colors.

The colours in the "company" range are often (but not always) changed to the current player colours. In some instances, they may be changed to colours specified by the .grf file, or random colours, or not changed at all.

Here is a list, provided by George, of the shades of player colours that will be used:

Playercolours.png

The "Company 2" range is normally not a special colour range, but since TTDPatch 2.0.1 alpha 67 it is possible to activate it as a second company colour for vehicles and town houses.

The palette cycling ranges listed are the water cycle (used for the blinking dots in the water), the block cycle, fire cycle, exchange red (better called crossing red; used for the flashing crossing lights), and the yellow cycle (used for lights in the runway of the large airport).

The following table presents more detailed info on differences between DOS and Windows colours and colour indices:

TTD Palettes.png

Coordinates

TTD internally uses a 3D engine, which then uses an isometric projection to display graphics on a 2D screen. The 3D engine uses so-called "bounding boxes" for each sprite, which are then sorted by the sprite sorter to get drawn in (what it thinks is) the right order.

To get a certain sprite drawn at the right place, it needs to have a proper bounding box (which is provided by the game for the most part), and the correct 2D offsets, here called "xofs" and "yofs" (see RealSprites for more information). The following picture by Oskar Eisemuth should help in figuring out how the 3D and 2D coordinates relate to each other:

Coordinates3d.png

For 3D coordinates, X goes from top right to bottom left, Y goes from top left to bottom right, and Z (height) from down to up. For 2D coordinates, X goes from left to right, and Y from top to bottom. Usually, the top side of the screen is referred to as "north", and thus "east", "south" and "west" are the right, bottom and left side of the screen.

For vehicles, the center of the bounding box (shown with a red dot in the yellow boxframe) is the reference point from which the xofs and yofs are counted. This means that in most cases, xofs and yofs need to be negative to get the sprite to fit on the box. Normally, as indicated above, this means xofs is approximately the negative value of half the sprite width, and yofs is approximately the negative value of half the sprite height.