The mouse position is set in window coordinates, but it's clipped to the
game area in drawable area coordinates. Previously, the scaling between
these two was not taken into account when calculating the right/bottom
edges of the game area. When the clipped mouse position was converted
back to window coordinates and rounded to the nearest integer, it could
end up on the edge of the game area, not inside of it. This leads to a
loop in which the clipped mouse position is outside of the game area and
needs to be clipped again.
This fixes bug #12646.
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
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 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
When switching between the SDL and OpenGL graphics managers, trying
to restore the state could fail as the two managers do not have the
same list of supported formats, so we may not be able to transfer
the pixel format from one to the other. This then resulted in an
assert.
This fixes bug #12079
- Use the fake constructor for message dialog less often
- solve errors regarding comparision between string and u32string in midi
- solve errors in testbed/speech related to ttsMan->say
- fix unsigned comparision warning in tab.cpp
- fix issue with static strings and translations in sdl-graphics
This commit also includes some additional major changes.
- Return U32String from TransMan getTranslation()
- Change tooltips to be U32Strings
- Remove temporary code of convertToU32String
- U32 Support various dialogs (Browser, FileBrowser, Messages, Chooser, etc)
- U32 for music plugins
- U32 for OSD messages
- Add some helper functions to ustr.cpp
- Change default tooltips from nullptr & 0 -> ""
- Some runtime exceptions may occur when changing languages due to incorrect String::Format
Use Common::FSNode to test for screenshot existence instead of
SDL_RWFromFile(). SDL does different character encoding conversions
which fail on Windows when a unicode character is in the path.
Fixes bug #11118
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.
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.
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.
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 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.
