Simutrans 32-bit graphics — work in progress and open for review

[victor_18993]

I have been working on a new 32-bit graphics renderer for Simutrans Standard.

The goal is to modernize the graphics pipeline while keeping compatibility with the existing game and current paksets. Existing 16-bit graphics still work as they do today, but the new renderer can use full 32-bit colour internally, giving us much more room for better shading, transparency, lighting and future higher-quality graphics.

The project is still under development and has NOT been integrated into SVN.

The current version already runs with GDI, SDL2 and SDL3 and has been tested with pak64, pak128 and pak192.comic. The classic 16-bit renderer is still preserved as well.

I have published the current development version here so that anyone interested can review the code, screenshots, documentation and validation results:


https://github.com/Dkijas/simutrans-true32-renderer

The repository also contains the patch against the current development base, build instructions and technical notes.

At this stage I would especially appreciate feedback from maintainers, developers and anyone interested in the graphics side of Simutrans.

There is still work to do before any possible integration into the official trunk, so for now this should be considered a public work-in-progress and review project.

[victor_18993]

I've now been able to reproduce and isolate this properly.
There were actually two separate Windows GDI issues involved: one in resize-event delivery, and another where

Code Select Expand

WindowSize mixed logical and physical pixels when Windows scaling was above 100%.
Both now have tested candidate fixes. I've verified them at 150% scaling with resize, maximize and restore, and the original corruption no longer appears.
I've published the fixes and the test evidence in the public lab repository for review:
https://github.com/Dkijas/simutrans-true32-renderer

[makie]

Great,
that's what I've been waiting for—I'm I am scraping with my feet.

Is there a version of makeobj yet that handles 32-bit graphics?

[victor_18993]

Hi Makie, for now we first need to agree that this renderer is what is wanted—a 32-bit renderer that is backwards-compatible with 16-bit so we don't break existing add-ons (this is essential). The architecture is already designed and I'm still testing, looking for potential bugs.

Then there would be the community discussion to see if the proposal is suitable for Standard.

Don't worry, Makeobj will definitely have to be updated to a version that supports both the future and current formats. As soon as the scope is finalized, I will present the Makeobj proposal.

I know you're very eager for this leap to 32-bit without image compression, but it's important that it's finalized properly. The Japanese community is also waiting for this to be settled, from what I've talked with them, since they would likely handle the port to OTRP and I would do the port adapted for Extended so James can review it.

My idea is for this project to be cross-cutting, just like SDL3 was, which has been quickly incorporated into OTRP and Extended.

Thank you very much for the comment, and I would really appreciate hearing what you artists expect from a real leap to 32-bit without image compression.

[makie]

and I would really appreciate hearing what you artists expect from a real leap to 32-bit without image compression.

It s not a image compression it is a lost of color information. Color gradients become stepwise. That can be mask with dithering, but then there is a lost of resolution and sharpness. The graphics are becoming crumbly.

In pak128.german all graphics are available as 32/24-bit graphics.
All i have to do is use a 32bit capable makeobj and run over the thousands of graphics and the map should be softer and the colors more nuanced.
Just how clearly visible that becomes—and whether the effort is worth it—can only be seen in a real test.

pak192.comic will not benefit, i think.
But pak128 and pak128.german should look much more better.
pak64 has too few pixels, so no significant differences are to be expected.

[victor_18993]

That's great if you have all the images because you can migrate quickly; I framed it as a system that will allow coexistence.

Yes, exactly, I misspoke—it's not image compression, it's how it's processed in Makeobj and then displayed by the renderer in Simutrans. This project is indeed about that: not losing detail, being able to implement shadows and depth, and adding more detail to the graphics.

Ultimately, for me it's not just about improving the graphics and giving Simutrans a bit of a visual refresh for the user, but also about providing a better tool for everyone making add-ons—so what you're already creating in 32-bit is displayed in Simutrans with depth, shadows, and details that we can't offer today with the current renderer.

[poppo]

In my opinion, we need to decide how to treat special colors for 24bit colors.

Player color has only 8 variations of brightness, and we can only set the player color from about 28 colors.
The number of special colors are too less, with the 24bit well-resolution graphic.
(And more, we also need to check the variation and how to define light colors in the night)

24bits (32bits) is not hard task for pak makers because most image editing software supports 24(32) bits PNG file.

[victor_18993]

Poppo, I think that's one of the issues to address. I'd like to have the input of Prissi and the rest of the maintainers to get a broader view.


Thank you very much for your contribution.

[makie]

In my opinion, we need to decide how to treat special colors for 24bit colors.

Look at this discussion:
https://forum.simutrans.com/index.php/topic,23978.msg213136.html
More special colors lead to many lighting pixel in old graphics.
Who has fought against glowing ghost pixels knows, this is a real nuisance.
All the old PNG files would then have to be reworked.

A good solution is a mask graphic specified separately.
Then at least 24 bits are available for all all kinds of special colors.
And if a mask graphic is specified then the old special colors should be ignored.

[victor_18993]

Look at this discussion:
https://forum.simutrans.com/index.php/topic,23978.msg213136.html
More special colors lead to many lighting pixel in old graphics.
Who has fought against glowing ghost pixels knows, this is a real nuisance.
All the old PNG files would then have to be reworked.

