- Welcome to The International Simutrans Forum.
News:
Congratulations!
You've won the News Item Lottery! Your prize? Reading this news item!
You've won the News Item Lottery! Your prize? Reading this news item!
Recent posts
#41
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.
#42
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
#43
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.
#44
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.
#45
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?
#46
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.
#47
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.
#48
Patches & Projects / Re: [Project] Native Language ...
Last post by victor_18993 - August 20, 2026, 07:58:58 PMKorean native IME input has now been verified on Simutrans Standard.
The good news is that no additional Korean-specific code change was required.
The fix already integrated in:
r12182 — FIX: display IME composition in empty text fields
also works correctly with the Microsoft Korean IME.
The Korean tests covered both Windows GDI and SDL2, including real incremental Hangul composition and recomposition:
ㅎ → 하 → 한 → 한국
and Backspace through an active composition.
The results were green for:
- native Hangul keyboard input
- composition/pre-edit in an empty text field
- incremental Hangul recomposition
- Backspace during composition
- committed UTF-8 integrity
- normal cursor and text editing
- clipboard round-trip
- in-game naming
- save/load persistence
- Windows GDI
- Windows SDL2
The committed text "한국" was also verified as the exact expected UTF-8 data.
This means that the same basic native-input baseline is now verified for all four East Asian languages currently covered by this first NLS pass:
- Japanese
- Korean
- Simplified Chinese
- Traditional Chinese
No Korean-specific patch was necessary: r12182 fixed the underlying IME composition display path generically.
The official English developer documentation has also been updated accordingly:
r12184 — DOC: record Korean IME input validation
This does not mean that all CJK input work is finished. Other previously identified IME and font-related issues remain separate and will continue to be addressed incrementally.
With the basic East Asian native-input baseline now established, the Native Language Support work is moving on to the Cyrillic family.
The good news is that no additional Korean-specific code change was required.
The fix already integrated in:
r12182 — FIX: display IME composition in empty text fields
also works correctly with the Microsoft Korean IME.
The Korean tests covered both Windows GDI and SDL2, including real incremental Hangul composition and recomposition:
ㅎ → 하 → 한 → 한국
and Backspace through an active composition.
The results were green for:
- native Hangul keyboard input
- composition/pre-edit in an empty text field
- incremental Hangul recomposition
- Backspace during composition
- committed UTF-8 integrity
- normal cursor and text editing
- clipboard round-trip
- in-game naming
- save/load persistence
- Windows GDI
- Windows SDL2
The committed text "한국" was also verified as the exact expected UTF-8 data.
This means that the same basic native-input baseline is now verified for all four East Asian languages currently covered by this first NLS pass:
- Japanese
- Korean
- Simplified Chinese
- Traditional Chinese
No Korean-specific patch was necessary: r12182 fixed the underlying IME composition display path generically.
The official English developer documentation has also been updated accordingly:
r12184 — DOC: record Korean IME input validation
This does not mean that all CJK input work is finished. Other previously identified IME and font-related issues remain separate and will continue to be addressed incrementally.
With the basic East Asian native-input baseline now established, the Native Language Support work is moving on to the Cyrillic family.
#49
Patches & Projects / Re: [Project] Native Language ...
Last post by victor_18993 - August 20, 2026, 07:54:15 PMQuote from: Isaac Eiland-Hall on August 20, 2026, 05:02:30 PMworking on attachment problem, sorry!Thank you very much for working on it, Isaac! And no need to apologize — you're always very attentive to the forum and quick to help when something goes wrong. 🙂
edit: Fixed I think
Unfortunately, it still seems to be failing on my side. I'm getting the same error message saying that there was a problem during the upload and that I should contact the administrator.
Thanks again for taking a look at it!
#50
Patches & Projects / Re: [Project] Native Language ...
Last post by Isaac Eiland-Hall - August 20, 2026, 05:02:30 PMworking on attachment problem, sorry!
edit: Fixed I think
edit: Fixed I think