News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Bugs in 120.3

Started by prissi, June 25, 2018, 02:59:52 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

prissi

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

No bankrupsy in server mode: My current server was not generated with freeplay, but no bankrupsy was activated. Investigating.

Ters

Quote from: prissi on June 25, 2018, 02:59:52 PM
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.

DrSuperGood

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.


prissi

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.

Ters

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.

It could also be the scaling code for SDL2 that's acting up.

prissi

#5
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]).

Ters

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.

An_dz

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.

Ters

Quote from: An_dz on June 27, 2018, 10:03:40 PM
1366x768 is the most common screen resolution for computers for like 5~8 years actually.
Indeed.  :-[  How did that fail to register in my mind? It must be getting full.


The odd thing is then that many must have run Simutrans at this screen width for years.

An_dz

Yes, but many must have been using the GDI version, that does not have this bug.

prissi

Only since 120.2 we released the SDL2 version.

Ters

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.

prissi

The reason for SDL2 was mainly stream, and then Unicode support. Old SDL did not support japanese input, so 33% of all Simutrans unser could not use this.