SDL: Mamximizinga window causes some Pixel rows to be lost. Maybe we need again a bitmap which whidth is dividable by 16. (I think this was removed not so long form SDL support).

It could be interesting to know if this changes with optimization settings, including USE_C on/off. There is a possibility that it fails because simgraph16.cc, after the compiler has done vectorization optimization, somehow expects rows to be 16-byte aligned. Although the last time I ran into alignment problems there, Simutrans crashed hard.

Judging by what was happening with GDI, it could easily be off by 1 resize logic. Until my patch last year every time full screen GDI was minimized and then restored it would expand the drawn image by a number of rows and columns to the bottom and right of the display because it was trying to do some nonsense rounding logic that kept interfering with itself. I removed this rounding logic from GDI and the issue went away, both in Standard and Extended.

Extended currently uses SDL but I have not noticed a problem with infinitely expanding back image when minimizing full screen.

Ever 100 or so row is missing, liek SDL tries to scale a slightly mismatched window. Seems also this is SDL2 specific. Unforutunately it happens on a tablet, where compiling is out of question due to low harddrive memory. I could not reproduce it on my main computer.

I would expect a maximized window to have a (internal) width matching the screen resolution, and those things have been divisible by 16 for as long as I've used computers.

Does the tablet have some form of status bar? Maybe there is some confusion between actual screen height and usable screen height, like the difference between rcMonitor and rcWork in MONITORINFO on Windows. If Simutrans ends up with a "textur" based on the former and tells SDL to present that into the latter, then that could cause such a mismatch and row skipping scaling.

I am pretty sure, it is the scaling code. When you maximise the window, the image is shortly distorted before almost ok. It also happens only when maximized. Normal windows are fine (and then the width is set to even values anyway.)

EDIT: Submitted a fix. THe screen width was really 1366, which had other undesired effects as well (like an endless loop of sizing messages too, forcing full redraw each frame [which explains while the CPU was usually working as crazy in full screen mode]).

The until now unknown to me 1366x768 format, I guess. Apparently a not-quite 16:9 pre-HD, yet more than the "HD ready" 1280x720, television resolution that has gotten a second life on handheld devices. The more computer-y 1360x768 can't have been 16:9 enough for them.

1366x768 is the most common screen resolution for computers for like 5~8 years actually. The majority of low-end laptops are still being sold with 1366x768, though 1920x1080 are starting to replace them. And back in 2010-2011 that was the common resolution for low and middle-end laptops. Only desktops and high-end laptops used higher resolutions.

simsys_s2.cc has existed since 2013 and given the number of edits done to it (unlike simsys_d.cc) someone must have been using it. The again, the reason for using SDL2 seems to have been better performance on HD and beyond.