The keyboard repeat event generator is used when building against SDL1.
Previously the repeat events would generate based on the event stream
produced by the keymapper which is not guaranteed to have matching up
and down events in the case the keymaps are changed while a key is
pressed.
Fixes#11417.
Game controller input is now enabled whenever a compatible device is
connected. The keymapper's keymaps are refreshed when a joystick is added
or removed.
Fixes#10366.
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.
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.
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.
Otherwise there is no way of generating these events, thus it's better to make
people really aware of this.
I furthermore added some nots that its part of a WIP API, thus it should only
be used after checking up.
It was badly broken after refactoring into EventObserver.
Fitst, deinit() method was never called which lead to bad record
files. Then, the concept of counting pollEvent() calls was ignored.
Introduced dispatchPoll() method of EventObserver which is implemented
in EventRecorder. It counts calls so is able to inject events at
more proper time.
Additionally now event times are recorded.
