The International Simutrans Forum

Development => Patches & Projects => Incorporated Patches and Solved Bug Reports => Topic started by: poppo on February 05, 2026, 02:52:09 PM

Title: display broken by changing screen scale
Post by: poppo on February 05, 2026, 02:52:09 PM
when we change the window size of simutrans.exe with non-100% screen scale, display of simutrans is broken like this.break_display.png
Title: Re: display broken by changing screen scale
Post by: prissi on February 06, 2026, 01:47:03 PM
Which version, SDL3 or SDL2? I always use windows in window mode but did not see it. SDL3's SDL2 compatibility layer could be the problem. Self compiled version?
Title: Re: display broken by changing screen scale
Post by: poppo on February 06, 2026, 02:47:25 PM
I download this simutrans.exe from sourceforge.
If my memory serves me correctly, it's a GDI version.
Title: Re: display broken by changing screen scale
Post by: prissi on July 19, 2026, 07:54:01 AM
Could not reproduce. Maybe fixed by recent changes?
Title: Re: display broken by changing screen scale
Post by: victor_18993 on September 06, 2026, 03:25:41 AM
Hi, I managed to reproduce it in the 32-bit lab and found the cause, which predated the 32-bit lab. I'll try to prepare a valid candidate for Standard and OTRP.
Title: Re: display broken by changing screen scale
Post by: victor_18993 on September 06, 2026, 06:15:22 AM
Quick update on this issue.

The two Windows resize fixes for Standard have now been integrated into trunk:

- r12259 — FIX: on Windows a resize could be lost before it was applied
- r12260 — FIX: with display scaling the window was repainted at the wrong size

The investigation showed that these were two independent problems.

The first one was related to resize event delivery: under some timing conditions, the resize event could be lost before the new size was applied.

The second one was a DPI/unit mismatch in the Windows GDI repaint path. This explains why the issue could disappear at 100% display scaling while reproducing at higher scaling values such as 125% or 150%.

Both fixes were validated independently before integration, including negative controls, and the committed trunk contents were verified afterwards against the certified versions.

I also checked OTRP because it reproduces the same user-visible symptom.

Interestingly, the OTRP producer-side DPI error is not exactly the same as Standard's, so it required an OTRP-specific correction rather than simply copying the Standard patch.

That fix is now available as OTRP PR #721 and is waiting for maintainer review.

Current status:

Standard: integrated in trunk — r12259 + r12260
OTRP: PR #721 open for review

Thanks to everyone who helped narrow this down.