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

[victor_18993]

XR32 testing-3 released — Dirty-region optimisation and rendering fixes

Hi everyone!

Following the recent discussion with prissi about SDL2/SDL3 texture updates, I've completed another round of development and validation of the experimental XR32 renderer.

XR32 testing-3 is now available:
https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/xr32-prissi-night-image-prototype-01-r12377-testing-3

The main improvement is the implementation of partial framebuffer uploads using dirty regions, instead of transferring the entire 32-bit framebuffer every frame.

At 1920×1080, this reduces texture transfers from approximately 7.9 MB to 0.15–0.45 MB per frame in scenarios where only part of the screen changes.

Across the measured scenarios, this resulted in CPU frame-time improvements ranging from 0.06 to 5.5 ms. When the entire screen changes, there is little or no benefit, and some scrolling scenarios show a small regression.

The investigation also helped identify and correct three additional XR32 rendering issues:

• Incorrect alpha blending during SDL presentation.
• Missing full-screen invalidation during day/night and company-colour changes.
• A missing dirty-region invalidation in
  
  Code Select Expand
  draw_rect.

Validation results:

• 309/309 automated tests passed.
• No visual differences in the verified framebuffer/presentation tests.
• Windows SDL2 and SDL3 tested.
• Linux SDL2 and SDL3 tested under WSLg (X11/Wayland).
• No measurable memory regression.
• Previous XR32 fixes remain intact.

The official 16-bit renderer is unchanged, and XR32 remains fully experimental. Native Linux desktops, macOS, Android, ARM and HiDPI configurations still need additional validation.

Regarding the original SDL discussion, my measurements continue to favour the existing framebuffer + partial

Code Select Expand

SDL_UpdateTexture approach over direct rendering into locked streaming textures on the tested hardware.

Thanks to prissi for suggesting this investigation, and to tomado for the useful historical context regarding the rendering architecture. Both contributions helped clarify the trade-offs and led to a measurable improvement in XR32.

I'm now investigating another architectural limitation: generating 32-bit water graphics for sloped coast tiles, which currently still rely on the traditional 16-bit path.

As always, feedback and testing on different platforms are very welcome!

[victor_18993]

XR32 — Exploring new graphical possibilities for Simutrans artists



Hi everyone!

Following the recent XR32 testing-3 release, I've been exploring what native RGBA32 artwork could offer to Simutrans artists and pakset creators.

The goal is not to change Simutrans into a 3D game or replace its traditional visual style. Instead, I want to explore how richer colours, more precise alpha transparency and optional DAY/NIGHT artwork could enhance the existing isometric graphics.
I've prepared six original pak128-style sprite examples, each with separate DAY and NIGHT images.



These examples explore glass-roofed structures, transparent water details, vegetation, illuminated windows and signal lights.
The source package includes 12 RGBA PNG files, DAT definitions and reproducible generation code. The image files have been checked, but compilation with XR32 makeobj and in-game rendering still need to be verified.

There are also some interesting possibilities for future artwork, including softer smoke sprites, more detailed colour gradients, transparent glass and lighting effects painted directly into DAY/NIGHT images.

It's important to distinguish these from dynamic lighting, volumetric smoke or GPU effects, which are not implemented by XR32. The traditional 16-bit renderer already supports transparency and special lighting colours; XR32's advantage is preserving richer source colour and alpha information.

I would particularly welcome feedback from pakset artists:

• Would optional DAY/NIGHT artwork be useful for your projects?
• Which types of sprites would benefit most from RGBA32?
• What requirements should the image format meet to remain practical for artists?

XR32 remains experimental, and backward compatibility with existing paksets remains a priority.

Español: Estoy preparando ejemplos gráficos para explorar las posibilidades de XR32: mayor precisión de color, transparencia RGBA y versiones gráficas independientes de día y noche. Son recursos experimentales; todavía deben comprobarse dentro del juego.

日本語: XR32の描画機能を活用した、pak128風の画像サンプルを制作しました。RGBA32による豊かな色表現、透明度、昼夜別の画像を紹介しています。現在は実験段階で、ゲーム内での動作確認はこれからです。日本のpakset制作者の皆さんからのご意見も歓迎します！

Thanks to everyone contributing feedback and technical suggestions to the project!

[prissi]

Simutrans supported transparent colors since several versions, and pak192 made ample use of it, e.g. for station roofs. Or the transparent steam of engines, even in pak64.

I think a separate night graphic adds a lot of freedom to the visual design and might be useful even for the old graphics.

