9628
|
1 |
32bpp and OpenTTD
|
|
2 |
=================
|
|
3 |
|
|
4 |
OpenTTD has 32bpp support. This means: OpenTTD still is 8bpp, but it has the
|
|
5 |
posibility to override the graphics with 32bpp. This means that it isn't a
|
|
6 |
replacement of grf or newgrf, but simply an addition. If you want to use 32bpp
|
|
7 |
graphics of a newgrf, you do need the newgrf itself too (with 8bpp graphics).
|
|
8 |
|
|
9 |
|
|
10 |
The Format
|
|
11 |
----------
|
|
12 |
|
|
13 |
32bpp images are stored in PNG. They should go in:
|
|
14 |
data/sprites/<grfname>/<SpriteID>.png
|
|
15 |
|
|
16 |
For example, a grfname would be 'openttd' (without .grf, lowercase), and the
|
|
17 |
SpriteID 3, to override the 3rd sprite in openttd.grf with a 32bpp version.
|
|
18 |
|
|
19 |
The format of this PNG can be almost anything, but we advise to use RGBA
|
|
20 |
format. Alpha-channel is fully supported.
|
|
21 |
|
|
22 |
As the core of OpenTTD is 8bpp, and because you of course want company colours
|
|
23 |
in your images, you will need to add a mask for every sprite that needs colour
|
|
24 |
remapping. The name is simular as above, only you have to put a 'm' behind the
|
|
25 |
SpriteID. This image should be a 8bpp palette image, where the palette is the
|
|
26 |
OpenTTD palette. Upon load of the PNG, the mask is loaded too, and overrides
|
|
27 |
the RGB (not the Alpha) of the original PNG image, and replacing it with a
|
|
28 |
8bpp color remapped and converted to 32bpp.
|
|
29 |
|
|
30 |
An other thing that OpenTTD needs in your png, is 2 tEXt chunks: x_offs and
|
|
31 |
y_offs. This to define the x- and y-offset, of course. Use the tool we supply
|
|
32 |
to add this information. Sadly enough most graphical editors trashes those
|
|
33 |
chunks upon save, so you have to readd it every time you save your image.
|
|
34 |
|
|
35 |
Your images should be the same as the grf, in size.
|
|
36 |
|