A good solution is a mask graphic specified separately.
Then at least 24 bits are available for all all kinds of special colors.
And if a mask graphic is specified then the old special colors should be ignored.

I'm already looking into evolving MakeObj so the prototype can be used for testing; this might help serve as a testing platform to unblock agreement on the special color specifications, for example, or test how the graphics look.

I'll let you know as soon as I update the repository.

[victor_18993]

A small update on the RGBA32 / true32 work.

The project has moved forward quite a lot since the last update. The experimental runtime can now load the new XR32 image data while keeping the normal IMG data as a fallback, so old content and older Simutrans versions remain compatible.

The main pieces are now working together:

• true RGBA32 rendering
• legacy IMG fallback
• player colours and special colour semantics
• day/night changes
• transparency and antialiased semantic edges
• native zoom for XR32 images
• substantially reduced memory usage and first-draw/zoom costs

The native zoom was probably the hardest part. Player colours cannot simply be averaged when an image is scaled, so this needed a new runtime representation that keeps the different colour contributions separate. That design is now implemented and has passed the current pixel-level validation without mismatches.

We have now consolidated the work into a single candidate and are cleaning the remaining laboratory code. It is still experimental and not yet an SVN candidate: there is one runtime path that still needs explicit test coverage, and broader compiler/platform testing is still pending. Makeobj production integration will also come later.

Once the current cleanup is complete, I think we have accumulated enough progress to publish a new laboratory GitHub pre-release, so people can start testing it with real saves, paksets and hardware while we continue preparing the eventual Standard candidate.

So the project has moved from "can true 32-bit graphics work in Simutrans?" to mainly "is the implementation clean, sufficiently covered and portable enough for upstream review?"
I'll keep posting updates as those last stages are completed.

[victor_18993]

[Experimental] True 32-bit (ARGB8888) renderer - Windows test build, feedback wanted

An experimental prototype of a true 32-bit ARGB8888 screen renderer for Simutrans
Standard is available for testing. It is NOT integrated into Standard, it is not an
official release, and it is not a stable version.

Download (Windows x86_64, SDL2):
https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/rgba32-revised-4-r12261-testing-1

What it does: the screen framebuffer and the per-player image caches become ARGB8888
instead of RGB565, so day/night shading, transparency, blending, player colours,
outlines and zoom filtering work with 8 bits per channel instead of 5/6/5. Pakset
image data, savegames and the network protocol are unchanged.

The archive contains two executables built from the same source tree:

    simutrans-rgba32.exe  the 32-bit renderer - the one to test
    simutrans-16bit.exe    the ordinary 16-bit renderer - for comparison

Comparing the two on the same world is the most useful thing you can do.

How to run it:

    1. Extract into a folder of its own, NOT over your normal installation.
    2. Copy in a pakset (pak64, pak128, ...). None is bundled - please use your own.
    3. Use COPIES of any savegames you try.
    4. Run:  simutrans-rgba32.exe -singleuser
      -singleuser keeps settings, saves and screenshots inside that folder
      instead of your Documents\Simutrans.

What would help most:

    - zoom: scroll over a large map at every zoom level, watching tile edges
    - info windows: tile, station, convoy, depot, line - especially at zoom
      levels other than the default one
    - transparency: underground view, cursors, transparent building mode
    - player colours with more than one player, and day/night transitions
    - long sessions, an hour or more on a busy map
    - save and reload, compared against simutrans-16bit.exe on the same save

A note on XR32: the build can read an optional extra node in a pak file, but no
public pakset contains one and the makeobj that would write them is not part of
this candidate. Your usual paksets bring no new XR32 content, so there is no XR32
visual improvement to look for here. Testing the 32-bit renderer with ordinary
paksets is the useful test.

Reporting: https://github.com/Dkijas/simutrans-true32-renderer/issues
There is a "Bug / regression" template. Please include the pakset and version, your
Windows version, the steps from a fresh start, and - this matters more than usual,
because most of the changed code is clipping and zoom - the zoom level and which
window was open. A screenshot and a minimal savegame help.

This is a candidate, not a proposal to merge. It can and probably will change based
on what testing and the discussion here turn up.

[prissi]

I had a look at the code. It seems, the only difference is the output being 32 bit, but the images pixels still RBG565 bit? It's a bit lost in the include files.

For 32 bit, I think the darkening needs to be handled in the images on the fly with lazy caching, like zoom, and not using lookup tables which are impractically large compared to cache size. With 16 bit 128kB, bit with 4*(2^24) => 64MB, not fitting most caches anymore and thus almost slower than a calculation. Moreover, modern processor have a lot of parallel bytewise operations, so bytewise darkening could be very optimised by the compiler. If all fails, one could use a 256 bit table for darkening one channel after the other, but that sounds again slow (It will fit in the Level 1 cache ...)

[makie]

For 32 bit, I think the darkening needs to be handled in the images on the fly with lazy caching, like zoom, and not using lookup tables which are impractically large compared to cache size. With 16 bit 128kB, bit with 4*(2^24) => 64MB, not fitting most caches anymore and thus almost slower than a calculation. Moreover, modern processor have a lot of parallel bytewise operations, so bytewise darkening could be very optimised by the compiler. If all fails, one could use a 256 bit table for darkening one channel after the other, but that sounds again slow (It will fit in the Level 1 cache ...)

