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.
Normally, notifyMousePosition converts real mouse events into the
virtual coordinate system, but events only get sent through
notifyMousePosition if they are real events from SDL since that
method also decides if the real mouse is inside the content area or
not. As such, these fake events need to be pre-converted to virtual
coordinates or else the wrong values are sent through to the engine
when a scaler or AR correction is in use.
This reverts commit 6b4195a542.
There seemed to be no clear benefit in using RLE for transparent
surfaces, and there were a few reports that it might cause crashes
on Windows. So to be on the safe side I prefer to revert this
commit.
- Flag them as repeat events
- Disable ScummVM's own repeat event generation
This fixes keyboard repeat events not being flagged as such with SDL2,
and complies with the user's operating system preferences regarding key
repeat timings.
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.
Since those GraphcisManager initialize the cursor position to (0,0) when
created the cursor was jumping to the top left corner and then moving
back to its initial position as soon as the mouse was moved. Now it
stays at its initial position.
There are still some issues with it when changing between OpenGL and
SurfaceSDL at the same time as toggling fullscreen. But it is not worse
than before.
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.
Warnings are as follows:
"In the GNU C Library, "minor" is defined by <sys/sysmacros.h>.
For historical compatibility, it is currently defined by
<sys/types.h> as well, but we plan toremove this soon.
To use "minor", include <sys/sysmacros.h> directly. If you did
not intend to use a system-defined macro "minor", you should
undefine it after including <sys/types.h>"
Folks are confused about the new behaviour where the mouse is not
restricted to the game area in fullscreen, which is understandable.
This changes mouseIsGrabbed to use SDL directly in order to avoid
making changes to the user preference in the _inputGrabState.
Otherwise we'd either clobber the user's previous windowed mouse
grab preference, or require maintaining a second variable just to
track the original state, when we can have SDL do that for us.
I noticed that in Maemo the cursor was offset after the SDL refactoring
in de2bbe3b97
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.
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.
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.