For if you need transparent graphics, 2012 Hochbahn or 2000_track_hall in pak192. That could look nicer in 32 bit.
https://github.com/Flemmbrav/Pak192.Comic/tree/Standard/pakset/infrastructure/track/images/station

[Andarix]

Are the themes included in Simutrans created in 32-bit in their test versions?


Are you sure the files for testing-3 were newly created today? Because the date of the files in the zips is November 30, 2026.

[victor_18993]

For now, everything being tested in-game is synthetic textures generated by AI to make 32-bit demos. I'm going to see if any artist interested in trying out 32-bit would like to participate, since I've reached a point where I need to test with material created by artists, as AI won't give me enough quality synthetic models.

[Andarix]

Most graphics from the last 20 years or so are likely 24-bit without alpha.

It's questionable to what extent such graphics can be improved with alpha at a reasonable cost.

It's also questionable to what extent 24-bit graphics are degraded by reducing them to 16-bit. However, this would probably be noticeable in the details and especially with larger packsets. With 64 packsets, the difference will hardly be noticeable. Here, better scaling during zooming will likely be necessary. I can't say whether zooming benefits from 24-bit.

[makie]

It's questionable to what extent such graphics can be improved with alpha at a reasonable cost.

In Pak128.german:
All trees have shadows with an alpha channel.
All clouds of steam and smoke are transparent.

I've added / changed that. Previously, there were dithered black pixels. I added an alpha channel and then smoothed out the pixel structure using a blur effect. This is relatively easy to do in GIMP.

That looks significantly better, and not so crumbly.

[victor_18993]

For now, all benchmarks are being run on pak128German based on what our fellow member pointed out—it seems to be the pak with the most images adapted for a new system, and there are also lots of buildings from OTRP, etc... but the official one right now for all my benchmarks is Pak128German.

Recently I added pak192Comic to use 32-bit images, but I haven't finished testing yet. There are still about 6 hours of testing left on pak128German, which will give me the benchmark results so I can let you know if a new version of XR32 will be released.

Hopefully tomorrow I can post new data, and with any luck, if there are significant improvements, a new version.

[victor_18993]

XR32 testing-4 released — 32-bit water now works on sloped coasts

Hi everyone!
I've just published XR32 testing-4, another experimental build of the 32-bit graphics prototype for Simutrans.

This update addresses an issue we've been investigating: although open water and flat coasts could already use RGBA32 graphics, the water on sloped coast tiles was still generated from the legacy 16-bit sea image.

What's new in testing-4?

The water on sloped coasts now uses the pakset's RGBA32 sea graphics, including during day/night transitions and at different zoom levels.

I've also introduced a small shared cache for the coast composition process. This reduced the reconstruction cost by approximately 4–5 times compared with the initial, unpublished implementation.

The 16-bit renderer remains unchanged, and existing paksets without 32-bit water continue to use their previous rendering behaviour.

Visual comparison
The following screenshot uses a deliberately magenta test sea to make the difference easy to identify. It is a real engine capture, not an AI-generated illustration.

https://github.com/Dkijas/simutrans-true32-renderer/raw/xr32-prissi-night-image-prototype-01-r12377-testing-4/docs/images/testing-4/xr32-r12377-testing-4-coast-mutant.png[/img[/url]]

Known limitation
At zoom 2/1, a few isolated sand-coloured pixels may appear in the water next to sloped coasts. This is a known issue (A11/H1) and will be investigated separately.

https://github.com/Dkijas/simutrans-true32-renderer/raw/xr32-prissi-night-image-prototype-01-r12377-testing-4/docs/images/testing-4/xr32-r12377-testing-4-h1-2x1.png[/img[/url]]

Testing and performance
The implementation passed 309 automated tests, along with graphical and stability checks on Windows SDL2/SDL3 and Linux under WSLg.

Typical frame times showed no measurable change. Some frames that rebuild coast water still have additional costs, particularly when zooming. Native Linux, macOS and ARM have not yet been certified.

Download testing-4:
https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/xr32-prissi-night-image-prototype-01-r12377-testing-4
To enable RGBA32 rendering, launch simutrans-rgba32 with SIMUTRANS_XR32=1.

A pakset containing actual 32-bit water data is required to see this particular improvement; the bundled test kit does not include one.

This remains an experimental build, not an official Simutrans release.

I'd also like to thank prissi, Markus and everyone who has contributed feedback. The discussions about transparency, lighting, NIGHT artwork and artist workflows have been particularly useful.

