Init ImGui after our GLContext object has been initialized and check the
context type to specify the proper GLSL version.
Also make sure we are not in GLES mode before setuping ImGui.
Originally authored by @magicmyth in PR #1039
ScummVM is optimised to render frames when something changes on screen.
As some host environments can perform poorly if the app does not
reliably refresh its output regularly (notably Steam overlay) this new
option ensures that Scummvm outputs a minimal amount of frames even if
nothing is changing in the game renderer.
Currently this is only implemented in the SDL OpenGL renderer.
The new config option is called force-frame-update and it takes a
integer value representing the desired minimum milliseconds Scummvm
should wait before forcing a screen update/refresh. E.g: 50.
Note that the rendering system will not force a re-draw of a frame if
the app has rendered a changed frame within the desired minimum refresh.
Thus if the app is outputting 30fps and force-frame-update is set to
100ms (~10fps) then no duplicate frame will be shown (in theory).
As this is implemented in OpenGLSdlGraphicsManager::updateScreen()
OpenGLGraphicsManager::_forceRedraw has had its access changed to
*protected* so that it can be access by it's descendant. The reason this
has been done in OpenGLSdlGraphicsManager::updateScreen() is so
SDL_GetTicks() can be used to track the elapsed time. If it is useful
for other platforms using OpenGL to have this feature it could be
implemented within OpenGLGraphicsManager::updateScreen() provided a
suitable platform independent replacement for SDL_GetTicks() is used.
This would potentially be better as OpenGLSdlGraphicsManager checks
various other states when deciding if the screen should update.
This unifies the ImGui processing for both 2D and 3D engine.
This also make sure we don't destroy ImGui if init failed (like on older
OpenGL).
The destroy callback is also called whenever we destroy the context.
Only do it when ImGui is enabled by the engine and move the check in SDL
backend where ImGui is supported.
This makes the OpenGL backend independent of ImGui.
Using the Ctrl+Alt+0 or 9 keymap
Also added a guard check for kFeatureScalers to allow the actions (kActionNextScaleFilter, kActionPreviousScaleFilter) to change scaler (but not scaler factor) in sdl/sdl-graphics.cpp
Size of the alpha channel is not set to its default value and this caused totally corrupted graphics on my PC.
See:
https://bugs.scummvm.org/ticket/13712
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.
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).
