When entering fullscreen it was storing the default window size
in the config, which was overwriting the current window size. As
a result when exiting window size, instead of restoring to the
previous window size it was restoring to the default window size.
When loadVideoMode gets called to exit fullscreen, the window is
still fullscreen, which means that the SDL_WINDOW_MAXIMIZED is set
(at least on macOS). As a result the window was resized to the
stored maximized window size instead of the size it had before
entering fullscreen.
The OpenGLSDLGraphicsManager was changed in bb15133a0a to use
SDL_WINDOW_FULLSCREEN_DESKTOP instead of SDL_WINDOW_FULLSCREEN.
But getFeatureState(kFeatureFullscreenMode) was still checking
the SDL_WINDOW_FULLSCREEN flag. This worked because in current
SDL2 versions SDL_WINDOW_FULLSCREEN_DESKTOP is defined as
SDL_WINDOW_FULLSCREEN | 0x00001000, but this is not documented
and could change in future SDL versions.
The previous SdlGraphics3dManager::toggleFullScreen() was not using
beginGFXTransaction / endGFXTransaction in toggleFullScreen().
Restore this logic for 3D games, as using transactions in such games
results in a black screen for 3D games when switching to full screen
A regression from d33487f64
Instead of falling back to the normal scaler if the new scale factor is
1, explicitly check if the desired scaler is available at the new scale
factor. Suggested by criezy, and I'm shamelessly copying his
implementation because this sort of C++ trickery is something I'm not
fluent in.
At the moment, this shouldn't make any difference. But I guess in the
future, there may be a scaler that's available at 3x and 4x, but not 2x,
or something like that.
Now that we have higher scale factors than 3, it makes sense to try and
figure out a default scaler for high-resolution games that approximate
the window size of a low resolution game.
That also means that we are not necessarily restricted to the normal
scaler, since AdvMame has both 2x and 4x versions.
It looks like other platforms are not affected by this, at least I
wasn't able to reproduce the issue on Linux in any way.
Since branching off to the next release is very soon and we are running
out of time, I'm limiting this to Win32 in order to avoid unneccessary
breakage by only fixing _really_ affected platforms.
The SDL library handles HiDPI differently depending on the system.
On some systems, such as macOS, the drawable area and the SDL window
have a different size (the window is on low-dpi size) while on
other systems such as Windows they have the same size. Because of
that we sometimes need to scale sizes or coordinates between the
two, and sometimes we don't.
This was handled in two different ways. This commit change the code
to handle it consistently everywhere, and also should be more future
proof should SDL change the way it handles HiDPI in the future (as
we now query the size from SDL itself to find out if the scaling is
needed).
SDL handles HiDPI scaling differently depending on the system. On
macOS for example the SDL window size and SDL drawable area have a
different size (factor 2 usually) while on Windows they are the
same. When HiDPI is disabled (for the SDL Surface mode for example)
they are always the same.
We need to appl this scaling when converting cursor position between
the drawable area and the SDL window.
The previous implementation was already broken, since the values were never stored in the config file
since that part was already guarded by SDL_VERSION_ATLEAST.
Since we have no way to properly determine if a window is maximized or not for
SDL1, I recommend skipping this part in the compilation.
Now, the function at least works properly for SDL2 - it was broken on _both_ versions before.
The OpenGLSdlGraphics3dManager::getSupportedFormats() implementation
returns an empty list. This caused a crash when trying to get the
first element of the list in SdlGraphicsManager::setState().
This fixes bug #12762: The longest Journey crashes
Since we use the SDL_WINDOW_FULLSCREEN_DESKTOP with SDL2, we always
use the desktop resolution in fullscreen mode anyway. Cycling
through other resolutions did nothing and was confusing.
The grabOverlay() function would only copy half the width of the
overlay. This was probably more or less visible in any game that could
show a ScummVM dialog (e.g. the pause dialog in SCUMM games, or any
message box in the Hugo games).
Is crossBlit() overkill here? Probably, but it should fall back on
copyBlit() if the source and destination formats are the same.
Besides, this way perhaps I will finally get some more feedback on how
to fix the regression.
Orgad Shaneh
Paweł Kołodziejski
Alexandre Detiste
Vanfanel
Thierry Crozat
Filippos Karapetis
Torbjörn Andersson
Lothar Serra Mari
Eugene Sandulenko
athrxx
Cameron Cawley
Le Philousophe
Paul Gilbert