My next focus is validating real RGBA32 artwork from existing paksets, including Pak192.Comic, while preserving the graphical features that Simutrans already supports.

As always, feedback and testing are very welcome!

[prissi]

Why not using the same drawing as for the 16 bit water, as this is already animated using the transparent slopes and just uses drawing order? Blending is needed for the climates too, but I think you are already using that in the ground desc anyway.

[victor_18993]

Why not using the same drawing as for the 16 bit water, as this is already animated using the transparent slopes and just uses drawing order? Blending is needed for the climates too, but I think you are already using that in the ground desc anyway.

Hi Prissi,
Thanks for the suggestion! That's a very good point, and it's particularly relevant to the coastline zoom issue we're currently investigating.

XR32 already reuses part of the existing system, including the slope geometry, masks and water animation structure.
The main difference is where the actual water colours come from.

In testing-3, the generated sloped-coast tiles still used the legacy 16-bit water texture, even when the pakset provided an RGBA32 version. This caused visible colour differences between open water and sloped coastlines.

Testing-4 addresses that by deriving those tiles from the original RGBA32 water artwork while retaining the existing slope geometry.

However, your suggestion raises an interesting question: could we reuse more of the original transparency and drawing-order mechanism instead of generating additional composed images?

That might also help with the remaining zoom alignment issue, although we'd need to verify the visual results and performance before changing the implementation.

You're also right about climate blending. The existing blending mechanisms are reused, but some internally generated terrain transitions still operate with 16-bit image data. Extending those paths to preserve RGBA32 precision is on the roadmap.
I'll include your suggestion in the A11/H1 investigation.

Thanks again! These kinds of observations are extremely valuable for keeping XR32 as simple and maintainable as possible. 🙂

[makie]

The ground.ClimateTexture are still processed as 16-bit.

The same applies to the ground.LightTexture.
Especially in these cases, the effect is striking. The steps are clearly visible.


For tests this is a pak128.german with 32bit and removed dithering.
https://pak128-german.de/PAK128.german_2.5_beta.zip

[victor_18993]

The ground.ClimateTexture are still processed as 16-bit.

The same applies to the ground.LightTexture.
Especially in these cases, the effect is striking. The steps are clearly visible.


For tests this is a pak128.german with 32bit and removed dithering.
https://pak128-german.de/PAK128.german_2.5_beta.zip

Hi makie,
Thank you! This is a very useful observation, especially because you've provided a real pakset where the colour banding is clearly visible.

I've checked the current XR32 ground texture generation path, and you're right: ClimateTexture and LightTexture are still involved in 16-bit processing when the game generates ground tiles.

Testing-4 introduced a specific RGBA32 path for sloped-coast water, but the equivalent work for climate textures and slope lighting has not been completed yet.

🎨 This is particularly interesting because it could produce a much more noticeable visual improvement than simply preserving the original colours of individual sprites.

I've added both areas explicitly to our next graphics milestone (A12):
🔹 RGBA32 climate texture composition.
🔹 RGBA32 slope lighting and texture generation.
🔹 Preservation of existing terrain geometry and compatibility.

Your Pak128.German test resource gives us a very useful starting point for reproducible before/after comparisons.
The immediate priority is finishing testing-5, but A12 is becoming one of the most important next steps toward a visible graphics upgrade.

Thanks again for your contribution and for providing a practical test case! 🙂

[victor_18993]

Hi makie! 👋
Thank you again for pointing out the colour precision loss in

Code Select Expand

ClimateTexture and

Code Select Expand

LightTexture, and for providing a real Pak128.German test case.

🎨 Good news: your observation has already led to a working XR32 improvement!

I've completed the first A12 implementation and its technical validation, with some very encouraging results:

✅ ClimateTexture and LightTexture now use their RGBA32 data when generating terrain tiles.
✅ All 520 generated terrain tiles match an independent 8-bit reference model, pixel for pixel.
✅ Visible colour banding is greatly reduced:

• One slope increased from 198 to 1,820 colours.
• Snow increased from 16 to 480 colours.

✅ Terrain geometry, existing 16-bit graphics, company colours and previous XR32 corrections remain unaffected in the tested cases.

⚠️ One interesting difference: the terrain is now noticeably brighter, particularly the snow (approximately +8 to +13 RGB levels per channel). This comes from removing the old 5-bit colour truncation.
The climate, snow and beach transition masks still use their traditional 32 blending levels. Improving those separately remains on the roadmap.

