.png sprite loading removed from OpenTTD

[emaluzer]

I got all the way to the end of all the steps with Knuckles help....When I type ./grfcodec -f -e -g2 grf_32bpp.nfo . i recieve this error:
Encoding in temporary file grf_32bpp.new
Error: mask sprite not preceded by 32bpp sprite.
While reading sprite:7

How do I fix this? I havent added any new pics or anything...just straight 32bpp mega pack nightly from march 2012.

[GeekToo]

And how does the info for sprite 7 in the nfo look?:
Should be something like:

Code: Select all

7 empty.pcx  8bpp 0 0   1   1    0    0 normal
    | 4582_z1.png 32bpp 0 0 128 134  -64  -71    zi2 chunked
    | 4582_z1m.png  mask 0 0                          
    | 4582_z0.png 32bpp 0 0 258 268 -125 -142    zi4 chunked
    | 4582_z0m.png  mask 0 0                          
    | 4582.png 32bpp 0 0  64  67  -32  -36 normal chunked
    | 4582m.png  mask 0 0         

Judging by the error message I'd guess you miss one of the 32bpp lines.

[emaluzer]

Ill check when I get home.....quick question tho....if it doesnt look like that could I possibly just copy what you typed and paste it into the nfo file?

[GeekToo]

You can copy everything you want, but it would only work if you have the exact same set of pngs in the directory when executing the script as I did. Otherwise wrong sprites would appear.

Much better is to try to understand what is wrong; if you don't find it, post your sprite nr 7 section of your .nfo.

[GeekToo]

Does the colour displayed in-game depend on the value of the mask colour's index (but not the actual colour this represents in the palette) or does it depend on the actual colour (i.e. on both the index and the palette used)?

The GRF itself only stores the colour indices which are interpreted using the fixed, built-in TTD DOS palette. Thus in the source mask file only the indices are relevant, but nml and grfcodec are supposed to tell you if the palette in the PNG doesn't match the OTTD palette.

For the second point, the recolour algorithm in trunk (1.2) is different than the one in the ez-zoom patch, because that one was very complicated and expensive. For each pixel, trunk will calculate the brightness from the RGB values (which is simply max(R,G,B)) and use it to modulate the colour corresponding to the mask colour index (brightness == 64 means no change, 128 means double brightness and 32 half and so on). There's some trickery involved to avoid numeric overflow, but that's the basics. The result is similar to the ez recolour, but not identical.

-- Michael Lutz

There have been a couple of recolour algorithms in the EZ-patch, and the last one, developed by Szvengar is indeed much too expensive (I mean, using floats in the blitter, get real). I already started some optimizing, but got occupied by real life, and I won't finish now EZ is in trunk.
The trunk algorithm is a nice compromise between simplicity and looks, and I honestly think the devs did great there. In some cases, the EZ-patch recolour did look much better, but the EZ-patch recolour also fails miserably when distinguishing between colours of the same hue, but with different brightness/value (like white and gray). For a patch that is kind of OK, for trunk it is not.
Main difference is that the EZ-patch did not take into account any of the brightness value of the mask, so using mask value 196 or 201 would result in the same pixel colour, only the 32bpp source sprite would determine the brightness.

As said, the trunk algorithm is simpler, and it fails in showing hue gradients, which are used frequently by 3Dsoftware renderers. Result looks a bit flatter, but absolutely acceptable, and endlessly better than the previoud versions of recolour in trunk, where the pixels would be completely replaced by mask colour, making it effectively 8bpp.

The trunk algorithm also takes into account the brightness of the masks, which result in some suboptimal result when using the mask files of the EZ-patch. Those mask files really need rework for trunk. In fact, I took a look at the mask files in the last nighly megapack, and they are a mess. Really, using dithering, wrong palettes, water colours for company colours etc. Several of the already produced mask files are simply unusable for the trunk algorithm. We need to work on that before even thinking of submitting any of the sprites with an accompanying mask t in a base set. The mess also makes automating the conversion hard. I may have just bad luck, grabbing a wrong nightly megapack, but we need to take a good look at that in the conversion process to newgrf.

[emaluzer]

this is what my sprite 7 reads:
7 empty.pcx 8bpp 0 0 1 1 0 0 normal
//!!Could not read xrel from apparent real sprite.
// | 4582_z1.png 32bpp 0 0 128 134 zi2 chunked
| 4582_z1m.png mask 0 0
//!!Could not read xrel from apparent real sprite.
// | 4582_z0.png 32bpp 0 0 258 268 zi4 chunked
| 4582_z0m.png mask 0 0
//!!Could not read xrel from apparent real sprite.
// | 4582.png 32bpp 0 0 64 67 normal chunked
| 4582m.png mask 0 0

what do I need to change?

[emaluzer]

most of the sprites say this:
/!!Could not read xrel from apparent real sprite.

