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.