The Virtual Mouse is meant to provide a way to control the mouse cursor
on system without a physical mouse. It provides keymapper actions that
are expected to be bound to game controller axes or buttons.
This was a relatively short-lived port. We have it broken and
disabled on the buildbot since 2016. Also, the last builds
were provided in 2011. Thus, it makes a little sense to continue
to keep the code in the repository, as it gets bitrot.
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.
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.
rsn8887
Cameron Cawley
Bastien Bouclet
Eugene Sandulenko
Dries Harnie
Thanasis Antoniou
Michael Ball
Thierry Crozat