Why was darkening handled via a lookup table in 16-bit colors? Presumably to avoid having to check for each of for the various special colors.

Darkening itself is very simple isn't it? Just simply subtract a value from each color. Arithmetic operations on modern CPUs are very fast, whereas memory accesses are slow.

In the future, we want to have even more special colors. These should be encoded in a separate graphic plane.

The question is: is there a need for handling a special color for this pixel? Is there a special color at this tile at all? If no then do darkening with subtraction.

If all fails, one could use a 256 bit table for darkening one channel after the other, but that sounds again slow (It will fit in the Level 1 cache ...)

That doesn't work. To identify a special color, all three colors must be compared.

From my point of view, the old-style special colors should be separated into a own graphics layer during loading. That is necessary for 32-bit colors anyway.

Edit supplement:
If there is a wish for a lookup table, then the index should be a program internal sequential number, so that the table keep small and convert all spezial colors in this index. That would also keep the graphics layer for special colors small.
------
I don't have Windows, only Linux.

[victor_18993]

Hi, I'm looking over your comments and the code. I got back to work from vacation this week and haven't had much time, sorry.

[victor_18993]

Thanks both for reviewing the code.

Makie, a Linux x86_64 build is now available in the same pre-release:
https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/rgba32-revised-4-r12261-testing-1

Download the linux-x86_64-sdl2.tar.gz archive. It includes both renderers for comparison. Please use your own pakset, a separate folder, -singleuser and copies of your saves.

It was built on Ubuntu 26.04 and tested under WSL2 with a virtual display, so desktop feedback would help. It is dynamically linked; if it fails to start, please send your distribution and the terminal error.

Prissi, you are right: the legacy stored images remain 16-bit. The framebuffer and screen caches are ARGB8888, but that cannot recover colour detail already lost in the source.

The current implementation already caches the darkened images lazily. It also does not use a lookup table covering the full 24-bit colour space: the colour tables total about 267 KiB in this build, around 136 KiB more than the 16-bit version.

Makie, special colours already have dedicated codes and compact palette entries, but that is not the independent graphics plane you are proposing. Your suggestion goes further, especially where colour and alpha are still packed together in the legacy format.

For now, I have kept the candidate unchanged so we can compare behaviour. Feedback on zoom, info windows, transparency and longer sessions would be very welcome.

[makie]

I started the program and, oh shock, the window was completely black. No error message, nothing. Somehow I got the idea to resize the window and there it was, the pak set selection. Otherwise, the game runs without any issues. Trees with transparency flicker when they extend above the map. Tested on a large map with big cities.


old


supplement:
Performance -> ok
CPU using -> marginally higher
RAM using -> approximately the same

[victor_18993]

Thanks, Makie! I reproduced the black window and found the cause: the 32-bit renderer was missing its initial clipping rectangle, so nothing was drawn until resizing the window set one. Your resize tip helped track it down.

The fix is verified locally, and I'm preparing an updated Linux build.

I haven't reproduced the tree flicker yet. Which pakset and version are you using? Does it also happen with the 16-bit executable from the same archive? A savegame showing the affected area and the zoom level would help.

[Yona-TYT]

and I'm preparing an updated Linux build.

I'll wait for this one to do some testing. 

[victor_18993]

Quote from: Yona-TYT on 12/9/2026, 3:24:20
I'll wait for this one to do some testing. 

The Linux version is now available on GitHub, cheers.

[Yona-TYT]

Code Select Expand

error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory

There are dependency issues in Fedora.

The following are needed: libbz2.so.1.0

But Fedora only has:

Code Select Expand

/usr/lib64/libbz2.so
/usr/lib64/libbz2.so.1
/usr/lib64/libbz2.so.1.0.8


Edit.

I've created a library link in Fedora to match the one Simutrans looks for; however, this is just for testing purposes. The expected behavior is for Simutrans to work with the library links that the system provides by default.


The first issue I see is that the package installation window isn't displaying correctly:

Code Select Expand