is this normal? if not what may have caused this?

[emaluzer]

I followed Knuckles tutorial with the step by step. The first time I used the "updated create.txt" script he gave the link for that gave me
the error posted above. When I ran ./grfcodec -f -e -g2 grf_32bpp.nfo . i got the error
So I decided to use the original create.txt from Rubidium.
That worked until I ran ./grfcodec -f -e -g2 grf_32bpp.nfo . then I got this error:

Code: Select all

./grfcodec -f -e -g2 grf_32bpp.nfo .
Encoding in temporary file grf_32bpp.new
Error: mask sprite not preceded by 32bpp sprite.
	While reading sprite:2985

I opened the .nfo file and heres what it says: (partial, after sprite 3037 it seems to go back to normal)

Code: Select all

2985 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   837_z1.png 32bpp 0 0 103  59  zi2            
    | 837_z1m.png  mask 0 0                         
 2986 * 5	 0A 01 01 \w836
 2987 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   836_z1.png 32bpp 0 0 103  59  zi2            
    | 836_z1m.png  mask 0 0                         
 2988 * 5	 0A 01 01 \w835
 2989 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   835_z1.png 32bpp 0 0 103  59  zi2            
    | 835_z1m.png  mask 0 0                         
 2990 * 5	 0A 01 01 \w834
 2991 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   834_z1.png 32bpp 0 0 103  59  zi2            
    | 834_z1m.png  mask 0 0                         
 2992 * 5	 0A 01 01 \w833
 2993 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   833_z1.png 32bpp 0 0 103  59  zi2            
    | 833_z1m.png  mask 0 0                         
 2994 * 5	 0A 01 01 \w832
 2995 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   832_z1.png 32bpp 0 0 103  59  zi2            
    | 832_z1m.png  mask 0 0                         
 2996 * 5	 0A 01 01 \w831
 2997 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   831_z1.png 32bpp 0 0 103  59  zi2            
    | 831_z1m.png  mask 0 0                         
 2998 * 5	 0A 01 01 \w830
 2999 empty.pcx  8bpp 0 0   1   1    0    0 normal
    | 830_z1.png 32bpp 0 0 103  59   39   60    zi2
    | 830_z1m.png  mask 0 0                         
 3000 * 5	 0A 01 01 \w829
 3001 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   829_z1.png 32bpp 0 0 103  59  zi2            
    | 829_z1m.png  mask 0 0                         
 3002 * 5	 0A 01 01 \w828
 3003 empty.pcx  8bpp 0 0   1   1    0    0 normal
    | 828_z1.png 32bpp 0 0 103  59   39   60    zi2
    | 828_z1m.png  mask 0 0                         
 3004 * 5	 0A 01 01 \w827
 3005 empty.pcx  8bpp 0 0   1   1    0    0 normal
    | 827_z1.png 32bpp 0 0 103  59   39   60    zi2
    | 827_z1m.png  mask 0 0                         
 3006 * 5	 0A 01 01 \w826
 3007 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   826_z1.png 32bpp 0 0 103  59  zi2            
    | 826_z1m.png  mask 0 0                         
 3008 * 5	 0A 01 01 \w825
 3009 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   825_z1.png 32bpp 0 0 103  59  zi2            
    | 825_z1m.png  mask 0 0                         
 3010 * 5	 0A 01 01 \w824
 3011 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   824_z1.png 32bpp 0 0 103  59  zi2            
    | 824_z1m.png  mask 0 0                         
 3012 * 5	 0A 01 01 \w823
 3013 empty.pcx  8bpp 0 0   1   1    0    0 normal
    | 823_z1.png 32bpp 0 0 103  59   39   60    zi2
    | 823_z1m.png  mask 0 0                         
 3014 * 5	 0A 01 01 \w822
 3015 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   822_z1.png 32bpp 0 0 103  59  zi2            
    | 822_z1m.png  mask 0 0                         
 3016 * 5	 0A 01 01 \w821
 3017 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   821_z1.png 32bpp 0 0 103  59  zi2            
    | 821_z1m.png  mask 0 0                         
 3018 * 5	 0A 01 01 \w820
 3019 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   820_z1.png 32bpp 0 0 103  59  zi2            
    | 820_z1m.png  mask 0 0                         
 3020 * 5	 0A 01 01 \w819
 3021 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   819_z1.png 32bpp 0 0 103  59  zi2            
    | 819_z1m.png  mask 0 0                         
 3022 * 5	 0A 01 01 \w818
 3023 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   818_z1.png 32bpp 0 0 103  59  zi2            
    | 818_z1m.png  mask 0 0                         
 3024 * 5	 0A 01 01 \w817
 3025 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   817_z1.png 32bpp 0 0 103  59  zi2            
    | 817_z1m.png  mask 0 0                         
 3026 * 5	 0A 01 01 \w816
 3027 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   816_z1.png 32bpp 0 0 103  59  zi2            
    | 816_z1m.png  mask 0 0                         
 3028 * 5	 0A 01 01 \w815
 3029 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   815_z1.png 32bpp 0 0 103  59  zi2            
    | 815_z1m.png  mask 0 0                         
 3030 * 5	 0A 01 01 \w814
 3031 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   814_z1.png 32bpp 0 0 103  59  zi2            
    | 814_z1m.png  mask 0 0                         
 3032 * 5	 0A 01 01 \w813
 3033 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   813_z1.png 32bpp 0 0 103  59  zi2            
    | 813_z1m.png  mask 0 0                         
 3034 * 5	 0A 01 01 \w812
 3035 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   812_z1.png 32bpp 0 0 103  59  zi2            
    | 812_z1m.png  mask 0 0                         
 3036 * 5	 0A 01 01 \w811
 3037 empty.pcx  8bpp 0 0   1   1    0    0 normal
