Resolves a bug with displaying the wrong (previous) translation when switch theme language
Previously, a translated string was stored in cloudmanager _storages config items, which would become stale if the theme language was changed.
When returning to the launcher with dynamic plugins enabled, the config manager
is re-created, invalidating the pointers the keymapper keeps to the
configuration domains.
Fixes#11348.
When launching a game, switch the graphics mode if necessary
(and by extension the pixel formats used for Graphics::Surfaces
and Sprites) to the one that most closely matches the pixel format
used in-game.
Additional Fixes:
- Fix to prevent cursor position from changing when exiting a menu.
- Fix to prevent updating of Magnification viewport position when
virtual keyboard is open.
- Cosmetic code fixes for improper whitespace and missing curly brackets.
- Remove RGB8 as a mode option because:
1) It was already commented out in the master 3DS backend.
2) There are currently no games that explicitly require it.
Notes:
- As these graphics modes are automatically implemented on a per-game basis, they
are meant for backend use only and are purposefully not accessible through the
Options menu.
- RGBA8 (aka RGBA8888) remains the default pixel format, being used for the launcher
menu, CLUT8, and for games which do not specify a particular format.
The documentation indicates that it should return the number of
milliseconds since the application started. It was however using
a different reference (last boot of the device minus the sleep time)
resulting in a much bigger value than expected.
warning: comparison is always false due to limited range of data type [-Wtype-limits]
s is Common::String. s[i] is thus a "char". If char is signed 8bit then the comparison will indeed always be false.
Previously backend defaults where added to the keymap defaults.
However, it became apparent backends need to change the default bindings
to resolve conflicts.
Backends can still (and do) generate such events. This works around an
issue with the keymapper where the "DOWN" event would be mapped to a
key, but the corresponding "UP" event would be mapped to another one due
to a keymap change. The keyboard repeat generation system would believe
the key to be still pressed and send a continuous stream of repeat
events.
Ideally the keymapper should be fixed to always generate matching event
pairs. However this source of an infinite stream of events still looks
like trouble waiting to happen to me. Hence disabling it by default.