A Simutrans Prettification Project + Open GL dev

[Yona-TYT]

This development snapshot should be up to date with Simutrans 124.2.2
https://github.com/Varkalandar/simutrans_gl/releases/tag/dev_snapshot

I get a segmentation violation in linux

Code Select Expand

(gdb) where
#0  0x00007fffbee46753 in client_node_transport (data=0x5555561b0290,
    readfd=24, writefd=23, mem_id=0, offset=0, size=2312)
    at ../pipewire-jack/src/pipewire-jack.c:1588
#1  0x00007fffbc505532 in client_node_demarshal_transport (
    data=<optimized out>, msg=<optimized out>)
    at ../src/modules/module-client-node/protocol-native.c:380
#2  0x00007fffbc5ee01e in process_remote (impl=impl@entry=0x55555626f5d0)
    at ../src/modules/module-protocol-native.c:1037
#3  0x00007fffbc5ee7f8 in on_remote_data (data=0x55555626f5d0, fd=21, mask=1)
    at ../src/modules/module-protocol-native.c:1071
#4  0x00007fffdc017246 in loop_iterate (object=0x555556249918,
    timeout=<optimized out>) at ../spa/plugins/support/loop.c:496
#5  0x00007fffbedfe4a7 in do_loop (user_data=0x5555561b0870)
    at ../src/pipewire/thread-loop.c:295
#6  0x00007ffff75c26d7 in start_thread (arg=<optimized out>)
    at pthread_create.c:447
#7  0x00007ffff764660c in clone3 ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb)

[_Hajo_]

I must admit I am a bit clueless about this. I do not recognize any method/function name in this trace. Looks to me as if the location of the crash is in some library, not Simutrans code.

Which Linux version do you use? I could try to set up a VM with just that distro and see what happens there.

[Yona-TYT]

I must admit I am a bit clueless about this. I do not recognize any method/function name in this trace. Looks to me as if the location of the crash is in some library, not Simutrans code.

Which Linux version do you use? I could try to set up a VM with just that distro and see what happens there.

Wait, there are some additional libraries that must be used, right? I think the directory where the executable is doesn't have them.

[_Hajo_]

CMake stores them in the "lib" folder and the created executable should load them from there. I suspect that some of these libraries again depend on other system libraries, and that there are differences between the Linux distributions. Simutrans GL needs a number of libraries that Simutrans Standard does not need (OpenGL and OpenAL and some support libraries like GLEW).

If you tell me which distro you are using, I'll try to set up a VM with just that, and see what I can find out about the problem.

[_Hajo_]

I've compiled a new release, Simutrans GL v0.08, which is up to date in features with Simutrans 124.2.2.

https://github.com/Varkalandar/simutrans_gl/releases/tag/v0.08

In addition to the bug fixes and features merged from Simutrans Standard, there have been some Simutrans GL specific bug fixes:

- Fixed several accesses to uninitialized memory which occasionally could change scrollplane backgrounds to go black.
- Fixed the layouts of several list dialogs (factories, curiosities, vehicles ...)
- Fixed the city info window layout.
- Chat messages in the ticker line should have proper player color now.

There is still a leftover problem from merging changes from Standard. Currently there is no "Load Game" button in the new world dialog, but a "Back To Menu" button which just closes the new world dialog and does nothing else. To load a game in this situation, please open the options dialog from the top menu bar and select "Load Game" from there.

[Yona-TYT]

If you tell me which distro you are using, I'll try to set up a VM with just that, and see what I can find out about the problem.

Im using fedora 40

[_Hajo_]

Thank you. I'll set that up and see what I can do.

[_Hajo_]

Im using fedora 40

So, there were some problems, but I think I have got it done. At least on my new Fedora Workstation 40 installation I could compile a version that runs. Now, the big question, will it run on your computer too? There are definitely some differences from Ubuntu because even with the same settings the Fedora build is 3 MB larger than the Ubuntu build.

Please follow the link and download the "simutrans_gl_v008-linux-fedora-x64.zip"

https://github.com/Varkalandar/simutrans_gl/releases/tag/v0.08

Let me know if this works.

[Yona-TYT]

So, there were some problems, but I think I have got it done. At least on my new Fedora Workstation 40 installation I could compile a version that runs. Now, the big question, will it run on your computer too? There are definitely some differences from Ubuntu because even with the same settings the Fedora build is 3 MB larger than the Ubuntu build.

Please follow the link and download the "simutrans_gl_v008-linux-fedora-x64.zip"

https://github.com/Varkalandar/simutrans_gl/releases/tag/v0.08

Let me know if this works.

great!, Work well now 

[_Hajo_]

Nice! So we now know its compatible with your card and drivers.

[Yona-TYT]

Nice! So we now know its compatible with your card and drivers.

This card supports up to OpenGL 3, so it's a piece of junk.

I assume simutransgl is using OpenGL 2... although games already use gl 3 and above.

[_Hajo_]

Yes, so far it's all very old style OpenGL.

I wanted to move to 3.2 though, to get access to the programmable pipeline with shaders. Seems I should wait some more with that.

[_Hajo_]

