- Welcome to The International Simutrans Forum.
News:
SimuTranslator
Make Simutrans speak your language.
Make Simutrans speak your language.
Recent posts
#31
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.
#32
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.
#33
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
#34
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.
#35
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
#36
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.
#37
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.
#38
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?
#39
Patches & Projects / Re: [Project] Native Language ...
Last post by victor_18993 - August 21, 2026, 09:50:22 AMQuick update on the Native Language Support (NLS) work.
Two underlying Windows input issues have now been fixed in Simutrans Standard:
r12182 — FIX: display IME composition in empty text fields
IME pre-edit/composition is now visible even when the text field initially contains no committed text.
r12185 — FIX: preserve Unicode character input on Windows GDI
The old ANSI boundary in the Windows GDI message loop was removed. Native Unicode keyboard characters are now preserved correctly instead of being converted through the active Windows code page.
East Asian native input
The basic East Asian baseline is therefore verified on both Windows backends.
Cyrillic native input
This includes real native-keyboard testing, extended Cyrillic characters, UTF-8 integrity, editing, clipboard, in-game naming and save/load persistence.
The seven-language Cyrillic basic baseline is now complete.
Latin Extended
Testing has now started with Czech:
Czech native input, UTF-8, rendering, editing, clipboard, shortcuts, in-game naming and save/load persistence are working correctly.
One small SDL2-specific issue remains:
LATEXT-01 — dead-key + Backspace handling
With a dead key pending, SDL2 currently does not reproduce the same cancellation behaviour as native Windows/GDI. The issue is limited to this editing gesture and is being handled separately.
So the current NLS status is:
East Asian basic baseline: COMPLETE
Cyrillic basic baseline: COMPLETE
Latin Extended: IN PROGRESS
The goal remains incremental: verify real native input family by family, fix underlying engine issues when they appear, and avoid language-specific workarounds wherever a generic fix is possible.
Two underlying Windows input issues have now been fixed in Simutrans Standard:
r12182 — FIX: display IME composition in empty text fields
IME pre-edit/composition is now visible even when the text field initially contains no committed text.
r12185 — FIX: preserve Unicode character input on Windows GDI
The old ANSI boundary in the Windows GDI message loop was removed. Native Unicode keyboard characters are now preserved correctly instead of being converted through the active Windows code page.
East Asian native input
| Language | Windows GDI | SDL2 | Overall |
| Japanese | PASS | PASS | PASS |
| Korean | PASS | PASS | PASS |
| Simplified Chinese | PASS | PASS | PASS |
| Traditional Chinese | PASS | PASS | PASS |
The basic East Asian baseline is therefore verified on both Windows backends.
Cyrillic native input
| Language | Windows GDI | SDL2 | Overall |
| Russian | PASS | PASS | PASS |
| Ukrainian | PASS | PASS | PASS |
| Bulgarian | PASS | PASS | PASS |
| Belarusian | PASS | PASS | PASS |
| Serbian Cyrillic | PASS | PASS | PASS |
| Macedonian | PASS | PASS | PASS |
| Kazakh | PASS | PASS | PASS |
This includes real native-keyboard testing, extended Cyrillic characters, UTF-8 integrity, editing, clipboard, in-game naming and save/load persistence.
The seven-language Cyrillic basic baseline is now complete.
Latin Extended
Testing has now started with Czech:
| Language | Windows GDI | SDL2 | Overall |
| Czech | PASS | PARTIAL | PARTIAL |
Czech native input, UTF-8, rendering, editing, clipboard, shortcuts, in-game naming and save/load persistence are working correctly.
One small SDL2-specific issue remains:
LATEXT-01 — dead-key + Backspace handling
With a dead key pending, SDL2 currently does not reproduce the same cancellation behaviour as native Windows/GDI. The issue is limited to this editing gesture and is being handled separately.
So the current NLS status is:
East Asian basic baseline: COMPLETE
Cyrillic basic baseline: COMPLETE
Latin Extended: IN PROGRESS
The goal remains incremental: verify real native input family by family, fix underlying engine issues when they appear, and avoid language-specific workarounds wherever a generic fix is possible.
#40
Incorporated Patches and Solved Bug Reports / The "Replace Stop" function se...
Last post by DThunder518 - August 20, 2026, 11:34:50 PMI've always liked using the "replace stop" function to help in changing station layouts, etc. This is great in a large station where a lot of lines may use the same stop, and now I need to move it by a tile or two. Using 11993 (in Linux), I've noticed that now when I use that function, it updates any lines that had that stop as expected, however convoys that were assigned to those lines still keep their old schedule and now become line-less. This is especially problematic when that old schedule now has an invalid stop in it because the station was changed/removed/etc and suddenly a lot of convoys can't find a route.