Is it possible for us to benefit from DLSS5?

[Mishasama]

I glanced at this post and it suddenly reminded me of the recently released DLSS5. Could we introduce this technology to directly improve overall image quality? Perhaps this would allow us to achieve photorealistic image quality without spending too many resources on texture? 😝

[victor_18993]

That's an interesting idea!

DLSS 5 is certainly an impressive technological development, and I think it's worth keeping an eye on how AI-assisted rendering evolves.

However, Simutrans currently uses a traditional 2D software rendering architecture, while DLSS 5 is designed around GPU-based rendering pipelines with additional scene information. Integrating it would therefore require significant architectural changes rather than simply enabling a new feature.
That said, I believe there are interesting opportunities to modernise Simutrans' graphics engine in the future, including GPU acceleration, improved scaling and potentially AI-assisted image enhancement.

Personally, I think any graphical evolution should preserve Simutrans' distinctive visual identity, remain optional and avoid compromising compatibility with older hardware.

We're already working on modernising parts of the rendering architecture, so discussions like this are definitely welcome!

Thanks for bringing it up!

[prissi]

Simutrans must run on many platforms, from a mobile phone to a high end PC. But mostly, it runs on normal PCs, and laptops. The latter are better suited for Simutrans, since the have a higher memory bandwidth to the screen than a PC with a dedicated graphics board. But Laptops and phones usually do not feature powerful GPU, mostly since phones can get away with courser displays on the super-dense screen hiding anyway finer details. Well, and Laptops are made to save power, so those GPU are just the level to meet Windows certification (for the bread and butter ones).

Not even mentioning the problem to get this portable.

However, the main problem with any isometric engine is that the smallest possible movement is 2x horizontally and 1px vertically in N, S, E, W direction. Since Simutrans just enlarges the images when zooming in, the visual steps become larger by the zoom factor. For smoother movement, one would need to do smaller internal steps (not 127 but 32767 per tile) so that zoomed out images can still move with 2px/1px steps and would make the zoomed inview appear much smoother.

And, of course, one could better zoom in than just doubling pixels are the current routines do. But zooming in image is a rare step, and using an expensive algorithm should be fine, since the results are cached.

Thus, for improving the appearance of Simutrans:
- Finer internal steps (xoff and yoff in simobj.h to sint16) and change the moving logic accordingly and convert old games. But onlz relevant for pak192 and larger at 4x zoomed in.
- Better zoom in interpolation (Bicubic Interpolation or Bresenham-based / Directional-Interpolation or even advanced Weighted Essentially Non-Oscillatory methods)

Those two are quite independent. Adding bicubic zooming is rather trivial, there are lot of examples. Maybe I do this tonight.

[makie]

See other posting:

In 2022, I experimented with a "pak512.german" set. To do this, I upscaled the "pak128.german" using anti-aliasing. I also added individual objects—such as the E69 locomotive, the "Adler" train, and various pedestrians—in higher resolution. I was curious to see how it would look in 32-bit color, ...... . .. . .

[martin509]

I would be very much opposed to DLSS5 support, or really any AI upscaling period. Simutrans looks best when it is pixel art, and upscaling usually destroys any charm that pixel art has. Even as an option that can be disabled, I don't support adding a "make the game uglier" button.

Plus there's the massive technical overhead for a game that should be simple. Even basic OpenGL hardware rendering with no visual changes is not a small project and carries technical risk, and I'm not sure if rendering is even much of a bottleneck on performance.

[Mishasama]

Simutrans looks best when it is pixel art, and upscaling usually destroys any charm that pixel art has. Even as an option that can be disabled, I don't support adding a "make the game uglier" button.

Just think about something like PAK4096.

This is a great opportunity to expand Simutrans's audience. Especially for an open-source project, it's difficult to secure sufficient development and maintenance resources without attention. You need to provide compelling reasons for people to contribute voluntarily, rather than just hoping for favors.

Simutrans's multi-PAK architecture is well-suited for presenting visuals in different styles. As for hardware requirements, this issue already exists and is unrelated to whether or not the more expensive DLSS5 is introduced. For example, PAK256 cannot run smoothly on some older Pentium 4 processors. Even with the introduction of DLSS technology, we will not, and need not, abandon classic styles such as PAK64.

[prissi]

pak256 not running on old processors is due to Extended's horrible programming wasting so many resources and pentium4's poor multithreading (if any at all). A pak256 for standard would run smoothly since it is internally the same as a zoomed in pak192 at the second zoom level. (Especially if compiled without multithreading.) Just for fun, I tested this on a N4100 celeron with 6 GB RAM which is about twice the speed of a pentium4. It coulod run the opening game of pak192 at almost any speed.

Moreover, running smoothly also depends on screen size. But with larger pak sizes, the CPU has to render LESS tiles per frame at the same screen size, so it runs a little faster when zoomed in until memory swapping starts. (And apparently crashes if running out of memory, see the above.)

pak4096 is likely not happening, since the would increase the main memory consumption 1000 times compared to pak128. Unless you have 2 TB of main memory, it will be no fun. No, at a certain point, one has to go 3D for further zoom.

[Mishasama]

The Pentium 4 cannot use more than 4GB of RAM because it is a 1C1T 32-bit CPU. So... I think it can basically only open games, but not really run smoothly on a typical multiplayer map, or even playable many years later. 🤔