There were some more problems left in v0.08 from the last merge with Simutrans Standard and also some older oversights which needed to be fixed. The list of changes is small, but some have bothered me and I felt a need to get a better version out. So here is the new and shiny v0.09!

Changes since v0.08:

• Fixed a crash when loading a theme without window title bar images
• Fixed a assertation failure when openening the mini map
• Station info icons (passengers, mail, freight, happy, unhappy, no route) are displayed again
• All list windows should have a common design again
• Tried to make the station info window more compact
• Tried to make the vehicle info window more compact
• "Back to menu" button in the new world window now opens the game options window (with option to load a saved game)
• There is a now an experimental build for fedora linux, because the ubuntu build did not work on fedora.

Downloads and sources:

https://github.com/Varkalandar/simutrans_gl/releases/tag/v0.09

[Yona-TYT]

The zoom out does not reach the same scale as in standard simultrans.

I also had some problems when trying to load an online game (not supported of course), the result was an infinite loop and I had to force quit.

The map thumbnail in the server loading window appears black.

[_Hajo_]

The zoom out does not reach the same scale as in standard simultrans.

A yes, I remember that problem. In Simutrans GL map is first rendered to a framebuffer which then is scaled. The size of the framebuffer limits the totally viewable area, I think it is 4096x4096 pixel currently.

I'll see if I can create a bigger framebuffer. At least in theory OpenGL should support up to 16000x16000 pixels, but in my one laptop anything bigger than 4096 failed, so I chose that as max size, but it surely would be good to use a bigger one on systems that allow bigger buffers.

The netork related things, I must admit I know very little about that part of Simutrans. I tried not to break anything, but chances are that something broke anyways. Problems there will need more time to be fixed. I want to focus on the basics first.

Update: The mentioned laptop has only 128mb graphics ram and simply runs out of graphics memory with a bigger framebuffer. I can detect the error code. This means I could try to get a bigger framebuffer on machines with enough graphics ram and fall back to the small buffer if creation fails with an out of memory error.

[_Hajo_]

The zoom out does not reach the same scale as in standard simultrans.

This version should offer one more level of zoom if you have at least 256MB of graphics ram.

https://github.com/Varkalandar/simutrans_gl/releases/tag/dev_snapshot

[_Hajo_]

Been working on light effects again. Still not 100% convinced, but I think I found a fairly good place in the code now to put the display of the light effects. For objects like stations I can put the light-halo above or below the front image. In these examples the light is displayed above and illuminates the whole structure.

The tricky part is to keep the pak files compatible to Simutrans Standard and still feed the lighting data into Simutrans GL's display engine. A proper solution will definitely need more planning. This is just a proof of concept.

As a welcome side effect of these experiments, I could fix the climate transition display at night (they were glowing before). The fix has been applied in the current development snapshot on github.

[Yona-TYT]

This version should offer one more level of zoom if you have at least 256MB of graphics ram.

https://github.com/Varkalandar/simutrans_gl/releases/tag/dev_snapshot

It works for me, although I get drops below 12 FPS with a 2432x2432 map.

I guess the GPU isn't being used very much.





Edit.



Minimap focus goes out of bounds.



Dragging horizontally with the mouse should allow you to move the pakset panels, but they do not drag and when the click is released the focused pak is loaded when the click was pressed.

[_Hajo_]

Thank you for testing. The feedback is very valuable.

Yes the GPU is only used for texture stuff, all the position calculations still happen on the CPU. The many trees in the screenshot are the problem, each goes through all position calculations and currently all these happen on the same CPU core because OpenGL does not support being used from multiple threads. I'll need more time to understand the rendering logic of Simutrans better and see if I can bring multi threading back there on some level.

The minimap is sadly broken in many ways. It will need time to fix it. It's on my list, though.

And I didn't know that scrollpanes in Simutrans standard support dragging with the mouse. I'll see what I can do about it.

[_Hajo_]

The pak selection scroll pane should support dragging by mouse in the new snapshot. I must have been way too tired when I coded that and the code to check for a mouse click was totally off; actually a surprise that it worked at all.

[_Hajo_]

I've tried to fix the small cracks in the world display that occurred at certain zoom levels. This required a fairly deep rework of the zoom function and touched more than 10 source files, which means, I might accidentally have broken something or missed something.

The new zoom code is in the current development snapshot,

https://github.com/Varkalandar/simutrans_gl/releases/tag/dev_snapshot

Overall I like this version better, it's cleaner than the former and simpler. Performance should be about the same. This version saves two multiplications and additions per tile displayed, but that is way too little to be noticed.

[Yona-TYT]

Two problems related to zoom:

- As the zoom out scale increases, scrolling on the map becomes slower.

- Zoom in should maintain the position relative to the mouse cursor, but this does not happen correctly.

[_Hajo_]

- As the zoom out scale increases, scrolling on the map becomes slower.

Is this worse than before or about the same? (It should be about the same, otherwise I broke something by accident. There always was some slowdown on zooming out because more objects must be displayed)

I'll look into the zoom center problem. That's something that my changes easily might have broken.

[Yona-TYT]

Yes, I have noticed an improvement. 

