- Welcome to The International Simutrans Forum.
News:
.Recent posts
#31
Social & Contests / My favorite soundfont is SGM-V...
Last post by Yona-TYT - October 05, 2026, 01:19:02 PMSometimes I listen to Simutrans melodies, so I have to say that SGM-V2.01 is my favorite of all the ones I've tried.
Side note: I love how "Midnight Express 2" sounds; it's wonderful.
#32
Patches & Projects / Re: Simutrans 32-bit graphics ...
Last post by makie - October 05, 2026, 11:49:07 AMI have run the new makeobj with STLAB_XR32_WRITE=1
It doubles the pak size.
In the game it looks all ok (beside the not working keyboard commands as shift 2)
But the graphics are 16 bit.
Look at this screenshot:
It is 4x enlarged for better visibility. It is the seawater. Left is the screenshot and right is how it should look. I am sorry i do right the tile position not exactly. You can see left there are only 16 various blue which leads to steps and areas.
For testing the water.pak
https://makie.de/seawater.zip
It doubles the pak size.
In the game it looks all ok (beside the not working keyboard commands as shift 2)
But the graphics are 16 bit.
Look at this screenshot:
It is 4x enlarged for better visibility. It is the seawater. Left is the screenshot and right is how it should look. I am sorry i do right the tile position not exactly. You can see left there are only 16 various blue which leads to steps and areas.
For testing the water.pak
https://makie.de/seawater.zip
#33
Incorporated Patches and Solved Bug Reports / Steam Windows build: default.s...
Last post by victor_18993 - October 05, 2026, 07:08:08 AMWhile investigating the music problem reported on the Steam Windows build, I found that the issue is in the Steam packaging rather than in the Simutrans music code itself.
The mixed "/" and "\" path separators shown in the SoundFont path are harmless and are not the cause.
The actual problem is that the Steam Windows workflows were building FluidSynth without its optional libsndfile support. Because of that, FluidSynth can load normal SF2 files such as PCLite.sf2, but it cannot load the supplied default.sf3 SoundFont (SoundFont 3.x).
This was reproduced independently on both Windows x64 and x86.
The build fix is very small: the Windows Steam workflows now install:
fluidsynth[sndfile]
instead of:
fluidsynth
I have tested the resulting packages with both default.sf3 and PCLite.sf2. Both load correctly on x64 and x86, music plays normally, switching SoundFonts and restarting works, and sound effects are unchanged.
The fix has already been committed to the Steam build repository:
simutrans/simutrans-steam-builds
commit 02ac9d19e4f4d1d0e51c2bb7f7058b2e4b3ecd69
All build workflows completed successfully.
This does not require any change to Simutrans SVN/trunk itself: the defect was only in the Steam Windows build configuration.
The corrected GitHub build artifacts are available, but I have not manually deployed anything to Steam. Steam publication is still handled separately by the existing deployment process/access.
So, in short:
- PCLite.sf2: already worked
- default.sf3: failed on Steam Windows
- cause: FluidSynth built without SF3 support
- fix: enable the sndfile feature in the Windows Steam packages
- Simutrans source code: unchanged
The mixed "/" and "\" path separators shown in the SoundFont path are harmless and are not the cause.
The actual problem is that the Steam Windows workflows were building FluidSynth without its optional libsndfile support. Because of that, FluidSynth can load normal SF2 files such as PCLite.sf2, but it cannot load the supplied default.sf3 SoundFont (SoundFont 3.x).
This was reproduced independently on both Windows x64 and x86.
The build fix is very small: the Windows Steam workflows now install:
fluidsynth[sndfile]
instead of:
fluidsynth
I have tested the resulting packages with both default.sf3 and PCLite.sf2. Both load correctly on x64 and x86, music plays normally, switching SoundFonts and restarting works, and sound effects are unchanged.
The fix has already been committed to the Steam build repository:
simutrans/simutrans-steam-builds
commit 02ac9d19e4f4d1d0e51c2bb7f7058b2e4b3ecd69
All build workflows completed successfully.
This does not require any change to Simutrans SVN/trunk itself: the defect was only in the Steam Windows build configuration.
The corrected GitHub build artifacts are available, but I have not manually deployed anything to Steam. Steam publication is still handled separately by the existing deployment process/access.
So, in short:
- PCLite.sf2: already worked
- default.sf3: failed on Steam Windows
- cause: FluidSynth built without SF3 support
- fix: enable the sndfile feature in the Windows Steam packages
- Simutrans source code: unchanged
#34
Patches & Projects / Re: HiDPI GUI scaling prototyp...
Last post by victor_18993 - October 05, 2026, 07:05:17 AMThanks for the detailed review, prissi. I reworked the HiDPI prototype following your suggestions, and the implementation is now quite a bit simpler.
https://files.simutrans-germany.com/upload/autoescaler.rar
The main changes are:
- only one persistent value remains, env_t::gui_scale; the effective scale is just zoom_up/zoom_down;
- manual and display scale changes now go through the normal SYSTEM_RESIZE event path;
- window positions/sizes are rescaled through rdwr_all_win;
- the old GUI-scale reload helper is gone;
- font_t::swap is not part of the HiDPI patch anymore — it belongs only to the separate font ownership fix;
- restore_all_skins() is still used for real theme changes, but not for scale-only changes, because reloading the skins there only registered extra images without changing the result;
- scaling now uses one SCALE() macro based on zoom_up/zoom_down. I kept round-to-nearest rather than truncation because the truncated form changes many pixel positions compared with the already tested behaviour.
The refactored version is based on r12333.
At 100% it is still pixel-identical to trunk in SDL3, SDL2 and GDI, the map remains unchanged from 100% to 300%, and the test suite is still 310/310.
I kept two of your suggestions as separate optional patches because they change existing behaviour even at 100%:
1. Tooltip offset using LINESPACE / D_H_SPACE — this moves the tooltip by 3 pixels at 100%.
2. The simgraph0 get_image_offset cleanup — this also changes how empty images are represented.
Would you prefer these two cleanups to be included with the HiDPI patch, or kept separate?
There is also one remaining usability question: at very large manual scales, e.g. 400% in a 1280x800 window, the Display dialog can become too large to use to change the scale back. Would you prefer to clamp the selectable scale, or allow large scales but make critical dialogs always recoverable?
No code has been committed or pushed yet. Real Windows mixed-DPI and macOS Retina testing are still pending.
https://files.simutrans-germany.com/upload/autoescaler.rar
The main changes are:
- only one persistent value remains, env_t::gui_scale; the effective scale is just zoom_up/zoom_down;
- manual and display scale changes now go through the normal SYSTEM_RESIZE event path;
- window positions/sizes are rescaled through rdwr_all_win;
- the old GUI-scale reload helper is gone;
- font_t::swap is not part of the HiDPI patch anymore — it belongs only to the separate font ownership fix;
- restore_all_skins() is still used for real theme changes, but not for scale-only changes, because reloading the skins there only registered extra images without changing the result;
- scaling now uses one SCALE() macro based on zoom_up/zoom_down. I kept round-to-nearest rather than truncation because the truncated form changes many pixel positions compared with the already tested behaviour.
The refactored version is based on r12333.
At 100% it is still pixel-identical to trunk in SDL3, SDL2 and GDI, the map remains unchanged from 100% to 300%, and the test suite is still 310/310.
I kept two of your suggestions as separate optional patches because they change existing behaviour even at 100%:
1. Tooltip offset using LINESPACE / D_H_SPACE — this moves the tooltip by 3 pixels at 100%.
2. The simgraph0 get_image_offset cleanup — this also changes how empty images are represented.
Would you prefer these two cleanups to be included with the HiDPI patch, or kept separate?
There is also one remaining usability question: at very large manual scales, e.g. 400% in a 1280x800 window, the Display dialog can become too large to use to change the scale back. Would you prefer to clamp the selectable scale, or allow large scales but make critical dialogs always recoverable?
No code has been committed or pushed yet. Real Windows mixed-DPI and macOS Retina testing are still pending.
#35
Patches & Projects / Re: [Project proposal] Optiona...
Last post by victor_18993 - October 05, 2026, 06:56:28 AMOK, I agree, now is not the best time to add more features,
cheers.
cheers.
#36
Patches & Projects / Re: [Project proposal] Optiona...
Last post by prissi - October 05, 2026, 05:32:48 AMBefore incorporating, let's release a 125.0.1 tonight to have the builder and key bugs fixed.
#37
Patches & Projects / Re: [Project proposal] Optiona...
Last post by victor_18993 - October 05, 2026, 02:55:43 AMI completed the next settings-architecture pass. The prototype now has 169 checks
(164 positive passes plus 5 negative controls behaving as expected), and I think
there is only one ownership question left before implementing settings.tab properly.
The main finding is that several different mechanisms currently overwrite local
GUI/application preferences:
- themes still load 9 behavioural settings, including tooltip timings, snap
distance and button side, and this can even override the user's simuconf.tab;
- 17 shipped simuconf.tab values duplicate env_t defaults and therefore reset GUI
choices on every start;
- Load/Join also alter some local state;
- joining a server can replace the nickname with a generated city name and keep
that value afterwards.
I tested a model where only values actually changed by the user are remembered.
Runtime overrides are never written back as the user's preference. Those remembered
values are kept in memory across New Game, Load and Join, rather than literally
reloading settings.tab there, because reloading the file at that point would also
undo higher-priority runtime overrides such as simuconf or command-line options.
I also tested two independent cleanups:
1. 11 of the 17 duplicated shipped simuconf defaults can be commented out without
changing first-run behaviour.
2. The 9 behavioural values can be removed from theme loading, so changing/reloading
a theme no longer changes unrelated application preferences.
Both work independently of introducing settings.tab.
There is one point where I need your intended ownership rule before going further:
Some paksets also specify values that look partly like local GUI/application
preferences. For example, pak192.comic sets fps=60, pak64 sets outside_tile=1, and
pak128 sets water_animation=100.
If the user has explicitly chosen one of these values, should the remembered user
choice override the pakset value, as you indicated for things such as the font and
button side?
Or are some of these values intentionally owned by the pakset and therefore supposed
to override a remembered local preference?
I think this ownership distinction is the last thing needed before implementing
the production settings.tab model.
No trunk changes were made.
(164 positive passes plus 5 negative controls behaving as expected), and I think
there is only one ownership question left before implementing settings.tab properly.
The main finding is that several different mechanisms currently overwrite local
GUI/application preferences:
- themes still load 9 behavioural settings, including tooltip timings, snap
distance and button side, and this can even override the user's simuconf.tab;
- 17 shipped simuconf.tab values duplicate env_t defaults and therefore reset GUI
choices on every start;
- Load/Join also alter some local state;
- joining a server can replace the nickname with a generated city name and keep
that value afterwards.
I tested a model where only values actually changed by the user are remembered.
Runtime overrides are never written back as the user's preference. Those remembered
values are kept in memory across New Game, Load and Join, rather than literally
reloading settings.tab there, because reloading the file at that point would also
undo higher-priority runtime overrides such as simuconf or command-line options.
I also tested two independent cleanups:
1. 11 of the 17 duplicated shipped simuconf defaults can be commented out without
changing first-run behaviour.
2. The 9 behavioural values can be removed from theme loading, so changing/reloading
a theme no longer changes unrelated application preferences.
Both work independently of introducing settings.tab.
There is one point where I need your intended ownership rule before going further:
Some paksets also specify values that look partly like local GUI/application
preferences. For example, pak192.comic sets fps=60, pak64 sets outside_tile=1, and
pak128 sets water_animation=100.
If the user has explicitly chosen one of these values, should the remembered user
choice override the pakset value, as you indicated for things such as the font and
button side?
Or are some of these values intentionally owned by the pakset and therefore supposed
to override a remembered local preference?
I think this ownership distinction is the last thing needed before implementing
the production settings.tab model.
No trunk changes were made.
#38
Patches & Projects / Re: Simutrans 32-bit graphics ...
Last post by victor_18993 - October 05, 2026, 01:57:18 AMYes — I checked this directly.
Legacy images are already handled lazily: the original 16-bit pak data stays as-is, and the 32-bit representation is only created in recode_img() the first time the image is actually drawn. Scaled versions are also created on first use and then kept in memory.
The current DAY+NIGHT prototype does not do the same for NIGHT. NIGHT is fully decompressed when the pak is loaded, even if the player never uses night mode.
I made a small local prototype that lets NIGHT reuse the same lazy path as legacy images. The NIGHT data stays compressed after loading and is only decompressed the first time that image is actually drawn at night.
It does not change Makeobj or the pak format, and the rendered output is identical to the current prototype: 63,524 cache comparisons matched exactly, including dusk transitions, player colours, glow outside the DAY silhouette, zooms and MRES.
The main benefit is DAY-only memory use:
- pak64: 15.25 MB -> 8.67 MB (-43%)
- pak128: 57.27 MB -> 30.44 MB (-47%)
After the first night the memory usage becomes the same as before, because the NIGHT data is kept once materialized.
The trade-off is a one-time first-use cost. In the heaviest synthetic case I measured, 1,000 pak128 images reaching their first night together increased that frame from about 43 ms to 210 ms.
So your suggestion is definitely practical, and it reuses an existing engine mechanism rather than introducing a new cache system.
Legacy images are already handled lazily: the original 16-bit pak data stays as-is, and the 32-bit representation is only created in recode_img() the first time the image is actually drawn. Scaled versions are also created on first use and then kept in memory.
The current DAY+NIGHT prototype does not do the same for NIGHT. NIGHT is fully decompressed when the pak is loaded, even if the player never uses night mode.
I made a small local prototype that lets NIGHT reuse the same lazy path as legacy images. The NIGHT data stays compressed after loading and is only decompressed the first time that image is actually drawn at night.
It does not change Makeobj or the pak format, and the rendered output is identical to the current prototype: 63,524 cache comparisons matched exactly, including dusk transitions, player colours, glow outside the DAY silhouette, zooms and MRES.
The main benefit is DAY-only memory use:
- pak64: 15.25 MB -> 8.67 MB (-43%)
- pak128: 57.27 MB -> 30.44 MB (-47%)
After the first night the memory usage becomes the same as before, because the NIGHT data is kept once materialized.
The trade-off is a one-time first-use cost. In the heaviest synthetic case I measured, 1,000 pak128 images reaching their first night together increased that frame from about 43 ms to 210 ms.
So your suggestion is definitely practical, and it reuses an existing engine mechanism rather than introducing a new cache system.
#39
Patches & Projects / Re: Simutrans 32-bit graphics ...
Last post by prissi - October 05, 2026, 12:27:31 AMThe old images are kept at 16 bit and not converted to 32 bit on load time? (Or rather lazily when used the first time?) I mean, the night images could be also rendered lazily, since many player do not use night mode.
#40
Patches & Projects / Re: HiDPI GUI scaling prototyp...
Last post by prissi - October 05, 2026, 12:23:22 AMWhen scaling the GUI, usually the pak images also become too small. Even zooming in pak64 became tiny, hence the scaling of everything. This is especially serious on phones, with their insane DPI values. Unscaled maps on run of the mill 4k displays on middle end phone just don't work well without map zoom (and on early retina macs), both getting very laggy as too much data has to be moved.
Moreover, proportional scaling on some things was ugly on some things, like huge scrollbars, hence the use of themes. But it is good to have an additional option, at least for more high-end hardware.
On the implementation:
Why two env_t values? One should be enough. The second is only needed temporary, see below.
The code in poll_event is very hackish. Rather sent a size event with an extra parameter with the requested new dpi. This the can call gui_themes etc. Also, one could scale window positions in rdwr_all_win and gui_frame_t(), not in the event routine (maybe).
win_reload_windows_after_gui_scale is just used one time, so no need for a new routine. Also, when gui_themes_init is called from an event, just queue the event once from the dialog.
What is the font_t::swap routine needed for? Font scaling worked already without ...
The offset of the tooltip should be relative to LINE_SPACE and D_H_SPACE. The fixed values were rather ancient left-over.
On gui_themes_t. Why the skinverwaltung_t::restore_all_skins() was removed? Maybe a comment would help?
Also the scaling is always done with the two zoom values. Hence, the gui_init could at first determine those two values and then scaling could use a macro
gfx->get_image_offset should probably return the image size on simgraph0.cc since it is loaded nowadays anyway. Would remove the if condition.
Moreover, proportional scaling on some things was ugly on some things, like huge scrollbars, hence the use of themes. But it is good to have an additional option, at least for more high-end hardware.
On the implementation:
Why two env_t values? One should be enough. The second is only needed temporary, see below.
The code in poll_event is very hackish. Rather sent a size event with an extra parameter with the requested new dpi. This the can call gui_themes etc. Also, one could scale window positions in rdwr_all_win and gui_frame_t(), not in the event routine (maybe).
win_reload_windows_after_gui_scale is just used one time, so no need for a new routine. Also, when gui_themes_init is called from an event, just queue the event once from the dialog.
What is the font_t::swap routine needed for? Font scaling worked already without ...
The offset of the tooltip should be relative to LINE_SPACE and D_H_SPACE. The fixed values were rather ancient left-over.
On gui_themes_t. Why the skinverwaltung_t::restore_all_skins() was removed? Maybe a comment would help?
Also the scaling is always done with the two zoom values. Hence, the gui_init could at first determine those two values and then scaling could use a macro
Code Select
SCALE(i) (((i)*gui_themes_t::zoom_up)/gui_themes_t::zoom_down)Now, this is done via MACRO plus two functions, not very clear and much more code. Not to mention, those two give anyway the factor the image are finally scaled ...gfx->get_image_offset should probably return the image size on simgraph0.cc since it is loaded nowadays anyway. Would remove the if condition.