- Welcome to The International Simutrans Forum.
News:
.Recent posts
#61
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.
#62
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.
#63
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.
#64
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.
#65
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.
#66
Patches & Projects / Re: [Project proposal] Optiona...
Last post by prissi - October 04, 2026, 11:27:08 PMAbout the GIU settings, one can argue that the tooltip timings are not for the gui themes to config. Maybe some other too. Those things should be indeed removed from the gui themes loading and rather stay with the simuconf.tab. (Also, not sure if there is even a settings for those to alter manually. So on Android, one cannot change them at all.)
Also there are some env_t which rather belong to settings and vice versa. Maybe now would be a good time to review them too.
Losing old preferences was somewhat inteded, in order to start a second game with the same settings as an old game. Of not, there were the buttons in the settings to reset them to settings default or simuconf.tab. But this has become a mess. For instnace, when joining a server game, serveral local settings are overwritten.
Maybe, after saving a game (intentionally) or closing, write out the settings, and then reload them before loading or creating a new game. (Although, there are still the settings altered by network mode).
Commandline setting should override all simuconf.tab settings. If not, maybe that needs to correction.
The font thingy is from ancient versions, which could not use the system fonts. Hence, user preference should pervail. (Some for other stuff like button side, only one toolbar etc.)
I think commenting out default values in simuconf.tab is sensible.
I will up the savegame version on release date. The code to write out could be still there.
Also, for the settings.tab, there is no need to keep the backward compatibility, as most settings are anyway default.
Also there are some env_t which rather belong to settings and vice versa. Maybe now would be a good time to review them too.
Losing old preferences was somewhat inteded, in order to start a second game with the same settings as an old game. Of not, there were the buttons in the settings to reset them to settings default or simuconf.tab. But this has become a mess. For instnace, when joining a server game, serveral local settings are overwritten.
Maybe, after saving a game (intentionally) or closing, write out the settings, and then reload them before loading or creating a new game. (Although, there are still the settings altered by network mode).
Commandline setting should override all simuconf.tab settings. If not, maybe that needs to correction.
The font thingy is from ancient versions, which could not use the system fonts. Hence, user preference should pervail. (Some for other stuff like button side, only one toolbar etc.)
I think commenting out default values in simuconf.tab is sensible.
I will up the savegame version on release date. The code to write out could be still there.
Also, for the settings.tab, there is no need to keep the backward compatibility, as most settings are anyway default.
#67
Incorporated Patches and Solved Bug Reports / Re: [r12321] Most keyboard key...
Last post by hymie - October 04, 2026, 08:37:37 PMI downloaded r12331 and it's fixed.
Thank you very much.
Thank you very much.
#68
Bug Reports / Minor - silence a cmake warnin...
Last post by Nazalassa - October 04, 2026, 05:35:41 PMWhen compiling with CMake I get this warning:
Patch: http://patches.simutrans-germany.com/download.php?file=fix-cmake-warning.patch
(Note: being new to Cmake, I do not know if it is an elegant solution.)
Code Select
CMake Warning (dev) in CMakeLists.txt:
A logical block opening on the line
/src/simutrans/CMakeLists.txt:380 (if)
closes on the line
/src/simutrans/CMakeLists.txt:399 (endif)
with mis-matching arguments.
This warning is for project developers. Use -Wno-dev to suppress it.
Patch: http://patches.simutrans-germany.com/download.php?file=fix-cmake-warning.patch
(Note: being new to Cmake, I do not know if it is an elegant solution.)
#69
Patches & Projects / Re: [Project proposal] Optiona...
Last post by victor_18993 - October 04, 2026, 05:12:53 PMHi prissi,
I finished the second configuration audit against current trunk (r12331), after your revert of r12329.
The good news is that a savegame-independent settings.tab model looks technically workable, but I think there are still four policy decisions that should come from you before I turn the prototype into a real implementation.
A few things became clearer during testing:
- The 17 GUI-related values in the shipped simuconf.tab are exact duplicates of the env_t defaults. Commenting them out leaves first-run behaviour unchanged, but allows 13 of those GUI preferences to survive restart normally.
- settings.xml currently stores the effective value, not necessarily the user's remembered choice. So if simuconf overrides a preference and is later removed, the old preference has already been lost.
- A small settings.tab prototype can avoid that: remembered values are loaded before simuconf/theme/command-line overrides, and only GUI changes made during the session are written back.
- It also preserves independent changes from two running instances by merging with the file on disk before writing.
The prototype works on Windows for the full precedence matrix and the important cases also work on Linux, including UTF-8 paths and music_folder. It is still only a lab prototype, not an integration candidate.
There are four points where I would like your direction:
1. Should command-line settings be temporary for that run only, or should they change the remembered value as they effectively do today in some cases?
2. Should themes continue to override behavioural preferences such as tooltip timings / snap distance, even after user simuconf has been loaded?
3. Since the 17 shipped simuconf values are exact duplicates of env_t defaults, would you prefer them commented/removed so GUI choices can persist naturally?
Related: should saved font and SoundFont choices continue to override installation simuconf values as they do today?
4. The dormant music_folder field is still gated behind 125.6, while trunk still writes 125.5 and no official build has written the field yet.
Would you prefer removing that block now, or keeping it before the savegame minor eventually reaches 6?
Separately, I tested your suggestion for the music-folder dialog: adding destroy_win(this) to the folder-selection path works as expected. Both selecting a folder and Default close the dialog cleanly, and the correct choice is highlighted when reopening it.
I have the full audit and prototype results if useful, but I wanted to keep this message focused on the remaining design decisions.
I finished the second configuration audit against current trunk (r12331), after your revert of r12329.
The good news is that a savegame-independent settings.tab model looks technically workable, but I think there are still four policy decisions that should come from you before I turn the prototype into a real implementation.
A few things became clearer during testing:
- The 17 GUI-related values in the shipped simuconf.tab are exact duplicates of the env_t defaults. Commenting them out leaves first-run behaviour unchanged, but allows 13 of those GUI preferences to survive restart normally.
- settings.xml currently stores the effective value, not necessarily the user's remembered choice. So if simuconf overrides a preference and is later removed, the old preference has already been lost.
- A small settings.tab prototype can avoid that: remembered values are loaded before simuconf/theme/command-line overrides, and only GUI changes made during the session are written back.
- It also preserves independent changes from two running instances by merging with the file on disk before writing.
The prototype works on Windows for the full precedence matrix and the important cases also work on Linux, including UTF-8 paths and music_folder. It is still only a lab prototype, not an integration candidate.
There are four points where I would like your direction:
1. Should command-line settings be temporary for that run only, or should they change the remembered value as they effectively do today in some cases?
2. Should themes continue to override behavioural preferences such as tooltip timings / snap distance, even after user simuconf has been loaded?
3. Since the 17 shipped simuconf values are exact duplicates of env_t defaults, would you prefer them commented/removed so GUI choices can persist naturally?
Related: should saved font and SoundFont choices continue to override installation simuconf values as they do today?
4. The dormant music_folder field is still gated behind 125.6, while trunk still writes 125.5 and no official build has written the field yet.
Would you prefer removing that block now, or keeping it before the savegame minor eventually reaches 6?
Separately, I tested your suggestion for the music-folder dialog: adding destroy_win(this) to the folder-selection path works as expected. Both selecting a folder and Default close the dialog cleanly, and the correct choice is highlighted when reopening it.
I have the full audit and prototype results if useful, but I wanted to keep this message focused on the remaining design decisions.
#70
Patches & Projects / Re: Simutrans 32-bit graphics ...
Last post by victor_18993 - October 04, 2026, 04:39:56 PMHi prissi,
I finished the public testing build of the DAY + optional NIGHT prototype based on revised-11:
https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/xr32-prissi-night-image-prototype-01-r12322-testing-1
The short version is: your idea works well, but the measurements point to a hybrid approach rather than replacing the legacy path.
For new XR32 content:
- DAY + optional NIGHT works well;
- traditional player colours are preserved;
- the legacy dusk transition can be matched correctly;
- artists gain much more freedom for lights and night effects.
For old content:
- keeping the existing legacy path is clearly better;
- generating NIGHT images at load time is too expensive in memory and cache rebuild time.
The current measured cost for native DAY/NIGHT content is roughly:
- +75–93% XR32 image memory
- +20–47% cache rebuild cost
- +2–12% pak size
- no measurable per-frame difference in the tests
I also published makeobj for Windows and Linux x86_64, and both produce byte-identical test paks.
Before taking this any further, I think there are three design decisions worth discussing:
1. image identity / merging, because the current merge logic can associate the wrong extra XR32 data;
2. whether the extra NIGHT image memory cost is acceptable;
3. whether the pak format should use an explicit marker rather than relying on filename syntax.
So I would treat this as a public architecture prototype for discussion, not as revised-12 yet.
I finished the public testing build of the DAY + optional NIGHT prototype based on revised-11:
https://github.com/Dkijas/simutrans-true32-renderer/releases/tag/xr32-prissi-night-image-prototype-01-r12322-testing-1
The short version is: your idea works well, but the measurements point to a hybrid approach rather than replacing the legacy path.
For new XR32 content:
- DAY + optional NIGHT works well;
- traditional player colours are preserved;
- the legacy dusk transition can be matched correctly;
- artists gain much more freedom for lights and night effects.
For old content:
- keeping the existing legacy path is clearly better;
- generating NIGHT images at load time is too expensive in memory and cache rebuild time.
The current measured cost for native DAY/NIGHT content is roughly:
- +75–93% XR32 image memory
- +20–47% cache rebuild cost
- +2–12% pak size
- no measurable per-frame difference in the tests
I also published makeobj for Windows and Linux x86_64, and both produce byte-identical test paks.
Before taking this any further, I think there are three design decisions worth discussing:
1. image identity / merging, because the current merge logic can associate the wrong extra XR32 data;
2. whether the extra NIGHT image memory cost is acceptable;
3. whether the pak format should use an explicit marker rather than relying on filename syntax.
So I would treat this as a public architecture prototype for discussion, not as revised-12 yet.