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

[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.