| Age | Commit message (Collapse) | Author |
|---|
|
|
|
These are flagged by GCC if -Wswitch-default is enabled.
|
|
|
|
|
|
|
|
|
|
* OPENGL: Implement high DPI support on Android
* PSP2: Fix build
|
|
|
|
|
|
This removes the usage of memset to clear complex structures and replaces
them with constructor methods for the structures which will be executed
when these are instantiated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Four modes are supported:
- Use original size with no scaling
- Scale by an integral amount as much as possible but not bigger
than the window.
- Scale to fit the window while respecting the aspect ratio. There
may be black bars on the left and right, or on the top and bottom,
but not both. This is the default, and the old behaviour.
- Scale and stretch to fit the window. In this mode the aspecy ratio
is not respected and there is no black bars.
The mode is controled by the "scaling_mode" value (between 0 and 3) in
the config file.
Also add Crtl-Alt-s hotkey to cycle through scaling modes
|
|
|
|
|
|
The register keyword was deprecated from the C++11 standard,
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4193.html#809>,
and removed from the C++17 standard,
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4340>, so
cannot exist in a well-formed C++17 program.
It has never done anything in GCC
<https://gcc.gnu.org/ml/gcc/2010-05/msg00113.html>
and because of the way it is specified in the standard, it is “as
meaningful as whitespace”
<http://www.drdobbs.com/keywords-that-arent-or-comments-by-anoth/184403859>.
The one remaining use of the register keyword is in the DS backend,
where it is used to create a local register variable using the
non-standard GCC Extended Asm feature.
Closes gh-1079.
|
|
When a 32-bit cursor has the same size as an 8- or 16-bit cursor,
the mouse surfaces were not being regenerated even though the
32-bit cursors have a different memory requirement. This lead to
memory corruption as an inappropriate surface would be used for
the other type of cursor.
The shoe-horned 32-bit cursor support is clearly showing its
scrappy nature here and probably ought to be revisited in the
future if the SurfaceSdl graphics manager sticks around.
Fixes Trac#10349, Trac#10350, Trac#10351.
|
|
If a game is doing a screen shake (for example, DOTT when the
stereo is on), and the user does an RTL, the screen shake offset
may get stuck if the engine does not reset it on shutdown. To
avoid this in all cases, just always reset the screen shake
whenever the graphics manager is told to switch to a new graphics
mode.
|
|
SDL does not like this and will raise an assertion when built with
internal SDL assertions turned on. With internal assertions turned
off, it will still call SDL_SetError any time a null pointer is
passed, though it will not raise an assertion or crash.
|
|
Myst ME uses such cursors.
|
|
If we do not update the area below the message, it is just blitted on top
of itself again and again and gets progressively less transparent. It also
causes artefacts when the mouse pass below the OSD message.
|
|
On the OpenPandora handheld, the OSD message would not render unless you
moved the cursor in the area where it was supposed to show.
Additionally, the OSD message was not transparent like in v1.8.
This commit fixes both these issues.
|
|
I noticed that in Maemo the cursor was offset after the SDL refactoring
in de2bbe3b9738ef95b2529db989570770ef434f9d
In Maemo when entering fullscreen, ScummVM receives a SDL_VIDEORESIZE
event with the native touchscreen resolution rather than the current
window size. This causes a call to notifyResize.
Before that refactoring, notifyResize did nothing (in SDL1).
Now it calls handleResize but doesn't actually set a new video mode.
This messes up the coordinate mapping, causing an overcorrection for
the cursor position.
|
|
This may be a problem with SDL 2.0.4 generally, not just on
Windows, but it doesn't really matter much since it can't be
broken on *any* platform.
|
|
The SDL1 loop is not very optimal. Unfortunately all our existing
scalers only work in 16bpp and I don't have time to fix that right
now, so this is fine.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.)
|
