PalettesAndCoordinates

From GRFSpecs
Revision as of 14:11, 14 June 2015 by Juzza1 (talk | contribs) (Showing Windows palette first could imply it is preferred - the opposite is true)
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

Palette files for a number of graphics programmes are available on the DevZone

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. Do use the DOS palette as it contains some additional colours and is easier to work with (all grays in one line).

Dospal.png Windowspal.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 pink colours like the ones marked "WinAPI" in the Windows palette. The Pure White at the bottom right of each palette is a palette colour, but you shouldn't use it in graphics; instead use the "almost white" from index 0x0F instead (colour code #FCFCFC). Use pure white for the background of your sprite sheet; GRFCodec and NML will issue a warning if a sprite containes pure white pixels. This warning is useful as it lets you know that the code referencing a sprite has the wrong position or size defined, but not so useful if your sprite actually contains pure white pixels.

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 pseudo-3D or 2.5D engine, which uses an isometric projection to display graphics on a 2D screen. The graphics engine uses so-called "bounding boxes" for each sprite, which are 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.

For all other sprites, the reference point is the furthest corner of the box, at its lowest X, Y and Z coordinates, i.e. the lower northernmost corner. In the image above, it is indicated by the crossing point of the blue lines. The xofs and yofs work from this point, instead of the center of the box as for vehicles.