| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This ensures the window gets resized properly when a user changes
the scaler options in the GUI. Simply unlocking the window size on
a call to setGraphicsMode is not good enough, because the scaler
mode can be changed by games during mode switches, and we don't
want to reset the window size in that case.
|
|
32bpp cursor scaling is not available, but this should be fine as
many of the software scalers are not designed to work with >16bpp
data in any case.
This change also includes some minor cleanup of unnecessary #ifdefs
around code that works equally well with or without USE_RGB_COLOR,
to simplify the implementation.
|
|
Normally with SDL, a mouse motion event will be sent after the
system mouse cursor has been moved by a call to
SDL_WarpMouseInWindow, but if the system cursor cannot be moved
(e.g. because the window does not have mouse focus), games still
need to receive these mouse events so they can successfully update
the mouse position internally. Otherwise, games continue to think
the mouse is still in the original position and will continue to
try to perform whatever action is associated with that mouse
position.
Refs Trac#9689.
|
|
|
|
|
|
The SDL graphics manager was just ignoring calls from CursorMan to
set the cursor to a blank cursor, which meant engines that did not
immediately send a cursor to CursorMan at startup would still show
the launcher's cursor (usually with a broken palette).
The OpenGL graphics manager would try to generate and draw an
invalid cursor surface when receiving an empty cursor.
|
|
the cursor
The only reason we show the system cursor outside the game area is
to show users where their mouse is when the window is resized and
the mouse is outside the game area. If the game cannot be
interacted with, then the mouse also does not need to be shown in
the black areas.
|
|
This patch refactors the OpenGL and SDL graphics backends,
primarily to unify window scaling and mouse handling, and to
fix coordinate mapping between the ScummVM window and the
virtual game screen when they have different aspect ratios.
Unified code for these two backends has been moved to a new
header-only WindowedGraphicsManager class, so named because it
contains code for managing graphics managers that interact with
a windowing system and render virtual screens within a larger
physical content window.
The biggest behavioral change here is with the coordinate
system mapping:
Previously, mouse offsets were converted by mapping the whole
space within the window as input to the virtual game screen
without maintaining aspect ratio. This was done to prevent
'stickiness' when the mouse cursor was within the window but
outside of the virtual game screen, but it caused noticeable
distortion of mouse movement speed on the axis with blank
space.
Instead of introducing mouse speed distortion to prevent
stickiness, this patch changes coordinate transformation to
show the system cursor when the mouse moves outside of the virtual
game screen when mouse grab is off, or by holding the mouse inside
the virtual game screen (instead of the entire window) when mouse
grab is on.
This patch also improves some other properties of the
GraphicsManager/PaletteManager interfaces:
* Nullipotent operations (getWidth, getHeight, etc.) of the
PaletteManager/GraphicsManager interfaces are now const
* Methods marked `virtual` but not inherited by any subclass have
been de-virtualized
* Extra unnecessary calculations of hardware height in
SurfaceSdlGraphicsManager have been removed
* Methods have been renamed where appropriate for clarity
(setWindowSize -> handleResize, etc.)
* C++11 support improved with `override` specifier added on
overridden virtual methods in subclasses (primarily to avoid
myself accidentally creating new methods in the subclasses
by changing types/names during refactoring)
Additional refactoring can and should be done at some point to
continue to deduplicate code between the OpenGL and SDL backends.
Since the primary goal here was to improve the coordinate mapping,
full refactoring of these backends was not completed here.
|
|
The GUI is not redrawn when the window size changes, but that is
not as important as being able to resize the games themselves.
|
|
|
|
ports
|
|
There is no particular reason why backends that don't need to
calculate screen dimensions in advance should still need to
implement initSizeHint at this point.
|
|
|
|
|
|
This flag is removed for a few reasons:
* Engines universally set this flag to true for widths > 320,
which made it redundant everywhere;
* This flag functioned primarily as a "force 1x scaler" flag,
since its behaviour was almost completely undocumented and users
would need to figure out that they'd need an explicit non-default
scaler set to get a scaler to operate at widths > 320;
* (Most importantly) engines should not be in the business of
deciding how the backend may choose to render its virtual screen.
The choice of rendering behaviour belongs to the user, and the
backend, in that order.
A nearby future commit restores the default1x scaler behaviour in
the SDL backend code for the moment, but in the future it is my
hope that there will be a better configuration UI to allow users
to specify how they want scaling to work for high resolutions.
|
|
This change allows:
* Engines to update their target rendering surface/size and pixel
format with the backend multiple times during gameplay;
* Users to resize the ScummVM window without having it reset
size/position every time an engine updates its target surface
format;
* Conversions/scaling to continue to run efficiently in hardware,
instead of requiring engines to pick their maximum possible
output format once and upscale inefficiently in software;
* The window to reset size once when an engine calls to set its
initial output size, and to reset again once ScummVM returns to
the launcher.
This is relevant for at least SCI32 and DreamWeb engines, which
perform graphics mode switches during games.
|
|
This function is only defined when USE_RGB_COLOR is defined so
these additional conditions are redundant.
|
|
|
|
_hwscreen is always initialized to 16bpp so the supported 32bpp
pixel formats would never be put into the list of supported pixel
formats, making it useless for engines to query for usable 32bpp
pixel formats.
This patch changes things so that the native desktop pixel format
is at the top of the supported formats list, and all pixel formats
<= the default desktop pixel format will now show up in the list
of supported formats. ("Supported" is somewhat of a misnomer here
since there is no hardware querying beyond checking the default
desktop pixel format. SDL generally accepts a wide variety of pixel
formats and tries to convert them to whatever the hardware
supports.)
|
|
Translation strings come from external data sources and can cause
a stack buffer overflow here just by accidentally (or maliciously)
being too long.
|
|
|
|
Previously we were clearing the whole backbuffer for 3 frames after a
window size change, and then only clearing the game area. This assumes
the OpenGL driver uses at most 3 render buffer and uses them in
sequential order. This does not seem to be the case on Linux when using
an Intel integrated GPU.
Instead we now clear the whole backbuffer on each frame to make sure
there are no leftovers remaining on the screen. All semi-recent GPUs
should have hardware clear anyway so this should not impact negatively
performance.
Possibly fixes #10025.
|
|
This reverts commit eefa72afa1978a9dea10f5b1833fcc8f58a3468e.
With this patch ConfigManager is broken.
|
|
This fixes tons of warnings with clang from a recent xcode version on
macOS (and possibly other systems) complaining that an instantiation
of _singleton is required but no definition is available.
|
|
Destroying and recreating the SDL window whenever the video mode
changes in SDL2 is not necessary and causes several problems:
1. In windowed mode, the game window shifts position;
2. In fullscreen mode in macOS, every time the window is
recreated, it causes the OS to play its switch-to-fullscreen
animation again and emit system alert noises;
3. The window content flickers; and
4. The engine loses events from the old destroyed window.
This patch changes the SDL backend code to avoid destroying and
recreating the SDL window when using SDL2, except when switching
OpenGL modes, since there is no way to change the OpenGL feature
of a window.
There are still some outstanding issues with OpenGL where window
size ends up getting reset even though the user has resized it;
this will probably need to be addressed at some point in another
patch.
Thanks to @bgK and @criezy for their feedback which made this
patch much better.
Co-Authored-By: Bastien Bouclet <bastien.bouclet@gmail.com>
|
|
Closes gh-948.
|
|
Updating the cursor's texture is not necessary if it is not going to be drawn.
Fixes glDrawArrays sometimes failing due to using a framebuffer with an
incomplete color attachment. In SCI32 games, the framebuffer is incomplete
because the engine does not define pixel data for the cursor.
|
|
In particular this adds a warning when failing to save a screenshot
in OpenGL mode (there was already one in SurfaceSDL mode).
|
|
|
|
This fixes bug #9701: WINDOWS: Flow of taking screenshots
on Windows is broken
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We don't need to recreate the window when turning filtering on or off.
Only the texture needs to be recreated.
|
|
|
|
Crtl-Alt-f now enables/disables filtering instead of changing the
graphics mode. Since there is only one graphics mode now, a hotkey
to change it is a bit useless.
|
|
This implements the request from ticket #9573: SDL1/2: Different
rendering/filtering?
|
|
This replaces the two graphics modes "OpenGL (No filtering)" and
"OpenGL". Now there is a single "OpenGL" mode and filtering is
controlled by the kFeatureFilteringMode.
|
|
Also change some OSD messages to be the same or similar to
messages used by the Surface SDL code.
|
|
Previous releases also did full screen updates for transparent OSD messages.
There should be no performance regression with that regard.
Computing smaller update rects is non trivial, but should be looked into if
performance is an issue for OSD icons.
Fixes #9598
|
|
|
|
|
|
It is no longer being called by another thread.
|
