- 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
#11
Technical Documentation / Re: Compiler warnings treated ...
Last post by victor_18993 - Yesterday at 07:54:35 AMI agree. Enabling this for the relevant CI/nightly builds now that GCC and Clang are clean sounds like a good step.
#12
Technical Documentation / Compiler warnings treated as e...
Last post by ceeac - Yesterday at 07:47:40 AMIf the SIMUTRANS_WARNINGS_AS_ERRORS CMake option is enabled, compiler warnings are treated as errors to prevent easily-fixable bugs from creeping in. The option is disabled by default, but since r12205 (from today) enabling this will no longer break the build for GCC and Clang. Therefore, I want to enable this option for the relevant nightly (CI) build jobs at some point in the future (probably next week or so). For non-nightly builds the option will still be disabled to not accidentally break the build for people who are self-compiling Simutrans.
#13
Patches & Projects / Re: [Patch] Contextual constru...
Last post by Roboron - August 22, 2026, 11:00:06 PMQuote from: victor_18993 on August 22, 2026, 10:30:05 PMAndroid/touch behaviour is also unchanged: cost, length and rejection information can still be shown, but keyboard-only Ctrl/Shift hints remain suppressed.
I could play on Android devices with a physical keyboard and big screens. And I have played on Linux (non-Android) phones without keyboard.
I don't know if we can detect if the user is playing with a physical keyboard, but that would be the best option. Second best is to show this information based on screen size. But definitely not based on OS.
Quote from: victor_18993 on August 22, 2026, 10:30:05 PMWhat would be the preferred touch/mouse-accessible way to open the advanced construction dialog?
Currently this is done on Android by first pressing the "Ctrl" tool on the toolbar. I don't like it.
Another approach that comes to my mind: pressing the tool a second time to open the advanced construction dialog. Not sure how viable that is, and how that state should reflect on the toolbar.
#14
Patches & Projects / Re: [Patch] Contextual constru...
Last post by victor_18993 - August 22, 2026, 10:30:05 PMThanks for the feedback. I have now made the contextual construction information optional in r12195.
There is a new Show contextual construction information option in the display settings. It is enabled by default, so the current behaviour does not change unless the user disables it. On small screens this recovers the space used by the extra information band, while normal tooltips remain unchanged.
Android/touch behaviour is also unchanged: cost, length and rejection information can still be shown, but keyboard-only Ctrl/Shift hints remain suppressed.
I also tested the advanced construction dialog idea. The existing signal-spacing dialog is a good architectural precedent, and semantic controls such as Straight and Replace can be connected to the existing construction behaviour without duplicating the builder logic.
There are two points I would like to clarify before going further:
One small limitation of r12195: the GUI toggle works immediately, but persistence through
There is a new Show contextual construction information option in the display settings. It is enabled by default, so the current behaviour does not change unless the user disables it. On small screens this recovers the space used by the extra information band, while normal tooltips remain unchanged.
Android/touch behaviour is also unchanged: cost, length and rejection information can still be shown, but keyboard-only Ctrl/Shift hints remain suppressed.
I also tested the advanced construction dialog idea. The existing signal-spacing dialog is a good architectural precedent, and semantic controls such as Straight and Replace can be connected to the existing construction behaviour without duplicating the builder logic.
There are two points I would like to clarify before going further:
- What would be the preferred touch/mouse-accessible way to open the advanced construction dialog?
- When you mentioned a parallel option, did you mean a new explicit user-selectable mode? At the moment Code Select
prefer_parallelis derived internally from map geometry rather than being an existing player option.
One small limitation of r12195: the GUI toggle works immediately, but persistence through
Code Select
settings.xml is currently behind the existing 124.6 settings-version gate while the current save version is 124.5. I left that untouched rather than changing the format version just for this option. #15
Incorporated Patches and Solved Bug Reports / Re: The "Replace Stop" functio...
Last post by victor_18993 - August 22, 2026, 10:16:28 PM¡Genial, gracias por confirmarlo!
Great, thanks for confirming it.
Then we can consider this issue fixed since r12024. Glad to hear it is working again!
Great, thanks for confirming it.
Then we can consider this issue fixed since r12024. Glad to hear it is working again!
#16
Incorporated Patches and Solved Bug Reports / Re: The "Replace Stop" functio...
Last post by DThunder518 - August 22, 2026, 09:40:27 PMThank you Victor_18993, I just tried it with 12024 and it works again. Hooray!
#17
Bug Reports / Re: r11216 - moving objects
Last post by Andarix - August 22, 2026, 09:35:42 PMr12169
#18
Patches & Projects / Re: [Project] Native Language ...
Last post by victor_18993 - August 22, 2026, 08:43:28 PMA new update on the Native Language Support work.
The project has continued moving beyond the original East Asian language work, and we are now testing and improving several writing systems and translations in parallel.
On the runtime side, Japanese, Korean, Simplified Chinese and Traditional Chinese have a working baseline on both the Windows GDI and SDL2 backends. The Cyrillic work has also progressed significantly, with basic validation completed for Russian, Ukrainian, Bulgarian, Belarusian, Serbian Cyrillic, Macedonian and Kazakh.
One important Windows issue was fixed in r12185: the GDI event path was still using the ANSI Windows message functions in part of the input loop. It now uses the Unicode message path, which fixes native Cyrillic character input and also gives us a cleaner base for the other languages being tested.
Translation coverage is also being reviewed independently from rendering/input support.
A revised Russian translation has now been uploaded to Simutranslator. The existing Russian translation already had high coverage, but the review found a number of old mistranslations, untranslated help text, spelling problems and some placeholder inconsistencies. The first correction pass focuses on changes that can be made with high confidence rather than rewriting ambiguous strings without context.
Bulgarian has also received a much larger update in Simutranslator. The previous Bulgarian translation only covered a relatively small part of the interface, so although Cyrillic itself worked correctly, large parts of the UI were still effectively unsupported in Bulgarian. The new version substantially expands that coverage and corrects a number of existing translation problems.
As before, Simutranslator remains the authoritative place for translation changes. These language files are not being maintained as independent local forks.
We have also started extending the validation work to Latin Extended languages. Czech is currently being used as one of the first test languages. This has already exposed a backend-specific SDL2 issue involving dead keys and Backspace: native Windows/GDI and SDL2 do not currently produce the same result in one compose/edit sequence. That issue is being treated separately rather than being hidden by the translation work.
So the current direction of the project is now broader than simply "make CJK text work":
I will continue expanding the language matrix gradually and fixing reproducible backend problems as they appear, rather than making broad changes to the text system without a concrete failing case.
The project has continued moving beyond the original East Asian language work, and we are now testing and improving several writing systems and translations in parallel.
On the runtime side, Japanese, Korean, Simplified Chinese and Traditional Chinese have a working baseline on both the Windows GDI and SDL2 backends. The Cyrillic work has also progressed significantly, with basic validation completed for Russian, Ukrainian, Bulgarian, Belarusian, Serbian Cyrillic, Macedonian and Kazakh.
One important Windows issue was fixed in r12185: the GDI event path was still using the ANSI Windows message functions in part of the input loop. It now uses the Unicode message path, which fixes native Cyrillic character input and also gives us a cleaner base for the other languages being tested.
Translation coverage is also being reviewed independently from rendering/input support.
A revised Russian translation has now been uploaded to Simutranslator. The existing Russian translation already had high coverage, but the review found a number of old mistranslations, untranslated help text, spelling problems and some placeholder inconsistencies. The first correction pass focuses on changes that can be made with high confidence rather than rewriting ambiguous strings without context.
Bulgarian has also received a much larger update in Simutranslator. The previous Bulgarian translation only covered a relatively small part of the interface, so although Cyrillic itself worked correctly, large parts of the UI were still effectively unsupported in Bulgarian. The new version substantially expands that coverage and corrects a number of existing translation problems.
As before, Simutranslator remains the authoritative place for translation changes. These language files are not being maintained as independent local forks.
We have also started extending the validation work to Latin Extended languages. Czech is currently being used as one of the first test languages. This has already exposed a backend-specific SDL2 issue involving dead keys and Backspace: native Windows/GDI and SDL2 do not currently produce the same result in one compose/edit sequence. That issue is being treated separately rather than being hidden by the translation work.
So the current direction of the project is now broader than simply "make CJK text work":
- reliable Unicode input and rendering across the supported backends;
- validation of different writing systems rather than only ASCII/Western European text;
- improving actual translation coverage where a language technically exists but large parts of the UI are still untranslated;
- checking placeholders, formatting and help text as translations are reviewed;
- keeping runtime language support and translation completeness as separate validation targets.
I will continue expanding the language matrix gradually and fixing reproducible backend problems as they appear, rather than making broad changes to the text system without a concrete failing case.
#19
Patches & Projects / Re: Experimental SDL3 / SDL_GP...
Last post by victor_18993 - August 22, 2026, 08:38:10 PMSmall update on the SDL3/GPU renderer work.
The performance investigation is now giving us a much clearer picture of where the time is actually going.
In the current renderer, the main steady-state cost is not coming from atlas size, uploads or submission count. A large part of the overhead comes from the way exact rendering currently records many render passes and destination copies on the CPU.
D3D12 also has an additional issue once sampler descriptor usage crosses a specific threshold.
The first optimization work is already showing very encouraging results on cold frames. In one of the heavier test cases, Vulkan dropped from about 523 ms to 124 ms, while D3D12 dropped from about 588 ms to 193 ms.
We also corrected one earlier assumption during the investigation. The expensive first-use path is not caused by sprite data being copied back from the GPU. The actual problem is the synchronization model: newly uploaded sprites were creating a large number of separate transfer operations, submissions and blocking fence waits for a very small amount of data. Those uploads are now being batched much more efficiently.
Exact rendering is still matching the software reference in the tests completed so far, including multi-page atlas cases and different producer counts. We are continuing the longer validation campaign now to make sure the optimizations do not introduce regressions in warm rendering, clipping or general behaviour.
The next work will focus on the remaining D3D12 descriptor overhead and then on reducing the large number of destination-read passes required by exact rendering.
Once these optimizations are ready and the full correctness/regression checks are complete, we will try to release DEMO 4 as soon as possible so people can test the improved renderer directly.
There is still no production integration from this work yet; everything remains isolated while the renderer is being optimized and validated.
The performance investigation is now giving us a much clearer picture of where the time is actually going.
In the current renderer, the main steady-state cost is not coming from atlas size, uploads or submission count. A large part of the overhead comes from the way exact rendering currently records many render passes and destination copies on the CPU.
D3D12 also has an additional issue once sampler descriptor usage crosses a specific threshold.
The first optimization work is already showing very encouraging results on cold frames. In one of the heavier test cases, Vulkan dropped from about 523 ms to 124 ms, while D3D12 dropped from about 588 ms to 193 ms.
We also corrected one earlier assumption during the investigation. The expensive first-use path is not caused by sprite data being copied back from the GPU. The actual problem is the synchronization model: newly uploaded sprites were creating a large number of separate transfer operations, submissions and blocking fence waits for a very small amount of data. Those uploads are now being batched much more efficiently.
Exact rendering is still matching the software reference in the tests completed so far, including multi-page atlas cases and different producer counts. We are continuing the longer validation campaign now to make sure the optimizations do not introduce regressions in warm rendering, clipping or general behaviour.
The next work will focus on the remaining D3D12 descriptor overhead and then on reducing the large number of destination-read passes required by exact rendering.
Once these optimizations are ready and the full correctness/regression checks are complete, we will try to release DEMO 4 as soon as possible so people can test the improved renderer directly.
There is still no production integration from this work yet; everything remains isolated while the renderer is being optimized and validated.
#20
Patches & Projects / Re: [Patch] Contextual constru...
Last post by victor_18993 - August 22, 2026, 08:33:29 PMGracias, Roboron y Prissi. Estoy de acuerdo con ambos puntos, especialmente en lo que respecta a las pantallas pequeñas/táctiles.
La información de construcción contextual ahora está integrada en r12194 . El comportamiento actual se divide deliberadamente entre lo que es universal y lo que depende de un teclado físico:
También revisé el punto sobre la configuración de Ctrl. La implementación actual toma
Creo que el siguiente paso más importante es la dirección que ambos sugieren: en lugar de intentar reproducir las teclas modificadoras del teclado en dispositivos táctiles, hacer que las opciones de construcción sean explícitas e independientes del tipo de entrada.
El modelo que estoy investigando ahora es aproximadamente:
Teclado / táctil / entrada futura → opciones de construcción semántica → herramienta de construcción existente
Así, Ctrl y Shift seguirían siendo atajos de teclado rápidos, pero los conceptos que mostraría la interfaz serían, por ejemplo, Recto, Paralelo y Reemplazar , en lugar de "Ctrl" y "Shift". Por lo tanto, un usuario táctil nunca necesitaría abrir un teclado virtual ni saber qué tecla modificadora corresponde a cada acción.
También estoy analizando detenidamente el diálogo de espaciado de señales existente como precedente en el juego. El primer objetivo es un pequeño diálogo de construcción avanzada que se pueda abrir sin teclado y que configure la herramienta de construcción ya seleccionada, sin duplicar la lógica de enrutamiento/construcción.
En cuanto al tamaño de la pantalla, creo que la separación útil es:
Cerca del puntero: mantenga la información concisa que sea inmediatamente relevante para la acción actual: coste, duración, motivo del rechazo y el comportamiento actual de la información sobre herramientas.
Diálogo avanzado: opciones de construcción persistentes y, posteriormente, si resulta práctico, selección de vía/puente/túnel y una vista previa más detallada.
Eso debería evitar los dos problemas opuestos que mencionaste: en pantallas pequeñas no llenamos el espacio vertical con información permanente, mientras que en pantallas grandes la información relacionada con la construcción actual no termina muy lejos del puntero.
I will test the design at desktop resolutions and constrained Android-like resolutions before proposing an implementation. The intention is for the same semantic construction UI to work on desktop, Android, Windows/Linux touch screens and Android devices with a physical keyboard, rather than creating an Android-specific version of the construction tools.
One transparency note about r12194: the integrated version also contains two refinements developed after the patch originally posted in this thread, so it is somewhat larger than the version reviewed here. They were regression-tested together, but those later refinements were not part of the originally posted patch.
There is also one small observable scripting detail: some rejected
I will keep the advanced-construction work separate from r12194 and bring back a small, reviewable proposal with screenshots before considering any further integration.
La información de construcción contextual ahora está integrada en r12194 . El comportamiento actual se divide deliberadamente entre lo que es universal y lo que depende de un teclado físico:
- Coste, duración y motivo de rechazo: ordenador de sobremesa + Android
- Sugerencias de modificadores Ctrl/Shift: por ahora solo para escritorio.
- Semántica de construcción, enrutamiento y costos: sin cambios
Code Select
__ANDROID__Todavía no he realizado una prueba real con Android NDK/dispositivo, así que no quiero afirmar que se haya realizado una validación de Android en tiempo de ejecución que aún no se ha producido.También revisé el punto sobre la configuración de Ctrl. La implementación actual toma
Code Select
straight_way_without_controlen cuenta, por lo que no anuncia Ctrl para el comportamiento de ruta recta cuando la construcción recta ya está forzada por la configuración.Creo que el siguiente paso más importante es la dirección que ambos sugieren: en lugar de intentar reproducir las teclas modificadoras del teclado en dispositivos táctiles, hacer que las opciones de construcción sean explícitas e independientes del tipo de entrada.
El modelo que estoy investigando ahora es aproximadamente:
Teclado / táctil / entrada futura → opciones de construcción semántica → herramienta de construcción existente
Así, Ctrl y Shift seguirían siendo atajos de teclado rápidos, pero los conceptos que mostraría la interfaz serían, por ejemplo, Recto, Paralelo y Reemplazar , en lugar de "Ctrl" y "Shift". Por lo tanto, un usuario táctil nunca necesitaría abrir un teclado virtual ni saber qué tecla modificadora corresponde a cada acción.
También estoy analizando detenidamente el diálogo de espaciado de señales existente como precedente en el juego. El primer objetivo es un pequeño diálogo de construcción avanzada que se pueda abrir sin teclado y que configure la herramienta de construcción ya seleccionada, sin duplicar la lógica de enrutamiento/construcción.
En cuanto al tamaño de la pantalla, creo que la separación útil es:
Cerca del puntero: mantenga la información concisa que sea inmediatamente relevante para la acción actual: coste, duración, motivo del rechazo y el comportamiento actual de la información sobre herramientas.
Diálogo avanzado: opciones de construcción persistentes y, posteriormente, si resulta práctico, selección de vía/puente/túnel y una vista previa más detallada.
Eso debería evitar los dos problemas opuestos que mencionaste: en pantallas pequeñas no llenamos el espacio vertical con información permanente, mientras que en pantallas grandes la información relacionada con la construcción actual no termina muy lejos del puntero.
I will test the design at desktop resolutions and constrained Android-like resolutions before proposing an implementation. The intention is for the same semantic construction UI to work on desktop, Android, Windows/Linux touch screens and Android devices with a physical keyboard, rather than creating an Android-specific version of the construction tools.
One transparency note about r12194: the integrated version also contains two refinements developed after the patch originally posted in this thread, so it is somewhat larger than the version reviewed here. They were regression-tested together, but those later refinements were not part of the originally posted patch.
There is also one small observable scripting detail: some rejected
Code Select
command_x paths that previously propagated an empty string can now preserve the actual rejection text. The accept/reject decision, route, cost and resulting world state are unchanged, but a third-party scenario explicitly checking Code Select
err == "" could observe that difference.I will keep the advanced-construction work separate from r12194 and bring back a small, reviewable proposal with screenshots before considering any further integration.