32bit Graphics Extra Zoom Patch

[NekoMaster]

Correct, it's not present (reminds me, I should really change it so that it does not crash, but just takes the optimized blitter, I believe BeeJay implemented that some time ago).

Also, animation for 8bpp is 'just' a palette-shuffle, we should discuss how to make animation for 32bpp work nicely.

Well, you could have extra sprites for animation for 32bit graphics

[Ben_Robbins_]

Would having extra, even multiple sprites for an animation not consume a lot more processing power/memory than having 1 animated sprite which notes the changes between stages, rather than starting afresh on every stage?. I know near on nothing on this though, so I'll just make animated sprites to whatever format/spec needed if I can.

[NekoMaster]

Would having extra, even multiple sprites for an animation not consume a lot more processing power/memory than having 1 animated sprite which notes the changes between stages, rather than starting afresh on every stage?. I know near on nothing on this though, so I'll just make animated sprites to whatever format/spec needed if I can.

Well unless they code in a "magic" colour for every animation, which would probably take more power, then i can only see having extra sprites being a better idea

[bazil14]

http://en.wikipedia.org/wiki/APNG

possible awnser to the pallete problem, if we implement support for that file format we should be fine

[Bad_Brett]

When I worked with mobile phone games we solved this by putting all animation frames into a single picture and just changed the coordinates, but I guess it would be complicated since you would have to set boundaries and stuff.

[neob]

does this bug: "Crashes quickly on full zoom since r13639 " still exist?
(i never encountered the problem)


And btw there is a bug with starting the game if there is no available openttd.cfg file, instead of creating a new one with default settings the game crushes.

[BeeJAy]

Correct, it's not present (reminds me, I should really change it so that it does not crash, but just takes the optimized blitter, I believe BeeJay implemented that some time ago).

Also, animation for 8bpp is 'just' a palette-shuffle, we should discuss how to make animation for 32bpp work nicely.

Here's how I did it, this is after the patch is applied, so you should be able to just add it to your code at the correct lines:

src/blitter/factory.hpp

Replace line 86 with:
const char *default_blitter = "32bpp-optimized";

Replace line 94 with:
default_blitter = "32bpp-optimized";

src/spritecache.cpp

Replace line 30 with:
uint _sprite_cache_size = 64;

src/table/settings.h

Replace line 256 with:
SDTG_STR("blitter", SLE_STRQ, S, 0, _ini_blitter, "32bpp_optimized", STR_NULL, NULL),

Replace line 273 with:
SDTG_VAR("sprite_cache_size",SLE_UINT, S, 0, _sprite_cache_size, 64, 64, 64, 0, STR_NULL, NULL),

It's a bit forceful, but it has to be so that if you have an openttd.cfg it changes the settings and if you don't have one, when it creates one it creates it with the settings.

Here's the diff with the changes implemented just in case but the code is pretty straight forward, I haven't been able to check to see whether it works as I don't have Visual Studio installed just yet.

32bpp_r18768_v13_fixes.diff

(80.4 KiB) Downloaded 126 times

Also I don't know whether the bug with the town names etc being offset/not working is still happening but I do have the ugly fix that I did so that they would at least work semi-properly, but it's more of an offset fix as the root cause seems to be in code I have no idea how to understand.

[neob]

btw why the trunk version supports 32Bpp but set it off by default?

[NekoMaster]

btw why the trunk version supports 32Bpp but set it off by default?

No its on, you just need to set the blitter to 32bpp-anim or 32bpp-optmised

Trunk just doesnt have the extra zoom levels

[neob]

i know, i asked why?

[peter1138]

Because it's detrimental to performance if you are only using the 8bpp graphics sets.

[neob]

maybe if you have a very low end system, i use it all the time with my laptop and seen no difference.
anyway, supported usually means you can change it in game and not some outside file editing.

the way i recall it, most users are afraid of the words location, edit, change, etc, even if its only notepad and clear text.

[Hyronymus]

Question: if you create a grf with extra zoom levels and play the grf in a "trunk" version of OTTD, will it work or does it break?

[CommanderZ]

Question: if you create a grf with extra zoom levels and play the grf in a "trunk" version of OTTD, will it work or does it break?

The GRF can contain only standard-zoom 8bpp sprites which are then overridden by the 32 bpp sprites loaded from corresponding tars/png files.

[neob]

The GRF can contain only standard-zoom 8bpp sprites which are then overridden by the 32 bpp sprites loaded from corresponding tars/png files.

so you for example you will have 2 files, MY.GRF and MY-in32Bpp.tar
which means that in order to upgrade all the current available GRF's you only need a tar file with the better quality images (no change to code)

but that still dont answer the question if Extra Zoom tar is compatible with normal zoom ?
(although i understand that making a normal zoom when you have a full zoom its very easy)

[maquinista]

The GRF can contain only standard-zoom 8bpp sprites which are then overridden by the 32 bpp sprites loaded from corresponding tars/png files.

so you for example you will have 2 files, MY.GRF and MY-in32Bpp.tar
which means that in order to upgrade all the current available GRF's you only need a tar file with the better quality images (no change to code)

but that still dont answer the question if Extra Zoom tar is compatible with normal zoom ?
(although i understand that making a normal zoom when you have a full zoom its very easy)

8 and 32 bpp are different style graphics. This means that 32 bpp doesn't have better quality than 32 bpp, It is a different look.

About the GFR+TAR files: TAR files replaces the 8 bpp sprites. If the TAR file and the GRF file are different (for example Spain set 1.27 in GRF and 1.28 in TAR file), You will get wrong graphics, because the sprite number can be different in the GRF file.

[Hyronymus]

This is too confusing for me. Maybe that makes me thick but can I get a simple answer please .

If I provide a grf with an extra zoom level, will the grf function normally in a trunk build of OpenTTD? So will it show the "default" zoom levels also in the grf?

[GeekToo]

Mix of concept Hyronymus:
A grf or newgrf is independent of zoom level, it changes game mechanics and/or 8 bit graphics. This will (if well coded of course) work in the extra zoom level patch and in trunk.

Then we have 32 bpp pngs (it is possible to tar them) that can replace graphics in the base set, or from the newgrf (by giving them the correct number and put them in the directory named after the grf).
And we have code:trunk or extra zoom patch.

Png files can be provided for the standard zoom level, and to provide extra graphical detail also for the extra zoom level patch. The latter won't be recognized by trunk version, it will not break, but they are just not shown, because they use a different naming convention. Png files for standard zoom will be recognized in both.

The problem that Maquinista mentions is true, but also independent of zoom level or trunk/patch, you just have to make sure you have the tar that belongs to a certain grf-version

[maquinista]

If I provide a grf with an extra zoom level, will the grf function normally in a trunk build of OpenTTD?

Yes, the GRF can work in a official release without problems.

[GeekToo]

So if you want to make, let's say, a trainset with 32bpp sprites, you would have to make a newgrf, with 8bpp graphics (can be dummy if you don't want to show anything in 8bpp), just like the newgrfs we all know.
Then you would have to provide some 32bpp pngs (png is just a graphical format, like jpg etc, extra zoomed or not), to show the trainset in 32bpp. They would have to be pngcodeced, but that is a relatively simple operation (at least compared to nfo-coding), it is just adding an x and y offset to the png, so the game knows where to show it.