- Welcome to The International Simutrans Forum.
News:
Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.
The official on-line manual for Simutrans. Read and contribute.
Recent posts
#21
Patches & Projects / Re: [Patch] Contextual constru...
Last post by prissi - August 22, 2026, 08:17:11 PMWhile I agree that more information is needed, the screen shot displays one problem: On small screen (Android) there is already very little space in the vertical direction.
Another problem with large screens: when dragging long ways, the information is always near the pointer position, while the bottom could be far away (for the eye).
Therefore, it should be optional to display the information at the bottom.
Moreover, the function of Control can be inverted in the settings. Not sure if the patch takes care of that.
For advanced construction, I agree with Roboron, a separate dialog would be best, with (image?) comboboxes for way, bridge and tunnel, and buttons for parallel building, straigt and replacement. It sounds sensible to add extended preview there too.
Overall, more information may be nice if screen diemnsions are reasonable. But I would not retire the tooltips, as they show the information where the focus is already.
Another problem with large screens: when dragging long ways, the information is always near the pointer position, while the bottom could be far away (for the eye).
Therefore, it should be optional to display the information at the bottom.
Moreover, the function of Control can be inverted in the settings. Not sure if the patch takes care of that.
For advanced construction, I agree with Roboron, a separate dialog would be best, with (image?) comboboxes for way, bridge and tunnel, and buttons for parallel building, straigt and replacement. It sounds sensible to add extended preview there too.
Overall, more information may be nice if screen diemnsions are reasonable. But I would not retire the tooltips, as they show the information where the focus is already.
#22
Incorporated Patches and Solved Bug Reports / Re: Several memory-safety issu...
Last post by victor_18993 - August 22, 2026, 01:54:12 PMA small update from the image-loading audit:
Two more long-standing issues have now been fixed in trunk:
- r12190 — read_bmp() now checks that the BMP file was successfully opened before reading it.
- r12191 — the same issue was fixed in read_ppm().
In both cases the file had already been opened successfully once during format detection, but the reader opened it again without checking the second result. If that second open failed, a NULL FILE* could reach the C runtime. On Windows/MSVC this can terminate the process.
Both fixes are very small and valid BMP/PPM output remains byte-identical. The full regression suite is still green (287/287), with no savegame, network or pak format changes.
All three image readers now correctly check their file opens.
While reviewing read_ppm(), one additional small resource leak was found on the truncated-file error path. I will handle that separately rather than mixing it into this fix.
Two more long-standing issues have now been fixed in trunk:
- r12190 — read_bmp() now checks that the BMP file was successfully opened before reading it.
- r12191 — the same issue was fixed in read_ppm().
In both cases the file had already been opened successfully once during format detection, but the reader opened it again without checking the second result. If that second open failed, a NULL FILE* could reach the C runtime. On Windows/MSVC this can terminate the process.
Both fixes are very small and valid BMP/PPM output remains byte-identical. The full regression suite is still green (287/287), with no savegame, network or pak format changes.
All three image readers now correctly check their file opens.
While reviewing read_ppm(), one additional small resource leak was found on the truncated-file error path. I will handle that separately rather than mixing it into this fix.
#23
Patches & Projects / Re: [Patch] Contextual constru...
Last post by Roboron - August 22, 2026, 12:53:08 PMFantastic idea! This is the kind of change that users with less Simutrans experience will appreciate 
Actually, I have thought about this in the past, so I have some ideas for improving it. I think the best approach would be to create a new build dialog* where the user could see that information and check/uncheck those options without the need of pressing keys, because that's not practical while playing in touch devices.
It would also be cool if it could show demolition costs as well.
But, as an initial approach this is much better than what we have currently, so for me this can go in.
* Similar to the one that appears when you ctrl+click the signal builder.
Actually, I have thought about this in the past, so I have some ideas for improving it. I think the best approach would be to create a new build dialog* where the user could see that information and check/uncheck those options without the need of pressing keys, because that's not practical while playing in touch devices.
It would also be cool if it could show demolition costs as well.
But, as an initial approach this is much better than what we have currently, so for me this can go in.
* Similar to the one that appears when you ctrl+click the signal builder.
#24
Incorporated Patches and Solved Bug Reports / Several memory-safety issues f...
Last post by victor_18993 - August 22, 2026, 12:24:38 PMDuring a recent code audit, several long-standing memory-safety issues were identified and have now been fixed in trunk:
- r12186 — fixed out-of-bounds reads/writes in locality_factor_per_year. In some configurations this could corrupt factory worker settings.
- r12187 — fixed out-of-bounds reads/writes in startingmoneyperyear. This could corrupt city-road configuration and produce incorrect starting-money calculations.
- r12189 — fixed a Windows use-after-scope in dr_mkdir(). The affected path was reached during every Windows startup when creating the maps, save and screenshot directories.
The fixes are deliberately small and do not change savegame, network or pak formats.
Current regression suite remains green (287/287).
These were mostly silent defects: the game could continue running while using corrupted or undefined state, which made them particularly difficult to diagnose from their visible symptoms.
- r12186 — fixed out-of-bounds reads/writes in locality_factor_per_year. In some configurations this could corrupt factory worker settings.
- r12187 — fixed out-of-bounds reads/writes in startingmoneyperyear. This could corrupt city-road configuration and produce incorrect starting-money calculations.
- r12189 — fixed a Windows use-after-scope in dr_mkdir(). The affected path was reached during every Windows startup when creating the maps, save and screenshot directories.
The fixes are deliberately small and do not change savegame, network or pak formats.
Current regression suite remains green (287/287).
These were mostly silent defects: the game could continue running while using corrupted or undefined state, which made them particularly difficult to diagnose from their visible symptoms.
#25
Game Servers / Re: http://list.extended.simut...
Last post by Off Laddie - August 21, 2026, 11:15:17 PMI assume this won't get resolved then
#26
Patches & Projects / Re: Experimental SDL3 / SDL_GP...
Last post by victor_18993 - August 21, 2026, 09:40:41 PMQuote from: prissi on August 21, 2026, 07:37:53 PMHow much faster per frame is the GPU rendering? You have only compared Direct3D and VulkanIn the current research version, it is actually not faster than the software renderer yet.
On the latest CUT-06 measurements, using the same L9 test workload:
- software renderer: ~12 ms/frame
- SDL_GPU Vulkan EXACT: ~58 ms/frame
- SDL_GPU D3D12 EXACT: ~97 ms/frame
The important result from the profiling is that the GPU itself is not the bottleneck. The remaining cost is almost entirely on the CPU side: command recording, atlas/run/pass construction and backend submission overhead. Vulkan is already considerably better than D3D12 here; D3D12 still has a relatively expensive per-pass cost.
Therefore I would not claim a performance advantage for SDL_GPU yet. The current work has been focused first on getting the GPU path deterministic and pixel-correct against the software renderer. The next cuts are intended to remove the remaining CPU-side overhead, after the multi-page atlas ordering issue is fixed.
I should have included the software baseline in the previous comparison — comparing only Vulkan and D3D12 was incomplete.
#27
Patches & Projects / Re: Experimental SDL3 / SDL_GP...
Last post by prissi - August 21, 2026, 07:37:53 PMHow much faster per frame is the GPU rendering? You have only compared Direct3D and Vulkan
#28
Incorporated Patches and Solved Bug Reports / Re: The "Replace Stop" functio...
Last post by victor_18993 - August 21, 2026, 11:07:36 AMI investigated this on current trunk.
The report is valid for r11993, but this particular issue has already been fixed in r12024.
The relevant change is:
r12024 — FIX: (Nazalassa) updatel line's convois if stop position changed
The Move/Replace Stop tool was already updating the line schedule itself, but it was not calling the normal line-management update path afterwards.
The missing call was:
player->simlinemgmt.update_line(line);
I also verified this causally by testing current trunk with that single call removed.
Without it, the line schedule is updated but the convoys keep the old stop indefinitely. If the old stop is then removed, the affected convoys can end up with no route.
With current trunk, the convoys are synchronized with the updated line and continue routing normally.
The apparent "line-less" behaviour is a secondary effect: moving the stop itself does not remove the convoy from its line. If a convoy still has the stale schedule and that schedule is later applied manually, it no longer matches the line schedule and the normal schedule logic can detach it from the line.
So this report does not require a new patch on current trunk.
If possible, please try again with a current nightly/revision newer than r12024 and let us know if you can still reproduce it.
The report is valid for r11993, but this particular issue has already been fixed in r12024.
The relevant change is:
r12024 — FIX: (Nazalassa) updatel line's convois if stop position changed
The Move/Replace Stop tool was already updating the line schedule itself, but it was not calling the normal line-management update path afterwards.
The missing call was:
player->simlinemgmt.update_line(line);
I also verified this causally by testing current trunk with that single call removed.
Without it, the line schedule is updated but the convoys keep the old stop indefinitely. If the old stop is then removed, the affected convoys can end up with no route.
With current trunk, the convoys are synchronized with the updated line and continue routing normally.
The apparent "line-less" behaviour is a secondary effect: moving the stop itself does not remove the convoy from its line. If a convoy still has the stale schedule and that schedule is later applied manually, it no longer matches the line schedule and the normal schedule logic can detach it from the line.
So this report does not require a new patch on current trunk.
If possible, please try again with a current nightly/revision newer than r12024 and let us know if you can still reproduce it.
#29
Patches & Projects / Re: Experimental SDL3 / SDL_GP...
Last post by victor_18993 - August 21, 2026, 10:03:53 AMSmall SDL3 / SDL_GPU development update.
I have now made the demonstration repository available publicly so anyone interested can inspect, build and test the current SDL3 work directly.
Public demo repository:
Dkijas/SDL3_SIMUTRAS_2.5D
The repository contains the experimental SDL3 platform backend together with the SDL_GPU renderer, including:
- existing software renderer through SDL3
- SDL_GPU renderer
- Vulkan backend
- Direct3D 12 backend
- build and test instructions
- launcher scripts
- the validated tutorial savegame
- architecture, testing and known-limitations notes
The published demo was validated from a fresh clone, with the automated suite passing on both SDL2 and SDL3 builds.
Please note that this is still an experimental demonstration, not an official Simutrans release and not an upstream-ready patch. Its purpose is to make the work reproducible and allow other developers or interested users to inspect the implementation and test it independently.
Development has continued beyond this public demo. The more recent GPU3 research cuts are still being hardened, particularly around deterministic multi-page atlas execution, D3D12 performance and the experimental visual rendering path. I prefer to keep those changes under validation before publishing them as another review point.
Feedback from anyone who builds or tests the demo is very welcome.
I have now made the demonstration repository available publicly so anyone interested can inspect, build and test the current SDL3 work directly.
Public demo repository:
Dkijas/SDL3_SIMUTRAS_2.5D
The repository contains the experimental SDL3 platform backend together with the SDL_GPU renderer, including:
- existing software renderer through SDL3
- SDL_GPU renderer
- Vulkan backend
- Direct3D 12 backend
- build and test instructions
- launcher scripts
- the validated tutorial savegame
- architecture, testing and known-limitations notes
The published demo was validated from a fresh clone, with the automated suite passing on both SDL2 and SDL3 builds.
Please note that this is still an experimental demonstration, not an official Simutrans release and not an upstream-ready patch. Its purpose is to make the work reproducible and allow other developers or interested users to inspect the implementation and test it independently.
Development has continued beyond this public demo. The more recent GPU3 research cuts are still being hardened, particularly around deterministic multi-page atlas execution, D3D12 performance and the experimental visual rendering path. I prefer to keep those changes under validation before publishing them as another review point.
Feedback from anyone who builds or tests the demo is very welcome.
#30
Incorporated Patches and Solved Bug Reports / Re: The "Replace Stop" functio...
Last post by prissi - August 21, 2026, 10:03:36 AMI guess you refer to the move stop tool?