[Suggestion] Drawing as night mode in under-ground tile

[Takamaro]

Hello, everyone. I suggest the improvement of expression of inner-tunnels way.
How about drawing as night-mode at under-ground way tile?

And I describe about detail of improvement of under-ground expression.
1. Drawing as night-mode(darken) always if tile is under-ground.way.
2. Drawing as day-mode(lighten) always if tile is under-ground way with station.
Maybe, It'll improve expression of your subway greatly.

Thanks.

[Leartin]

I assume you want the trains within the tunnels to be in night mode? Perhaps even the tunnels in darkness 8, but only 6 if there is a vehicle on the tile, and 4 on the tile in front of the train since it's illuminated by headlight?

...but night mode always affects the whole screen. It's turned off if you are in underground mode, but that again is for the whole screen. If you slice the landscape, tunnels follow the same day-night-pattern as above ground. So I very much doubt it could be done on a per-object basis that easily.

[Takamaro]

Thank for your early replaying, Leartin.

I read your comments, and I seemed to be difficult to applying my idea....

I just want to illuminate vehicles' headlights and windows running the tunnels, instead of tile-based day-night mode.
I don't care that make darken and illuminated vehicle image, so image replacing function on specified-conditions(for example, underground way and not existing station) is also OK.

I have poor knowledge for programming, but I have many methods of drawing addon images.
I hope for ideas for realizing about illuminated lights on the tunnels, everyone.

[Ters]

I see no way of doing this short of redoing the entire graphics engine in Simutrans. That could be a good idea which opens up for other things as well, but it is a massive undertaking. Not just writing it, be ensuring performance on a range of different machines. Simutrans doesn't so much darken images as darken the colors themselves, leaving only GUI colors unaffected, while the few light-colors get a slightly different treatment (often getting brighter at night due to being switched on). A vehicle can't be white at night, basically because the color white simply does not exist anymore, it has become gray.

[Takamaro]

Thanks, Ters.

I understand applying my idea require too much time and effort. I'll implement better subway scene by devising of expression of add-ons.

Thanks, everyone!

[prissi]

Drawing things in day-mode when the landscape is in Night mode is possible (like the GUI or vehicles in depot). So in principle an ugly hack is possible, that sets everything in night  mode in sliced view and then just draws above tiles in day mode. This will have troubles though around dawn and dusk. So without further extenst\ion I think this is unlikelz.

However, switching to night mode when undergound is something on could consider.

[Ters]

The GUI doesn't use the cached images. My worry is that this might not be fast enough when drawing potentially very many vehicles in the map, compared to the few ones in the GUI. The non-cached path has a warning that it can't be used in multithreaded drawing, which I think is on by default now. Even then, it is only for drawing something as always at full illumination, while sliced mode will need full illumination, no (or rather ambient only) illumination and day-night cycle animation. The code only supports full illumination and day-night cycle illumination, which is what I think is meant by the dawn/dusk troubles.

This is something my attempt at hardware accelerating the rendering would solve quite easily, but it was impossible to get it to run fast without being able to cache unchanged scenery in VRAM. Figuring out when scenery changes is however difficult in Simutrans today. It might also require so much more memory per image, that the image count limit might have to be lowered from 64k.

[DrSuperGood]

At some stage Simutrans could do with a proper 3D accelerated graphic engine. Yes it may be slower but that can be a worth while trade off if it could allow currently impossible visuals such as using isometrically projected 3D models instead of sprites (smooth corner rotation support) or much more advanced lighting or shading effects. However a big issue is writing such an engine to be fully backward compatible with existing pakset files without performance turning to mud. Such project would also be massive as it would require rewriting a huge part of Simutrans as well as significantly raising the system requirements (need reasonable GPU).

[Ters]

The first big hurdle isn't the sprites, it's the terrain. You can't generate terrain from karte_t every frame, but there is, as far as I have been able to figure out, no easy way to know what, or rather where something, has changed in karte_t since last frame either. There are lots of mutators in that class. Vehicles must be treated separately.