//!!Could not read xrel from apparent real sprite.
// |   811_z1.png 32bpp 0 0 103  59  zi2            
    | 811_z1m.png  mask 0 0                         
 3038 * 5	 0A 01 01 \w810 

edit: I just removed those png files from the folder and I got it to compile (they were just the face files) Why the didnt work...or what i can do to get them to work is beyond me if anyone could help.

Also after using the graphics the mouse arrow has disappeared.....making it nearly impossible to click anything...if I go off the screen the windows arrow appears then i can guess and click till i click something. Any clues?

[emaluzer]

I feel like a goof....
I found out why i was having probs....
I accidentally have been using the megapack-dev. files......switched to the regular and it worked perfectly!

[knuckles88]

For each pixel, trunk will calculate the brightness from the RGB values (which is simply max(R,G,B)) and use it to modulate the colour corresponding to the mask colour index (brightness == 64 means no change, 128 means double brightness and 32 half and so on). There's some trickery involved to avoid numeric overflow, but that's the basics.

Main difference is that the EZ-patch did not take into account any of the brightness value of the mask, so using mask value 196 or 201 would result in the same pixel colour, only the 32bpp source sprite would determine the brightness.

[...]

The trunk algorithm also takes into account the brightness of the masks, which result in some suboptimal result when using the mask files of the EZ-patch. Those mask files really need rework for trunk. In fact, I took a look at the mask files in the last nighly megapack, and they are a mess. Really, using dithering, wrong palettes, water colours for company colours etc. Several of the already produced mask files are simply unusable for the trunk algorithm. We need to work on that before even thinking of submitting any of the sprites with an accompanying mask t in a base set. The mess also makes automating the conversion hard. I may have just bad luck, grabbing a wrong nightly megapack, but we need to take a good look at that in the conversion process to newgrf.

I'm still confused about the specifics here. It seems that brightness (approximated as max(R,G,B)) is important, but which brightness? The brightness of the 32bpp image pixel, or of the 8bpp mask (which is apparently interpreted as though the OpenTTD DOS palette has been applied)? Or some combination?

If I'm reading this correctly, hue of some arbitrary company-coloured pixel in-game has nothing to do with the hue of the pixel in the original image, and is purely determined by the company colour applied. The brightness of the in-game pixel is determined by a combination of the brightness of the company colour applied and the "brightness" (=max(R,G,B)) of the corresponding pixel in the original image (plus also a contribution from the mask?), and the saturation of the in-game pixel is determined... also from company colour applied?

I'm asking because the grf I made from the 32bpp nightly gives some pretty whacky results in-game (I assume similiar to what GeekToo is seeing). I'm trying to fix the masks, and I'm unclear on whether I should be switching all of the masks to a specific colour index (e.g. 198 seems to give nice intense colours) and re-compiling, or whether I need to consider different mask colours for different situations. If a lot of mask conversion is required, can anyone point me to a good resource on selecting/modifying pixels by colour index in GIMP script-fu? I haven't been able to find anything particularly relevant to that subject with simple google searches.

[peter1138]

The max(R,G,B) of the 32bpp pixel is used to modulate brightness of the indexed colour. To allow over-bright pixels (the game looked very dull without this) a base value of 64 is used, so to use the indexed colour as is make sure the 32bpp pixel brightness is 64. The hue and saturation of the 32bpp pixel are completely ignored, and comes from the indexed colour, although if the pixel is very bright the saturation will reduce.

When using the company colours, you can use whatever available indices produce the best result. Be sure to test with each company colour though, as some of the gradients are different.

[GeekToo]

I'm still confused about the specifics here. It seems that brightness (approximated as max(R,G,B)) is important, but which brightness? The brightness of the 32bpp image pixel, or of the 8bpp mask (which is apparently interpreted as though the OpenTTD DOS palette has been applied)? Or some combination?