Performance is unchanged in normal static or scrolling views, although some lighting and zoom transitions require slightly more processing.

🔬 Current status: CERTIFIED WITH LIMITATIONS — local candidate only. Not yet released.
I'd especially appreciate your artistic feedback on the brighter terrain. Our goal isn't simply to increase the number of colours, but to preserve the original artistic intention as faithfully as possible.

I'll share real in-game before/after comparisons once the testing-6 preparation is complete.

🙌 Thank you for helping us identify an improvement that could make a genuinely visible difference to Simutrans!

[makie]

I'd especially appreciate your artistic feedback on the brighter terrain. Our goal isn't simply to increase the number of colours, but to preserve the original artistic intention as faithfully as possible.

I have reworked ClimateTexture—and not just by removing the dithering. Without this overhaul, the effect would barely be visible. I'm curious myself to see how it will look as a complete map; I might need to refine it further. It's quite possible that it will end up being brighter or more colorful.

In general, 32-bit color is a great thing: it offers more creative freedom, and, importantly, it eliminates the need for dithering—which otherwise compromises the detail and sharpness of the graphics.

However, the graphics do need to be adapted to take advantage of these new possibilities.

[victor_18993]

Hi makie! 👋

Thanks for the update! It's great to hear that you've already reworked ClimateTexture and may continue refining it.
As promised, I've prepared some real in-game comparisons showing the improvements from our latest XR32 work.

🎨 A12 — ClimateTexture and LightTexture in full 8-bit colour

The implementation is now technically certified on Windows SDL2 and SDL3, with some documented limitations.

The results are encouraging: the generated terrain no longer suffers from the previous 5-bit colour quantisation, gradients are noticeably smoother, and the original colour precision is preserved.
https://files.simutrans-germany.com/upload/comparison.rar
I've attached five comparisons:

• Slopes: improved colour gradients and reduced banding.
• Snow: differences in brightness and colour reproduction.
• Steep snow slopes: a closer look at the brightest areas.
• Climate transitions: the current behaviour with the existing blending masks.
• Night rendering: how the new terrain composition behaves under night lighting.

One particularly interesting finding is that A12 produces brighter terrain, especially snow. We verified that this comes from removing the colour precision loss in the old renderer, rather than introducing additional brightness.

There is one detail worth discussing: four of the steepest illuminated snow tiles become pure white. This is caused by the combination of the pak's snow texture and light map. It was already present in the previous rendering path, although A12 makes the brighter result more apparent.

Since you've been working on ClimateTexture yourself, I'd really appreciate your artistic perspective:

• Does the new rendering look closer to what you originally intended?
• What do you think about the snow and the illuminated slopes?

• Would you prefer adjusting the artwork, or does the more accurate colour reproduction look right to you?

The transition masks still use 32 blending levels, and A12 remains an unpublished local candidate for testing-6.
My goal is not simply to display more colours, but to ensure that the renderer respects the work of Simutrans artists as faithfully as possible.

Many thanks to you and the Pak128.German contributors for the artwork and the opportunity to test these improvements. Your feedback is genuinely helping shape XR32! 🙂

[makie]

This looks good—just as I had imagined it.
Regarding the snow on the sun-facing slopes: it's true that the snow appears brilliantly bright in the sunlight. We have to see how it looks on a whole map. If it's too bright, we can simply darken the snow texture; We should not intervene from within the program.
Furthermore, it is also possible to darken the Light Texture.

[victor_18993]

Hi makie! 😊

Thank you for your feedback! I'm glad the results are close to what you expected.

I completely agree with your approach. The renderer should preserve the original artwork as accurately as possible, rather than artificially adjusting brightness to compensate for the old 16-bit limitations.

If the snow appears too bright when viewing the entire map, adjusting the snow texture or LightTexture in the pakset would be the more appropriate solution.

This is precisely what we're trying to achieve with XR32: giving artists greater control over colour, lighting and gradients without the engine losing precision during rendering.

For now, I'll keep the A12 implementation unchanged and proceed with the experimental testing-6 release.
Your observations have been extremely valuable in guiding this development. Thanks again for your contribution! 🎨

[victor_18993]

🚀 Simutrans XR32 — Testing-6 is now available!

I'm pleased to announce that XR32 testing-6 (r12377) has been published as an experimental pre-release for Windows and Linux!

🔗 Download:
https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/xr32-prissi-night-image-prototype-01-r12377-testing-6
🎨 What's new — A12: 8-bit generated terrain
Following makie's observation that