[_Hajo_]

Improvement sounds good. I've merged the new zoom code into the main branch and tried to fix the zoom center problem. I could achieve an improvement there too, but it's still not quite right.

Then I went back to the lights, tried to set up interfaces and data structures to allow each object on the map to have a light inside (if it has front and back image) and a light above. Still missing are the configuration files, there are still hard coded values in the program for the display tests. But I think with another day or two I should have set it up, so one can compile pak files with sets of lights and assign these lights to other objects. Still left to do, head and tail light effects for vehicles to illuminate the road. That needs quite some lights per vehicle (8 directions each), but I want to at least show a proof of concept some day soon.

Here a combination of "lights inside" and "lights above". I think it can still be improved by better light textures and better placement. That will be part of the configuration though, once done.

[prissi]

Lighting is a very nice new feature, especially if it can also come with color.

Do you go by the OpenTTD route, with an 8 bit player map and additionally a fullcolor light map ...

[_Hajo_]

I don't know how OpenTTD works on a graphics level. OpenGL allows to tint a texture with any color, and the lights in the different screenshots have slightly different colors. The feature to have colored lights is already in the code.

What's missing is to configure the lights on a pak set level. I'm working on that. Each light will have a color which also defines the brightness and a texture which defines the falloff from center to the border of the light. Also offsets where exactly the light texture has to be displayed relative to the lit object.

Simutrans GL doesn't support player colors yet, I'd need to use more advanced OpenGL features for that. Some day I'll bring back support for player colors, right now I'm experimenting to find out what I can do with the already existing code.

[Yona-TYT]

Here a combination of "lights inside" and "lights above". I think it can still be improved by better light textures and better placement. That will be part of the configuration though, once done.

Wow they look amazing!

[_Hajo_]

Wow they look amazing!

Thank you!

@Prissi, I've attached an example with different light colors and light textures for station and road lights. I'm still working on the configuration though, about 50% done.

[Yona-TYT]

Thank you!

@Prissi, I've attached an example with different light colors and light textures for station and road lights. I'm still working on the configuration though, about 50% done.

I already posted it on X. 

[_Hajo_]

I'm working on particle effects for buildings and other objects. Here a ground object, sort of a volcanic geyser. The code needs some more refinements, there are many hard coded values at the moment, which need to go into some configuration file.

Edit: I think I can let particles fade over time (make them more translucent), scale them (shrink or grow), and give them other paths, like the arcs that water drops in fountains traverse. They can even be stationary and just fade/shrink like sparks that pop up and fade again. Must see which of these options are actually useful and how much effort it is to support all of these ideas. I think fountains will be interesting and useful.

I hope animated gifs work in the forum:

[Leartin]

Can the particles change texture over time? Then they could replace current smoke objects directly.


You mention different paths. Do you have to hardcode paths, or could a formula be provided via dat? I enjoy using shorthand dat to animate frontimages with position calculations, but those are 'precalculated' in makeobj. If simple formulas with time and a random value were possible, supporting PEMDAS and some form of sinus,  for x and y position, scale, opacity and texture, I think it would provide the most freedom.


Something to think about: It seems to me your advancements here could be used for weather overlays (rain and snow surely are particle effects, you can probably get ripple-effects via shaders for trees to make them look like leaves are shaking,...), and weather - especially wind - would affect most use-cases of particle effects. Might make sense to think about particle effects being influenced by world states?

[_Hajo_]

At the moment paths are like pos(t) = pos_0 + v * t + 1/2 * a * t² (all 3d vectors) where you can define pos_0, v and a as part of the configuration (plus some randomization for each, there are ranges in the config, like minimum v and maximum v for each axis).

An interpreter for something like pos = f(t) with a user defined f(t) will be overkill I think. It's not impossible though, I have just recently written something like that as a Rust training project.

The textures can change over time. That's fairly easy to code. At the moment color and size changes will be linearly interpolated from start to end settings, textures can change over a sequence of given values by time.

If the particles and generators can replace the smokes, I have doubts. Compared to the traditional smoke objects the particle generators and particle data are fairly heavyweight. I'm worried that for large maps frequent use of these will be too demanding.

I definitely have plans though to use the particles this way. For factories and also for vehicles to show sparks for pantographs, exhaust smoke and the like. I'll post examples once I have results to show.

Weather effects - yes, and since OpenGL does full screen updates all the time anyways, it won't be as much of a problem as in Standard where display performance depends on how much of the screen changes between two frames. I'll look into that, but later. I was thinking about wind effects to move some of the particles, this will probably come first because it's directly linked to particle movement which I am working on anyways.

Give me some more weeks to finalize the configuration and publish examples for at least one pak set.

Thank you for the feedback! That helps me to move on, and keep a good direction.

[_Hajo_]

Here a version with gravity configured to be greater than zero,

[Leartin]

pos_0 + v * t + 1/2 * a * t²

I see, that should allow any straight path or single curves by approximating sine with a quadratic, yes?. An additional parameter to enable oscillation might be nice (think leaves falling from trees, slowly swinging left and right on their way down), but that's already quite flexible as it is.