News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

display broken by changing screen scale

Started by poppo, February 05, 2026, 02:52:09 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

poppo

when we change the window size of simutrans.exe with non-100% screen scale, display of simutrans is broken like this.break_display.png
  • I found this bug with Windows11, 64bit.
  • If not change window size, this scaling works well.
  • When using WSL and playing linux application sim, this bug does not occur.

prissi

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?

poppo

I download this simutrans.exe from sourceforge.
If my memory serves me correctly, it's a GDI version.

prissi

Could not reproduce. Maybe fixed by recent changes?

victor_18993

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.
En la vida todo son vivencias y cada una de ellas nos hace mas grandes,¿Como de grande eres tu? :)

victor_18993

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.
En la vida todo son vivencias y cada una de ellas nos hace mas grandes,¿Como de grande eres tu? :)