[TOOL] RGBA EATER

[V453000 :)]

Hello, as I have been working on BRIX, I found it necessary to make a 32bpp->8bpp conversion tool.

RGBA_EATER_v1.png

(1.19 MiB) Not downloaded yet

If you would like to use it as well, you can find it at the devzone.

https://dev.openttdcoop.org/projects/br ... Rgba-eater

[V453000 :)]

You may have noticed that I keep mentioning my 8bpp converter script a lot recently.

I have been making use of it for BRIX, added support for a bunch of specific use cases, and added several improvements which should help make it more convenient to use.

I have created a github repository for the RGBA-Eater so it's much easier to download and keep updated.

https://github.com/V453000/RGBA-Eater

When downloaded, it works as is if you just replace 32bpp/example.png and double-click example.bat but it can be customized a lot.

Tonight I wrote a new readme to document its installation and usage better. The readme can be viewed on the github page.

Let me know if you can see some ways how I could make it even more intuitive and handy to use or the readme more clear.

I hope more NewGRF artists make use of it as it's a very powerful tool and seeing 32bpp NewGRFs look broken when 8bpp blitter is enabled is sad when there is this tool to solve it easily.

[PikkaBird]

seeing 32bpp NewGRFs look broken when 8bpp blitter is enabled is sad when there is this tool to solve it easily.

Hey, that's me!

I'm not planning to add proper 8bpp sprites to my sets, since 32bpp is the default and is faster than 8bpp on those modern systems that even support 8bpp - but nonetheless, I will ask this question: 32bpp sets use a separate overlay sprite to apply company colours. Could RGBA Eater combine the separate CC sprite into the main sprite to create its output?

[V453000 :)]

Hey, that's not only you I believe

I'm very surprised that 32bpp is faster, is that something new? I know when I started making some of my early 32bpp NewGRFs, a lot of people were telling me they just had to change to 8bpp blitter to keep afloat. I'm not sure whether I was actually adding 8bpp x4 zoom at that point though so it could have been just the resolution that had all the impact.

Still, as long as OpenTTD supports 8bpp I'd say it's worth adding proper 8bpp sprites IF the task can be somewhat automated and not a Photoshop set palette nightmare.



To answer your question, yes and no.

RGBA-Eater alone can't do that as it only processes a single file, not multiples.

However, I do exactly what you are saying in BRIX by a separate, much simpler script I call _mask-copier.py, though it's just a "place image A on top of image B and ignore index 0 (alpha blue) pixels".

https://github.com/V453000/BRIX/blob/ma ... -copier.py

My .bat command to start a resizer, RGBA-Eater, mask copier and NMLC to compile the grf then looks for example like this:

Code: Select all

_resizer.py -r -d 4 -i 32bpp/train-station/x4/train-station_0000.png    -o 32bpp/train-station/x1/train-station-x1.png
_resizer.py -r -d 4 -i 32bpp/train-station/x4/train-station-CC_0000.png -o 32bpp/train-station/x1/train-station-CC-x1.png

RGBA-EATER.py -n train-station/x4/train-station        -e ALL
RGBA-EATER.py -n train-station/x4/train-station-CC     -e CC1

RGBA-EATER.py -n train-station/x1/train-station-x1     -e ALL
RGBA-EATER.py -n train-station/x1/train-station-CC-x1  -e CC1

_mask-copier.py -m 8bpp/train-station/x1/train-station-CC-x1-8bpp.png -f 8bpp/train-station/x1/train-station-x1-8bpp.png
_mask-copier.py -m 8bpp/train-station/x4/train-station-CC-8bpp.png    -f 8bpp/train-station/x4/train-station-8bpp.png

cd ..

C:\NML\nmlc -c --default-lang=english.lng --grf=BRIX.grf BRIX.nml
copy /Y BRIX.grf "C:\Users\V\Documents\OpenTTD\newgrf"
pause

[Eddi]

people were telling me they just had to change to 8bpp blitter to keep afloat.

that was most likely due to sprite cache size (i.e. more about 4x zoom than 32bpp)

modern graphics drivers don't have support for decades old 8bpp magic (particularly palette animation), so that might be subject to slow software emulation, which brings down the speed. particularly OSX users have reported problems in this area.

[V453000 :)]

That's very interesting. From my laic perspective I just thought that the amount of more data in 32bpp will definitely make it slower.

So basically for performance,instead of adding 8bpp x4 version it's better to make a stripped NewGRF with x1 32bpp.

[Michi_cc]

I think two things are conflated here: a 32bpp blitter might well be faster than an 8bpp one, simply because all current OSes will emulate 8bpp more or less accelerated anyway. 32bpp blitters in OTTD can show 8bpp sprites as well though, and there for identical sprites 8bpp is likely to be faster than 32bpp due to the reduced memory bandwidth.

[V453000 :)]

Interesting. Well, I guess I'll just continue defining all of 8bpp and 32bpp properly and how the grf is used in the future can be chosen by the user.

[Eddi]

it's better to make a stripped NewGRF

that's more of a theoretical possibility. with the introduction of 32bpp and extra zoom sprites in GRF v8/container v32 came the functionality to have both full and stripped versions that are considered as compatible by the game, but the whole infrastructure of BaNaNaS was never adapted to handle this, so only users who install GRFs manually would be able to use the stripped version, and that's just a handful, effectively.