'/home/yonatan/Descargas/simutrans-rgba32-revised5-r12261-linux-x86_64-sdl2/simutrans-rgba32'  -debug 3
Simutrans version 124.5.1 Nightly from Sep 12 2026 r12261
Message: simu_main():    Parsing /home/yonatan/Descargas/simutrans-rgba32-revised5-r12261-linux-x86_64-sdl2/config/simuconf.tab
Message: simu_main():    Version:     124.5.1 Nightly  Date: Sep 12 2026
Message: simu_main():    Debuglevel:  3
Message: simu_main():    base_dir:    /home/yonatan/Descargas/simutrans-rgba32-revised5-r12261-linux-x86_64-sdl2/
Message: simu_main():    install_dir: /home/yonatan/simutrans/paksets/
Message: simu_main():    user_dir:    /home/yonatan/simutrans/
Message: simu_main():    locale:      es
Message: dr_os_init(SDL2):    SDL Driver: wayland
Message: SDL_StartTextInput:   
Message: dr_query_screen_resolution(SDL2):    screen resolution width=1366, height=768
Message: simu_main():    simgraph_init disp_width=704, disp_height=560, fullscreen=0
Message: dr_query_screen_resolution(SDL2):    screen resolution width=1366, height=768
Message: dr_os_open():    Screen requested 704,560, available max 1366,768
Message: internal_create_surfaces(SDL2):    Renderer: opengl, Max_w: 0, Max_h: 0, Flags: 14, Formats: 4, SDL_PIXELFORMAT_ARGB8888, SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_RGB888, SDL_PIXELFORMAT_BGR888
Message: internal_create_surfaces(SDL2):    Renderer: opengles2, Max_w: 0, Max_h: 0, Flags: 14, Formats: 4, SDL_PIXELFORMAT_ARGB8888, SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_RGB888, SDL_PIXELFORMAT_BGR888
Message: internal_create_surfaces(SDL2):    Renderer: vulkan, Max_w: 16384, Max_h: 16384, Flags: 14, Formats: 2, SDL_PIXELFORMAT_ARGB8888, SDL_PIXELFORMAT_ABGR8888
Message: internal_create_surfaces(SDL2):    Renderer: gpu, Max_w: 16384, Max_h: 16384, Flags: 14, Formats: 4, SDL_PIXELFORMAT_ARGB8888, SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_RGB888, SDL_PIXELFORMAT_BGR888
Message: internal_create_surfaces(SDL2):    Renderer: software, Max_w: 0, Max_h: 0, Flags: 13, Formats: 8, SDL_PIXELFORMAT_ARGB8888, SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_RGBA8888, SDL_PIXELFORMAT_BGRA8888, SDL_PIXELFORMAT_RGB888, SDL_PIXELFORMAT_BGR888, SDL_PIXELFORMAT_RGB565, SDL_PIXELFORMAT_RGB555
Message: internal_create_surfaces(SDL2):    Using: Renderer: opengl, Max_w: 16384, Max_h: 16384, Flags: 10, Formats: 9, SDL_PIXELFORMAT_ARGB8888
Message: dr_os_open(SDL2):    SDL realized screen size width=704, height=560 (internal w=704, h=560)
Message: simu_main():    .. results in disp_width=704, disp_height=560
Message: simu_main():    Loading colours from /home/yonatan/Descargas/simutrans-rgba32-revised5-r12261-linux-x86_64-sdl2/config/simuconf.tab
Warning: simwin.cc themes_init():    Can't read themes from themes.tab
Message: font_t::load_from_freetype:    trying to load 'font/cyr.bdf' in size 11
Warning: font_t::load_from_freetype:    Cannot load font/cyr.bdf
Message: :    env_t::reload_and_save_on_quit=1
Message: SDL_EVENT:    0x207
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x302
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x302
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x302
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x400
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x200
Message: SDL_EVENT:    0x100

[makie]

I haven't reproduced the tree flicker yet. Which pakset and version are you using? Does it also happen with the 16-bit executable from the same archive? A savegame showing the affected area and the zoom level would help.

It is pak128.german, you can always assume this if makie don't note else.
The Map is: https://makie.de/viele-große-stadte.sve
Zoom Level is not important, but move around with the mouse change the speed of flickering.

only Trees with transparency

Look at the shadow of the trees and i think some load for the CPU is need.

Does it also happen with the 16-bit executable from the same archive?

No

Addendum regarding "viele-große-stadte.sve":
If you try to load this map using a debug version of the program, an assertion by Prissi regarding invalid city boundaries is triggered. You might want to remove that assertion for testing purposes.

[makie]

Warning: simwin.cc themes_init():    Can't read themes from themes.tab
Message: font_t::load_from_freetype:    trying to load 'font/cyr.bdf' in size 11
Warning: font_t::load_from_freetype:    Cannot load font/cyr.bdf

@Yona-TYT
I think your test folder miss this, or the path isn't set.

I admit I ignored Victor's test instructions and simply threw the program into my normal installation.
That way, I don't have problems like that.

[victor_18993]

I'll look into the issue with Fedora and let you know as soon as I have something,




cheers.

[victor_18993]

Thanks, Makie and Yona-TYT! Your reports helped track down the startup bugs.

A new Linux build is ready:
https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/rgba32-revised-7-r12261-testing-1

It fixes the black startup window and missing text, and no longer needs the manual library symlink. The same package was tested on Debian 13, Fedora 43 and Fedora 44 using virtual X11 sessions.

Yona, could you try it and let me know whether both problems are gone? Please extract it into a separate folder, run with -singleuser and use copies of your saves.

Makie, the tree flicker is still open. A savegame and your pakset version would help me reproduce it.

This update is Linux-only; the Windows downloads are unchanged.

[Yona-TYT]

Yona, could you try it and let me know whether both problems are gone? Please extract it into a separate folder, run with -singleuser and use copies of your saves.

Perfect, I can now start Simutrans without any problems. 



There is a bug  when I use zoom out / in in the minimap, see this video:

https://github.com/Yona-TYT/imgs/raw/6bb25bf23767c90a6d91e333fcb4bad947a8df8f/Grabaci%C3%B3n%20de%20pantalla%20desde%202026-09-12%2015-08-20.mp4