To put my and Peter's explainations in somewhat less technical language:
The EZ-zoom patch only uses the 32bpp sprite for brightness.
Trunk uses both the mask and the 32bpp sprite to determine brightness.

So if the masks for the EZ-patch are chosen too bright, in trunk it will look overlit.
Because there is a lot of variation in the mask colours in the nightly set, results have to be re-evaluated per sprite(set) and adapted. The actual adaption for a specific group of sprites, once you determined what the new mask value should be can be done in simple Python script, using PIL.

This script will show you the values in the mask file, in a similar way it can be converted.

Code: Select all

import sys
import Image
im = Image.open(sys.argv[1])
pix = im.load()
for y in range(im.size[1]):
        for x in range(im.size[0]):
                if pix[x, y] != 0:
                        print pix[x, y],
#im.save(sys.argv[1], "PNG")

[knuckles88]

Thanks for the colouring explanations. If you don't mind, I have another question or two:

-The old guide says to use colours in the 196-203 index range for masks. Are all colours available for use as masks now (in trunk)?
-Are there reserved colours for 32bpp sprites like there are for 8bpp sprites? I've made a .grf for a vehicle and I'm noticing that its sprite in the purchase window - which I provided a 32bpp alternative sprite for - periodically cycles between an off-white and a light blue while time is running (the 32bpp sprite is different enough from 8bpp sprite it overrides that I can tell the 32bpp sprite is being displayed). This seems to happen even without a mask, and I don't understand why.

[GeekToo]

Accidently used the water-cycle mask colours?
http://newgrf-specs.tt-wiki.net/wiki/Pa ... oordinates

[maquinista]

If you are dithering the masks from 32 bpp sprites, I recommend You to do a double dithering:
- Dither with a simplified 8 bpp palette (a OpenTTD palette without special colours). Use your favourite colour diffusion algorithm.
- Convert back to 24 bpp.
- Dither again, but with the OpenTTD palette.

[knuckles88]

OK, so I've managed to fix most of the masks using the following python (v 3.2) script:

Code: Select all

import sys
from PIL import Image
im = Image.open(sys.argv[1])
pix = im.load()
white = [0, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 254]
for y in range(im.size[1]):
        for x in range(im.size[0]):
                if pix[x,y] in white:
                        pix[x,y] = 0
                else:
                        pix[x,y] = 198
im.save(sys.argv[1], "PNG")

It was occasionally necessary to change the contents of "white" due to the way some masks had been made (i.e. sometimes I needed to add 1, sometimes I needed to remove 254). The target mask pixel index, 198, seemed to give good results for most of the masks. For some, a higher value such as 200 (corresponding to a lighter mask colouration) was better.

For some of the files, I'm getting weird results. Specifically, the buildings listed on the tracker page (http://wiki.openttd.org/City_Buildings_ ... cs%29#Town) as "1x1 Flats," "1x1 Modern office block," "1x1 office block," and "1x1 office tower" all have masks, but these buildings don't seem to spawn with different colours in-game like "1x1 Futuristic office block" does (they all end up taking on the blue colour of the mask). Is this a feature which was part of the EZ patch but isn't in trunk, or something?

Similarly, I have a collection of bridge tiles which have masks. I assume these are intended to give different flavours (steel, silicon, concrete) of the same bridge different colours, but the don't seem to be used in-game - all the bridges show up blue. I believe I collected the bridge sprites from another old .tar - would the recolouring of bridge sprites been coded in the associated .grf, rather than in the main game?

[FooBar]

Not all houses feature recolouring and some older houses use bridge-brown recolouring instead of cc-blue.

The latter is also the case for bridges. Bridges are recoloured from brown, not from blue. Therefore you need different mask colours for bridges.

[knuckles88]

Hmmm ok... so, based on looking at the original 8bpp bridge sprites, you mean colour indices 70-79? Will this recolouring follow the same algorithm as the company colour recolouring?

[FooBar]

Yes, those are the colours. I believe 97 is not mapped though, just 70 through 78.
The principle is furthermore the same, so you could simply recolour the blue mask to these browns.

[Zephyris]

I'm trying to get my 32bpp GRVTS set encoded as a grf with the help of knuckles88. I have managed to get the 32bpp graphics coded, compiled to a grf and working in game using this grfcodec 6.0.0 command:

Code: Select all

grfcodec -f -e -g2 grf_32bpp.nfo

What do the f e and g2 flags mean? Documentation is a bit thin...

This works for the 32bpp graphics but if I disable the 32bpp bitter the 8bpp graphics are not working correctly, the sprites sizes and positions seem to have been read wrongly when encoding the grf from the sprite sheet. I have double checked this is not down to human error, it does seem like a consistent effect though. Does anyone have any ideas about what's going on?