Code Select Expand

ClimateTexture and

Code Select Expand

LightTexture were still being processed at 16-bit precision, we've implemented a new RGBA32 terrain composition path.
This allows the engine to preserve much more of the original artwork's colour information when generating terrain, slopes and snow.

The results are encouraging:
✅ ClimateTexture and LightTexture now use their XR32 colour data.
✅ Much smoother terrain gradients, with substantially less colour banding.
✅ Terrain displays approximately 2–4 times as many colours in the tested Pak128.German scenes.
✅ All 520 tested generated terrain tiles match an independent 8-bit reference model, pixel for pixel.
✅ The traditional 16-bit renderer, existing XR32 format, company colours, coast rendering and previous fixes are preserved.
The terrain may now appear brighter, particularly snow, because the old 5-bit colour truncation is no longer applied. This represents the source artwork more faithfully, although the artistic evaluation of complete maps is still ongoing.

🖥� Available builds

Windows x64

• SDL2 — certified with limitations.
• SDL3 — certified with limitations.

Linux x86_64

• SDL2 — experimental, not certified.
• SDL3 — experimental, not certified.

The release also includes makeobj for both platforms, source code, patches and documentation.
⚙️ How to enable XR32
Windows CMD:

Code Select Expand

set SIMUTRANS_XR32=1Linux:

Code Select Expand

SIMUTRANS_XR32=1 ./simutrans-rgba32For creating XR32-enabled pak files with makeobj:

Code Select Expand

STLAB_XR32_WRITE=1A compatible pak containing XR32 image data is required to see the improvements. No pakset is included in the release.
⚠️ Known limitations

• Climate, snow and beach transition masks still use 32 blending levels.
• Changes of lighting and zoom can require slightly more processing when rebuilding terrain images.
• Some strongly illuminated snow slopes may become pure white.
• Linux builds have not undergone full graphical certification.
• XR32 remains experimental and is not yet integrated into the official Simutrans trunk.

Please use a separate installation and back up your savegames.
🙌 Acknowledgements

Special thanks to makie, whose observations and Pak128.German artwork helped identify and validate this improvement, and to prissi for his technical direction and contributions to Simutrans.
Thanks also to the pakset artists, the Japanese Simutrans community and everyone contributing ideas, testing and feedback.

💬 Feedback welcome!
I'd particularly appreciate feedback on:

• Terrain gradients and climate transitions.
• Snow brightness and illuminated slopes.
• Performance during zoom and day/night changes.
• Any Windows or Linux rendering issues.

Please include your operating system, SDL version, pakset and screenshots when reporting a problem.
XR32 is gradually moving from a working 32-bit rendering prototype towards a more complete graphics pipeline.
Thank you all for helping us get there! 🙂

[makie]

⚠️ Known limitations

• Climate, snow and beach transition masks still use 32 blending levels.

Either it works with more than 32 levels, or 32 levels are sufficient for this purpose. In any case, the result is fine as it is. I wouldn't change anything.
--------------------------
LightTexture

Terrain edges are OK, however corners in terrain edges are processed using 16-bit ClimateTexture and also 16-bit LightTexture .

[makie]

I ran a test on the overexposed, snow-covered slopes. I reduced the contrast of the light texture until structures on the sunlit slope became visible. It doesn't look good. At least on my screen, the contrast range isn't sufficient for a visually satisfactory result. The result might be better on an HDR screen, but who has one of those? In any case, it's unnecessary for playing Simutrans.

On the other hand, the snow slopes in Simutrans have always been overexposed, and nobody has complained.
I'll leave it as is.

[martin509]

On the other hand, the snow slopes in Simutrans have always been overexposed, and nobody has complained.
I'll leave it as is.

If I'll chime in, I'll say that I've definitely seen comments to the tune of "I tried Simutrans, but the [default pakset] graphics were eye-searing so I gave up and uninstalled" before. One reason we don't hear complaints may be because the people in the community giving feedback are going to be the ones who stuck around and either got used to it or moved to a pakset that's gentler on the eyes, and not the ones that uninstalled after five minutes.

I'm curious how the snow looks if you leave the contrast alone but turn down the overall brightness, if you haven't tried that already.

[makie]

if you leave the contrast alone but turn down the overall brightness, if you haven't tried that already.

That's not possible. The brightness and contrast of all the more than a thousand objects are coordinated to fit together.

What's possible: Each player can change the brightness and contrast of their display. This can be done either directly on the monitor itself or in the screen settings of the respective system.