Some icons are misaligned in the factory window:

[makie]

Makie, the tree flicker is still open. A savegame and your pakset version would help me reproduce it.

Look above posting #21

Addendum:
16-bit mode also exhibits the rendering glitch affecting trees with alpha channels; however, there is no flickering, and the issue only appears when moving the mouse cursor (magnifying glass) from outside the map, across the map edge, and directly onto the tile containing the tree.

This is clearly visible with deciduous trees in autumn or spring. With coniferous trees, only the shadow rendering is incorrect.

If 32-bit doesn't flicker move around with the mouse cursor (magnifying glass) over trees and watch the trees at the map margin.

[victor_18993]

Revised-8 is now available for Linux SDL2 and Windows SDL2/SDL3:

https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/rgba32-revised-8-r12261-testing-1

It fixes the minimap drawing outside its window when zooming and the misaligned icons reported by Yona. The Windows builds also include the previous fix for missing text at startup.

Yona, could you check the minimap and factory window again? Thanks for the video — it helped catch the brief drawing error.

Makie, could you also retest the trees at the map edges? The image-offset fix may be relevant, but I have not reproduced the flicker and cannot claim it is fixed. "No change" would also be useful feedback.

Each package includes 32-bit and 16-bit executables for comparison. Please extract into a separate folder, add your pakset, run with -singleuser and use copies of your saves.

Still experimental and not integrated into Simutrans Standard.

[Yona-TYT]

It works fine now.

You know, I've noticed something interesting: your Linux builds do show the window decorations that the GNOME compositor assigns, but the official Simutrans versions don't.

So, the window should look like this (Your builds are fine):