The second biggest problem is getting all the images into VRAM. With the then limit of 64k images, I figured pak64 might just barely fit without fancier tricks that I know about on what I considered quite high-range a few years back. That might probably be low-end now. Essentially, it involved support, and space, for three 16kx16x textures, plus frontbuffer, backbuffer, z-buffer and alle the vertex buffers.

As long as free rotation is disabled, compatibility with existing pak sets shouldn't be much problem. The main issue is avoiding z-fighting.

[DrSuperGood]

The second biggest problem is getting all the images into VRAM. With the then limit of 64k images, I figured pak64 might just barely fit without fancier tricks that I know about on what I considered quite high-range a few years back. That might probably be low-end now. Essentially, it involved support, and space, for three 16kx16x textures, plus frontbuffer, backbuffer, z-buffer and alle the vertex buffers.

Simutrans should not be loading all graphics into memory. Especially for a pakset as large as Pak128 Britain Extended being played on a server like Bridgewater Brunel most of the graphics will not be seen by the player in a 6 hour play session.

[Ters]

Simutrans should not be loading all graphics into memory. Especially for a pakset as large as Pak128 Britain Extended being played on a server like Bridgewater Brunel most of the graphics will not be seen by the player in a 6 hour play session.

A public player in timeline-less mode can build anything at any time. This may even be the same players who want the fanciest graphics the most in the first place.

[Leartin]

Wouldn't you be able to steal plane shadows for underground vehicles, but place them right in front of the object? If you poke holes for lights, the result should be very similar to the object in night mode. Gradual change is not needed. I think it only needs to be done for vehicles, since they move from underground to above ground. Anything that's always underground can just be designed dark.

isometrically projected 3D models instead of sprites

Whenever something like this comes up, I always start to wonder if it wouldn't be easier to take a game like Mashinky and add Simutrans-like gameplay, since a gradual transistion seems impossible anyway. To make use of 3D, pak-creators would need to start over. Even paksets which make use of rendered 3D models, since those are not optimized for a game and textures are likely all over the place. Allowing 2D paksets to be used is not just a problem in "how to do it" but also in future development. For example, a 3D environment could allow for different terrain, not restricted to the current slopes. 2D doesn't. So either the 3D aspect would be held back by the need to comply with 2D, or the 2D paksets are played in an engine that worsens their performance for no gain, since the benefits can't be used.

All in all, while 3D Simutrans is intriguing, it would need to be seperate from 2D Simutrans.

[DrSuperGood]

A public player in timeline-less mode can build anything at any time. This may even be the same players who want the fanciest graphics the most in the first place.

In which case it loads what it needs to complete drawing. This is how most games work. The result is an asset stall for some brief period of time.

Not all graphics need to be in GPU memory. Only the graphics needed for the current draw calls have to be in GPU memory. Graphics which were needed or might be needed soon can be cached. When vRAM is approaching a limit the cache can be purged of less useful entries. This might degrade camera pan or jump performance but could have significant memory savings for large paksets.

Whenever something like this comes up, I always start to wonder if it wouldn't be easier to take a game like Mashinky and add Simutrans-like gameplay, since a gradual transistion seems impossible anyway. To make use of 3D, pak-creators would need to start over. Even paksets which make use of rendered 3D models, since those are not optimized for a game and textures are likely all over the place. Allowing 2D paksets to be used is not just a problem in "how to do it" but also in future development. For example, a 3D environment could allow for different terrain, not restricted to the current slopes. 2D doesn't. So either the 3D aspect would be held back by the need to comply with 2D, or the 2D paksets are played in an engine that worsens their performance for no gain, since the benefits can't be used.

The idea would be to use 3D graphics while keeping gameplay the same. Adding more freedoms which come with 3D would turn Simutrans into a separate game and not just a 3D Simutrans. Mix and matching 2D graphics with 3D graphics can work, as was seen in SimCity 4 which many people will say is still the best SimCity.

Still the main issue is that the way Simutrans was designed to draw graphics does not translate to hardware accelerating very well. The only reason it works so well on the CPU is because there is little overhead making the drawing calls as they do not require kernel level function calls.

