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.