Official version (GNOME compositor decorations don't appear):



Edit.

The currency symbol (Euro) is not displaying correctly; I suspect this also affects the official version:



By the way, Isaac is still punishing us with the attachments files.   

[makie]

Makie, could you also retest the trees at the map edges? The image-offset fix may be relevant, but I have not reproduced the flicker and cannot claim it is fixed. "No change" would also be useful feedback.

No change.

Yona as a role model—here are some videos:
new 32 bit
old 16 bit

As you can see, the bug itself is old, but it is triggered more frequently in 32-bit mode.

The alpha channel is drawn to the image itself multiple times; essentially, the image with the alpha channel is drawn over itself repeatedly.

Without an alpha channel, this goes unnoticed, since drawing the same image multiple times makes no difference.

[prissi]

It goes away, when using the outside graphics:
draw_outside_tile=1

I guess the outside "color" at that point is still white. Thus, there is nothing to blend with, and any belding will increase the brightness of the pixels.

[victor_18993]

I'll have to take a look at the project, sorry for the hiatus but I've had quite a bit of work lately, I'll try to share updates as I make progress,




Best regards.

[victor_18993]

Hi makie,

I've published revised-9 with the fix for the map-edge tree/shadow flickering you reported:

https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/rgba32-revised-9-r12261-testing-1

I can reproduce the problem reliably with revised-8, and with revised-9 it disappears in my tests. The change also fixes the same issue in the 16-bit renderer.

If you have a chance, could you try revised-9 with the savegame where you originally saw the problem? Your confirmation would be especially useful since your report led us to the root cause.

Thanks again for the recordings and for helping test this 🙂

[makie]

Hi makie,

I've published revised-9 with the fix for the map-edge tree/shadow flickering you reported:

That looks good. I can't find any more errors.

[victor_18993]

Hi, I'm going to rebase everything onto the 125.0 stable branch to continue, I'll let you know as soon as the new beta is released.

[victor_18993]

Hi everyone,

I've published **RGBA32 revised-10** as a new public testing release:

https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/rgba32-revised-10-r12322-testing-1

This version has been rebased onto **r12322**, just after the Simutrans 125.0 release, so it is now much closer to the current codebase.

The main goal is still the same: **keep full compatibility with existing 16-bit paksets while allowing 32-bit RGBA artwork on top**.

Since revised-9, this build includes the XR32 asset pipeline, 1x/2x MRES support, CRC/bounds checks and the partial-transparency fixes. Windows SDL2, Windows SDL3 and Linux test builds are included, together with a small XR32 test kit and the source patches.

This is still an **experimental testing build**, not trunk and not an official Simutrans release.

The main open issue is still antialiased edges involving special colours such as company colours and lights. That will probably need explicit metadata from the artwork/exporter rather than trying to guess it inside Makeobj.

If anyone wants to test it, I'd be very interested in screenshots, visual regressions, crashes or cases where legacy paksets behave differently from normal Simutrans.

Thanks to everyone who has helped with testing and feedback so far.

[makie]

The main open issue is still antialiased edges involving special colours such as company colours and lights. That will probably need explicit metadata from the artwork/exporter rather than trying to guess it inside Makeobj.

I don't understand; please explain.

[victor_18993]

I don't understand; please explain.

Sure. What I mean is this:

Simutrans recognises company colours and light colours because some exact RGB values have a special meaning.

For example, if a pixel is exactly a company-colour value, the game knows that it has to replace it with the selected player's colour.

The problem appears at antialiased edges.

Imagine a company-coloured area next to a normal grey area. Blender or another graphics program creates intermediate pixels between them to make the edge smooth. Those pixels are no longer the exact Simutrans company colour — they are mixtures of the company colour and grey.

So when Simutrans reads the image, it can recognise the central company-colour pixels, but it cannot know that those intermediate edge pixels were also intended to belong partly to the company colour. To the game they just look like ordinary RGB colours.

The same problem exists around night lights.

We tested trying to guess this automatically in Makeobj, but it is not reliable enough. Different artwork can produce the same intermediate RGB colour for completely different reasons.

That is why I mentioned metadata from the exporter. For example, Blender could export the normal RGBA image plus a small mask saying:

"these pixels belong to company colour 1"
"these pixels belong to this light"

Then Simutrans would know the intended meaning even on smooth/antialiased edges.

Exact special-colour pixels already work correctly. This is only about preserving their meaning through the partially blended pixels around their edges.

[makie]

So when Simutrans reads the image, it can recognise the central company-colour pixels, but it cannot know that those intermediate edge pixels were also intended to belong partly to the company colour. To the game they just look like ordinary RGB colours.

Yes

We tested trying to guess this automatically in Makeobj, but it is not reliable enough. Different artwork can produce the same intermediate RGB colour for completely different reasons.

Please don't do it.

You try to generate the special colors via Blender automatically. My be this is possible or not. This is a special problem to Blender. Please do not integrate a solution to this problem in Makeobj.

The workflow of Pumuckl999s and my and may be some other graphic designer is:

Step 1: Create the the picture regardless of special colors.
Step 2: Eliminate the accidentally created special colors by replacing it to nearby color.
Step 3: Set special colors at the desired position manual.

If in future special colors are in separate plane there is no need for Step 2 and also there is no antialiased edges. See it as a mask, it is pixel exakt and no antialiasing. Maybe sdl3 or the graphics card do it for scaling. This is then after darkening for the night and handle the player colors.

The graphic stock contain no anti-aliased special colors.

[prissi]

I think too, either the old way as before (since we have already 32 bit PNGs anyway) or a new entry, with a second image name after a semicolon ";" with the mask. (Or even for. But I think atleast for the player colors, unsing red and green for masking with player colors 1 and player color 2 should be straight forward.) Maybe even a third image with the night appearance? So at dawn, the images are blended, which gives all the freedom for a night image.

[victor_18993]

Thanks, this makes sense.

I agree that Makeobj should not try to guess antialiased special colours from the final RGB image. The better direction is to keep that information explicit in the artwork/export pipeline, for example with separate masks/layers for player colours and lights.

I'm going to prototype that approach for XR32, while keeping legacy paksets fully compatible. I'll also look at the optional separate night image idea as a possible second step.

Thanks for the feedback — it matches very well with what the tests were already showing.

[victor_18993]

Hi everyone,

I've published a new public testing build of the 32-bit renderer work:

Revised-11 testing-1
https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/rgba32-revised-11-r12322-testing-1

This version is mainly about solving one of the trickiest parts of the 32-bit work: special colours around anti-aliased edges.

Until now, we were trying to infer things such as player colours and lights from the final rendered image. That works in simple cases, but starts to become unreliable once Blender, anti-aliasing and semi-transparent edge pixels are involved.

Revised-11 changes the approach.

Instead of asking Makeobj to guess the meaning of those pixels, the artwork can now provide the visual image and the semantic information separately.

That gives us a much cleaner pipeline for things such as:

- player/company colours
- lights
- multiple lights affecting the same pixel
- anti-aliased edges
- linear-light composition
- normal RGBA transparency

The important part is that this does not replace the normal image. The visible artwork stays exactly that: the artwork. The extra data simply tells Simutrans what some pixels mean.

For artists, the public test kit includes simple examples for manual 2D work and Blender, so you can see how the idea works without needing the internal test material I used during development.

Compatibility has also been an important part of this work.

Old pak files continue to work with the revised renderer, and the existing old test paks are unchanged. I also tested the new semantic paks with the older builds that were actually part of the compatibility tests.

Windows and Linux Makeobj builds generate the same pak bytes, and the renderer results match between the tested Windows and Linux builds.

There is one known performance issue in testing-1:

For 32-bit images without semantic masks, rebuilding the zoom cache is currently around 10–12% slower than revised-10. This happens when the zoom level changes, not every frame during normal gameplay.

I already have that isolated as a separate optimisation task, so I decided not to delay this testing build or mix an untested optimisation into it. If the fix is good, it can go into testing-2.

A few other notes:

- macOS and Android have not been runtime-tested for this version.
- The Blender exporter changes are still prototype patches, not yet part of the published Blender Kit.
- Object Studio can validate semantic masks, but it does not yet have a full editing UI for them.
- The Renfe S453 artwork I used for some internal accuracy tests is not included in the release.

At this point I'd really like feedback from pakset artists and testers.

In particular, I'm interested in whether this workflow feels understandable from an artist's point of view, and whether you see any visual regressions with existing paksets.

If you test it, please mention your OS, build used, pakset and what you were testing. Screenshots are very welcome if something looks wrong.

Thanks again to everyone who commented on the earlier versions. The move away from colour-guessing and toward explicit semantic data came directly from those discussions, and I think revised-11 is a much stronger direction because of it.

[prissi]

Do you mean a mask per each player color? I think using the old player colors at (maybe 15%) PC0 TO (80%) PC7 and similar for the second player color. This way, the colors would stay the same for 16 bit and 32 bit paks, as surely users would (and should) be able to mix paks visially.

When talking about blender, rendering night images would be rather trivial and remove the need for special night colors althougether, allowing for an easy automated work flow. And even for handdrawn paks, adding a nigh image can easily done using the base image and then enabling all kind on night effects.

Not everyone uses blender, especially the Japanese community uses pixels a lot. Having so many extra maps woudl be prone to errors. But a single extra night map seems rather straight forward.

And for paks without night images or old paks, night images could be generated on load time, leading to unified handling of the night for all images, leaving only the player colors for special treatment.

So something like

Code Select Expand

Image[...]=IMG.a.b[,x,y][;Night-IMG.a.b[,x,y]|-][;PC1-IMG.a.b,x,y|-][;PC2-IMG.a.b,x,y]shoudl be even manageable for handdrawn images and give even more flexibility.

[victor_18993]

Do you mean a mask per each player color? I think using the old player colors at (maybe 15%) PC0 TO (80%) PC7 and similar for the second player color. This way, the colors would stay the same for 16 bit and 32 bit paks, as surely users would (and should) be able to mix paks visially.
When talking about blender, rendering night images would be rather trivial and remove the need for special night colors althougether, allowing for an easy automated work flow. And even for handdrawn paks, adding a nigh image can easily done using the base image and then enabling all kind on night effects.
Not everyone uses blender, especially the Japanese community uses pixels a lot. Having so many extra maps woudl be prone to errors. But a single extra night map seems rather straight forward.
And for paks without night images or old paks, night images could be generated on load time, leading to unified handling of the night for all images, leaving only the player colors for special treatment.
So something like

Code Select Expand

Image[...]=IMG.a.b[,x,y][;Night-IMG.a.b[,x,y]|-][;PC1-IMG.a.b,x,y|-][;PC2-IMG.a.b,x,y]shoudl be even manageable for handdrawn images and give even more flexibility.

Thanks, I think I understand the direction you mean now.

For player colours, yes: my current prototype stores explicit semantic information rather than trying to recover the player colour from the final anti-aliased RGB pixels. Keeping the traditional PC0–PC7 / second-player colour behaviour also sounds important to me, especially so that 16-bit and 32-bit objects can still be mixed without looking inconsistent.

Your night-image suggestion is particularly interesting.

If I understand it correctly, instead of carrying increasingly complex semantic information for lights, a 32-bit object could optionally provide:

- the normal/day image,
- a night image,
- and player-colour information.

For older paks, or objects without a night image, Simutrans could generate the night representation at load time using the traditional behaviour.

That would give the renderer a much more uniform model while also making the Blender workflow considerably simpler, since the artist can simply render the actual night appearance instead of encoding every light semantically.

It also seems much friendlier for hand-drawn graphics than having several different semantic maps.

I don't want to change revised-11 now that the testing build is published, but I think this is worth investigating as the next architecture step.

I'll make a small isolated prototype and compare the two approaches, particularly memory/pak size, day/night transitions, old-pak compatibility, player colours and the manual pixel-art workflow before proposing anything for trunk.

Thanks — this is exactly the kind of feedback I was hoping to get from the testing release.

[makie]

Your night-image suggestion is particularly interesting.

The question that arises for me is: Can i create a night image from a day image, using GIMP for example, in the same way Simutrans does?
Adding lighting effects to a night image in GIMP is easy. Where I see a problem is in achieving a consistent map at night when using night images from various sources—old ones, new ones, or ones from a different pakset.

[makie]

Revised-11 testing-1
https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/rgba32-revised-11-r12322-testing-1

I miss a compiled makeobj.

[victor_18993]

Quote from: makie on 4/10/2026, 12:29:13
I miss a compiled makeobj.

I'm uploading the compiled version of Makeobj now, I'll let you know, 


cheers.

[victor_18993]

Hi prissi,

I finished the public testing build of the DAY + optional NIGHT prototype based on revised-11:

https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/xr32-prissi-night-image-prototype-01-r12322-testing-1

The short version is: your idea works well, but the measurements point to a hybrid approach rather than replacing the legacy path.

For new XR32 content:
- DAY + optional NIGHT works well;
- traditional player colours are preserved;
- the legacy dusk transition can be matched correctly;
- artists gain much more freedom for lights and night effects.

For old content:
- keeping the existing legacy path is clearly better;
- generating NIGHT images at load time is too expensive in memory and cache rebuild time.

The current measured cost for native DAY/NIGHT content is roughly:
- +75–93% XR32 image memory
- +20–47% cache rebuild cost
- +2–12% pak size
- no measurable per-frame difference in the tests

I also published makeobj for Windows and Linux x86_64, and both produce byte-identical test paks.

Before taking this any further, I think there are three design decisions worth discussing:

1. image identity / merging, because the current merge logic can associate the wrong extra XR32 data;
2. whether the extra NIGHT image memory cost is acceptable;
3. whether the pak format should use an explicit marker rather than relying on filename syntax.

So I would treat this as a public architecture prototype for discussion, not as revised-12 yet.

[prissi]

The old images are kept at 16 bit and not converted to 32 bit on load time? (Or rather lazily when used the first time?) I mean, the night images could be also rendered lazily, since many player do not use night mode.

[victor_18993]

Yes — I checked this directly.

Legacy images are already handled lazily: the original 16-bit pak data stays as-is, and the 32-bit representation is only created in recode_img() the first time the image is actually drawn. Scaled versions are also created on first use and then kept in memory.

The current DAY+NIGHT prototype does not do the same for NIGHT. NIGHT is fully decompressed when the pak is loaded, even if the player never uses night mode.

I made a small local prototype that lets NIGHT reuse the same lazy path as legacy images. The NIGHT data stays compressed after loading and is only decompressed the first time that image is actually drawn at night.

It does not change Makeobj or the pak format, and the rendered output is identical to the current prototype: 63,524 cache comparisons matched exactly, including dusk transitions, player colours, glow outside the DAY silhouette, zooms and MRES.

The main benefit is DAY-only memory use:
- pak64: 15.25 MB -> 8.67 MB (-43%)
- pak128: 57.27 MB -> 30.44 MB (-47%)

After the first night the memory usage becomes the same as before, because the NIGHT data is kept once materialized.

The trade-off is a one-time first-use cost. In the heaviest synthetic case I measured, 1,000 pak128 images reaching their first night together increased that frame from about 43 ms to 210 ms.

So your suggestion is definitely practical, and it reuses an existing engine mechanism rather than introducing a new cache system.

[makie]

I have run the new makeobj with STLAB_XR32_WRITE=1
It doubles the pak size.

In the game it looks all ok (beside the not working keyboard commands as shift 2)

But the graphics are 16 bit.
Look at this screenshot:

It is 4x enlarged for better visibility. It is the seawater. Left is the screenshot and right is how it should look. I am sorry i do right the tile position not exactly. You can see left there are only 16 various blue which leads to steps and areas.

For testing the water.pak
https://makie.de/seawater.zip

[victor_18993]

Thanks for the test, makie — your pak is actually fine.

I checked the full path and the 32-bit data is there and renders correctly. The missing step is that the test build also needs to be started with:

SIMUTRANS_XR32=1

Without that, Simutrans simply ignores the XR32 data and uses the legacy 16-bit images instead, which matches your screenshot exactly.

So this is mainly a documentation issue on my side — I did not make that runtime switch clear enough in the test release.

Thanks also for the seawater.zip and the screenshot; they made this very easy to isolate.

[makie]

SIMUTRANS_XR32=1

ok this is the trick

At a quick glance, everything seems to be working. When zooming in to the map, there are occasional stray pixels at the tile edges. I'm not sure if that was already the case before.

I need to take a closer look at this when I have more time. It seems to me that I'll need to tweak the pak a bit in a few places.

[makie]

I'm a bit disappointed; I had expected more. The 16-bit and 32-bit versions look so similar that I initially suspected something wasn't working. It seems Pumuckl999 rendered most of his graphics in 16-bit color, so there's no difference. Many are dithered too. Though, I've often done that myself to avoid ugly-looking surfaces.

You really have to look closely to spot the differences.
Take a look at the roof inside the red circle in the image; the difference is only really visible when you zoom in. The onion dome above it to the left also has a slightly lighter, greenish sheen. The green area above the text and below the onion dome is smoother as well; however, Pumuckl did some tweaking on the onion dome itself with a pattern to prevent the surface from breaking up.



From my perspective, the 32-bit color is working fine.
I'll let you know if I find any later issues.

Nevertheless, the change is worthwhile because, in the future, there will be no need to account for the problems arising from 16-bit colors.


[DE]
Ich bin etwas enttäuscht. Ich hätte mir mehr erwartet. 16bit und 32bit sehen sich derart ähnlich dass ich anfangs glatt vermutet habe dass etwas nicht funktioniert. Pumuckl999 hat anscheinend die meisten seiner Grafiken auf 16 bit Farben gerendert, so dass kein Unterschied ist. Auch sind viele gedithert. Ok ich habe das auch oft getan um hässliche Flächen zu vermeiden.

Man muss wirklich suchen um Unterschiede zu finden.
Siehe Bild das Dach im roten Kreis. Den Unterschied sieht man erst in einer Vergrößerung wirklich. Auch das Zwiebeldach links darüber hat einen leicht hellern grünlichen Schimmer. Auch die grüne Fläche über dem Schriftzug und unter der Zwiebel ist glatter, aber dass die Zwiebel ein Muster hat, da hat Pumuckl nachgeholfen dass das nicht aufreißt.

Aus meiner Sicht funktioniert das mit den 32 Bit Farben.
Wenn ich noch einen Fehler finde melde ich mich.

Trotzdem lohnt die Änderung, weil man in Zukunft nicht mehr Rücksicht nehmen muss, auf die Probleme die sich aus den 16 Bit Farben ergeben.

[makie]

Another comparison of the cigarette factory.
Left: 16-bit; right: 32-bit.
At the bottom, I smoothed out the dithering using a blur effect.
The magnification is 8x, without anti-aliasing.
The small is 1x