[prissi]

You can look at the never finished 3D branch from 2011 in the SVN. It was using exactly this approach, 2D graphics for all existing paks in a isometric geometry and own 3D objects for the rest. The problem with Simutrans is that many paksets have many graphics, which needs also to darken at certain times.These must be uncompressed, and thus even if all are in one large bitmap for texture, this ends up with a GB or more (because uncompressed). Swapping GB size graphics around for missing objects does not sound like a recipe for acceleration.

Machinsky has Simutransish construction and also seems to solve the scale issue (of too large engines in relation to distances). Adding some passengers with destination (I think it is evne there) should be quite straight forward. Even Straße & Schiene had it with a 3D engine in 2001.

[Ters]

In which case it loads what it needs to complete drawing.

That could be everything.

The result is an asset stall for some brief period of time.

Potentially every frame.

Even if not all graphics is needed, it is beyond my capabilities to figure out which.

However, this was not the problem that brought my attempt to a halt, since I was able to load all of pak64 into VRAM. It was figuring out when something changed the mostly static landscape that sapped my motivation.

[Leartin]

The idea would be to use 3D graphics while keeping gameplay the same. Adding more freedoms which come with 3D would turn Simutrans into a separate game and not just a 3D Simutrans.

That's the idea, but Simutrans is not a dead game with fixed gameplay that gets revived with new graphics, it's still alive. New features are still added, and luckily our community is not toxic enough to claim "That's not Simutrans!" each time. Perhaps you misunderstood my comment as a drastic change away from the grid, so let me give you another example: A way to mark "parking spots" in buildings. Random citycars could appear as parked cars in these spots - just a bit of graphical variety, nobody could say that's "un-Simutrans" since we already have parking spots, just that we drew them with cars already on them. In 3D, this would be relatively simple, since the position dictates how it's drawn, while in 2D, it's much much more restricted what you can even do, and would require some extra code to put them on the right z level.
It's the same with pretty much anything that is currently not in the game due to graphical limitations. That there are no slope graphics for vehicles comes from the notion that pak designers would have to draw 4, by now 8, extra graphics per vehicle. But if the vehicle is a 3D object, that's not an issue at all. It wouldn't make the game any less Simutrans, so the only reason not to do it would be because of 2D compatability, so older 2D vehicles could exist alongside newer 3D vehicles.
But in the end, if everything that takes advantage of 3D couldn't be done, because it wouldn't be true to 2D rootes, why go through the trouble of going 3D at all?

[DrSuperGood]

It's the same with pretty much anything that is currently not in the game due to graphical limitations. That there are no slope graphics for vehicles comes from the notion that pak designers would have to draw 4, by now 8, extra graphics per vehicle. But if the vehicle is a 3D object, that's not an issue at all. It wouldn't make the game any less Simutrans, so the only reason not to do it would be because of 2D compatability, so older 2D vehicles could exist alongside newer 3D vehicles.But in the end, if everything that takes advantage of 3D couldn't be done, because it wouldn't be true to 2D rootes, why go through the trouble of going 3D at all?

I do not see a reason why both modes could not exist side by side other than the obvious one of code complexity. A 3D model might smoothly corner and go up and down ramps while any sprit based vehicles would act like they do currently. If mixing these two styles is good from an art consistency point of view is up to the pakset creator or player. The only reason not to do this would be coding complexity.

The reason I raised hardware accelerated graphics in this topic is because they can upgrade for as good as free a lot of visual effects and features which currently would have huge performance penalties if done on the CPU. For example moving to full 32bit RGBA colour support from the current 16bit colour is trivial for a GPU as they are optimized to handle 32bit colour but with the current software implementation the performance impact could nearly double the CPU time used for graphics, especially if memory bandwidth bottlenecked. Like wise special colour behaviours for day and night or above and blow ground or players could be implemented at a pixel shader level which should also be trivial for a modern GPU to run when compared with a CPU due to hardware level parallelism.