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.
Custom engine actions are a new type of event the Keymapper can produce.
When an engine declares its keymap, it can declare it wants to receive
custom action events when the corresponding key is pressed, instead of
the originating hardware input events.
This system allows:
* Key bindings to be specified only once when declaring the keymap,
instead of twice (when handling the events).
* To truly rebind keys in the keymaps dialog. When using traditional
event mapping, the keymapper remaps the user keypress to the keypress
expected by the game engine to perform the action. However, the engine
still accepts the original keys.
The new concept of 'standard actions' defines a set of engine actions
that are commonly available in the games supported by ScummVM. Backends
can define default bindings for the standard actions to hardware
specific input devices.