Reflecting on DLSS technology, I think even a PAK4096 wouldn't actually use 1000 times the resources, because it only looks like a 4096. It's more like a PAK256/512 that's visually equivalent to a PAK4096...
While DLSS 5 is currently primarily used for 3D rendering, by the time we're ready to introduce DLSS technology, it might already be the era of RTX 8900 paired with DLSS 10. I imagine it will definitely support mixed 2D/3D rendering by then. 

Besides, I just asked him to use an analogy to illustrate a readily available comparison... Why did you start calculating the memory usage required for 4096 so seriously...?

[prissi]

It does not take long to calculate, it's 1024 times that of pak128 (given the same number of images). And Simutrans 32 bit can only handle up to 3 GB of memory (or only two, depending on OS). It did run on 2 GB quite well under XP, and the code has saw sustancially improvement since then in memory handling and list iterations. No, a Pentium 4 with 2 GB RAM under Linux or any OS which does not hog all the memory should handle games fine, especially if compiled for single threaded. I mean the pak64 game server has just one virtual core, 1 GB of memory and a 20 GB hard disk and handles the German Forum too and some other services. The apache web server consumes more resources than simutrans on that machine. Compiling Simutrans on the server feels like back to my netbook from 2010, about a quarter of an hour.

The only thing that brings such old CPUs down is if someone idiotically requests 60 fps which makes no sense for multiplayer games or isometric engines. Memory and simulation cycles should not be an issue otherwise.

[Mishasama]

But as a server, its main function is to calculate the simulation data, so it doesn't need to handle the heavy rendering work, right?

However, considering the practicalities, probably no one uses such old hardware to play games anymore, right? It's not like it's some kind of retro gaming console...


In any case, players should not need to worry about technological innovations bringing about disruptive changes. 

[victor_18993]

I still need to spend some more time reviewing the documentation on DLSS 5.

The truth is that, at the moment, all graphics rendering in Simutrans is handled by the CPU. In other words, there is no GPU acceleration.

However, although I originally started the 32-bit graphics project as a migration, it also opens up possibilities for offloading some of the workload to the GPU, allowing it to handle rendering in real time or through other approaches. Of course, this is far from simple, and there are several technical challenges to overcome.

The project that actually covers GPU acceleration more directly is SDL3. I did carry out some experiments about a month or two ago, although I cannot remember exactly when, and shared the results with prissi.

These experiments are quite complex, particularly because the SDL3 backend is still being stabilised. Nevertheless, GPU acceleration is clearly a possibility worth exploring.

That said, I never tied the SDL3 project to any particular technology. I simply started integrating it into Simutrans to provide a more modern backend that would allow us to address a number of historical issues, especially those that emerged with touchscreen versions, along with several other longstanding problems.

My broader goal was to achieve a technological step forward that would allow Simutrans to remain compatible with modern software and operating systems for at least another generation.

There is also one fundamental principle behind the SDL3 project: maintaining full backward compatibility with existing paksets.

I consider this extremely important because I do not want Simutrans to lose its history or the enormous amount of work contributed by so many artists over the years.

Just because we now have access to significant computational capabilities through LLMs does not mean we have the right to throw away all the work that was done in the past.

In fact, a great deal has already been modernised. We have also managed to reduce a considerable amount of technical debt and fix many longstanding bugs. Personally, I believe this has been AI's greatest achievement in the project so far.

I understand that the use of AI creates high expectations, but I think we need to remain cautious, make sensible decisions, and carefully evaluate the consequences of the changes we introduce.

Perhaps I'm rambling a little here!

Unfortunately, I haven't had much time lately to contribute new developments to the project because of work commitments.

I hope I'll be able to return to contributing more actively within the next few days.

[Mishasama]

Of course, we cannot simply discard the work of the past! The progress of civilization can never be separated from the accumulation of history.

Given the current efficiency of AI in writing code, can we imagine that in the future we might have a Simutrans 2?
A game that combines traditional diagonal perspectives with modern 3D perspectives, like the one called "Evoland," where new visual styles, effects, and even music are gradually unlocked as the game progresses through different eras, would be absolutely amazing!

I don't quite understand why people worry that introducing new technology will lead to incompatibility with existing content. New things don't necessarily have to be replacements; they can also serve as supplements and extensions to the existing content, just like DLC for most games.
As long as we don't let history become a mountain of shiit code, everything will be fine...😂


On a side note: I enjoy chatting freely with everyone; I don't mind how long-winded you are, as long as you remain open-minded and inclusive, you can speak freely, it's the collision of different ideas that sparks new ideas.
And listening to you tell the stories behind the development is very interesting to me. No matter how much you say, I'm listening. 😉

Perhaps these stories can be shared across various platforms in the future as development narratives of Simutrans, serving as light entertainment while people await new versions. I think this might also increase our activity, boosting our visibility and attracting more people to participate in the project. 😋

[prissi]

Hardware accelerate SDL3 rendering was about 4 times slower than the classic CPU based rendering in the result I saw. I guess this is due to threaded rendering of the maps while the GPU path probably cannot multithread due to directional clipping etc., at least not with the curretn SDL code.

This weekend's experience with AI supported coding was not so great. AI introduced subtle errors all the time or reversed it conviction when confronted. In the end, it is still a probability parrot. For debugging by human brain was better than whatever the AI suggested (or insiting that there was no error because of false primary assumption on the internal coding of images). Might be due to the problem or my inability to use the tools, but AI is a little overhyped for me. (Btw. Claude writes dead ugly C code like a human beginner, saving on every bracket and semicolon.)

Your milage may vary. I found that AI is very useful for a bash script or getting suggestions. But without a human in the loop, this would works as well as taking every patch before finished for Experimental had. Apart from burning the planet for our entertainment.