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.
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.
With some older versions of SDL1, the SDL_iconv_string takes
char * instead of const char * as it's argument. This should
fix the build issue with gp2xwiz.
This reverts commit 6b4195a542.
There seemed to be no clear benefit in using RLE for transparent
surfaces, and there were a few reports that it might cause crashes
on Windows. So to be on the safe side I prefer to revert this
commit.
- Flag them as repeat events
- Disable ScummVM's own repeat event generation
This fixes keyboard repeat events not being flagged as such with SDL2,
and complies with the user's operating system preferences regarding key
repeat timings.
This change allows:
* Engines to update their target rendering surface/size and pixel
format with the backend multiple times during gameplay;
* Users to resize the ScummVM window without having it reset
size/position every time an engine updates its target surface
format;
* Conversions/scaling to continue to run efficiently in hardware,
instead of requiring engines to pick their maximum possible
output format once and upscale inefficiently in software;
* The window to reset size once when an engine calls to set its
initial output size, and to reset again once ScummVM returns to
the launcher.
This is relevant for at least SCI32 and DreamWeb engines, which
perform graphics mode switches during games.
The thread locale concerns display options (e.g. date formatting) not
the display language. There are typically, but not necessarily the same,
as Windows allows them to be configured separately.
