This hack was simulating repeated key presses (EVENT_KEYDOWN, then EVENT_KEYUP) for the arrow keys like the ones a physical keyboard sends
The hack could potentially cause further issues like spamming the events queue with many unnecessary events, and sending the events too quickly for some engines to handle
(thus missing some of them). We're now making use of the allowKbdRepeats() for the Up/Down/Left/Right event actions in the gui-manager, which will handle the case of a key
being kept pressed, sending an initial EVENT_KEYDOWN event and then subsequent EVENT_KEYDOWN events with the kbdRepeat flag set, and finally a single EVENT_KEYUP in the end.
Android itself handles repeated key events similarily (instead of a kbdRepeat flag, it updates a counter for the key repeats, which we translate to a simple flag).
This (and the hack that this replaces) affect things like moving the selection in the GUI lists (like the added games list) upwards or downwards continuously
while keeping the respective arrow key from the Android virtual keyboard pressed down.
This indicates that the cause of the vanishing mouse cursors appears to
be the loss of the palette data from a CLUT8 game cursor when the GMM
cursor which is ARGB is switched in. The SetMouseCursor implementation
currently does not setup the game cursor palette so the cursor is drawn
as all transparent i.e. default palette contents.
It is possible to toggle showing the text console as an overlay on the
screen by holding the Up direction arrow on the Wiimote and pressing
Button 1. This shows messages printed out via printf() / debug() and thus
can be used as a basic mechanism for debug output.
This does not work with the current libogc GDB stub on the Wii as the
GDB network stub support only works with the BBA (Broad Band Adapter)
for the Gamecube.
zlib is used when available and falls back on gzio.
This allows performance improvements as our CRC32 and gzio
implementations are slower than base zlib.
As zlib is available when libpng is present, this is sensible to
benefit from it.
The UITextField protocol function:
"textField: shouldChangeCharactersInRange: replacementString:"
was sometimes called with empty replacementStrings on key press
releases on keyboard. That triggered a backspace keyboard char to
be sent which caused problems when trying to remap actions to
other keyboard keys. No matter which key you were pressing the
resulting key would always be the backspace key.
Only handle text input using the UITextField protocol function
when the replacement string isn't empty. Handle all deletes through
the UITextInput protocol function "deleteBackword".
This has been tested in both cases when the UITextField is empty
(but GUI text field has text) and when the UITextField has text
(which has been added using the SoftKeyboard).
It has also been tested on Apple TV where a software keyboard is
shown with a big text field.
Instead of register input based on if hardware is connected or not
register input based on backend capabilities.
Mouse support is default supported through touch events on screen
(iOS) or touch on controller (Apple TV), and through connected
mouse hardwares. Gamepad controllers are supported from iOS 14 and
later.
Register mouse and gamepad input based on above capabilities to be
able to map actions to buttons on these input devices.
Keyboard support is to be added but not in this commit.
Remove the "isConnected" methods for each input and change the same
method for game controllers to a "isSupported" function to deal
with the iOS version support.
Remove the sending of the EVENT_INPUT_CHANGED event due to the
above reasons. The overide of the isConnected property function is
also removed due to this reason. It caused problems that key
mappings were reset on connections/disconnections.
The gamepad controller dpad button vaule change handler callback,
also called for the virtual controller dpad buttons, sent events
also for buttons not being pressed or released.
E.g. when the left dpad button was pressed an event was sent,
JOYSTICK_BUTTON_DPAD_LEFT with value 1 meaning it's pressed DOWN.
However, the other dpad buttons also did send their events but with
value 0 meaning UP. This had no impact for most of the games but
"The Griffon Legend" handles the dpad events a bit different where
the character is kept moving when the button is released. It meant
that the engine was triggering movements on both the event
EVENT_CUSTOM_ENGINE_ACTION_START and EVENT_CUSTOM_ENGINE_ACTION_END.
This commit changes the dpad button input handling so it remembers
the current state for UP/DOWN and LEFT/RIGHT. This ensures that only
the button that changes state is triggering an event.
The UITapGestureRecognizer is used to identify taps with two fingers,
sending an ESC key event. The UITapGestureRecognizer will not stop
touchesBegan from being called when doing a touch with two fingers.
Touching with two fingers when _mouseClickAndDragEnabled is enabled
will send a EVENT_RBUTTONDOWN.
But if doing a double tap the UITapGestureRecognizer with two fingers
will cancel the touchesEnded from being called meaning that no event
EVENT_RBUTTONUP will be sent to the engine. In some engines, e.g.
lure, this will cause problems since the engine might wait for mouse
clicks to be released before processing other events.
Fix the scenario above by introducing a delay of sending the event
EVENT_RBUTTONDOWN. If the UITapGestureRecognizer is triggered before
this timeout it will cancel the EVENT_RBUTTONDOWN by overwriting the
_queuedInputEvent with the ESC key event.
This commit also deletes the legacy implementation handling double
tap with two fingers to trigger an ESC event.
It should include all the valid axis defined in defaultJoystickAxes so the size should now be 8
The 2 extra since the previous size (6) is due to the addition of support for HAT_X and HAT_Y axis.
This fix allows the HAT_X+/- and HAT_Y/+- to operate as valid incoming events when mapped to an action (see Keymapper::convertToIncomingEventType())
Removed unnecessary normalization as Android already does this
Also fixed a wrong comparison in a clause for deciding to stop movement that was repeating
I optimized the NEON and Generic paths for ManagedSurface::blendBlitFrom
and the new TransparentSurface::blit. Now (on arm), the new blit function
matches the speed of the old blit function even with the added
inderections that the runtime extension detection code adds in.
Other than that, I made a benchmark for this code and you can make it
using this command:
CFLAGS="-DTEST_BLEND_SPEED" make test
I reverted wii to not use altivec anymore since it doesn't.
I also removed graphics/blit-neon.cpp from graphics/module.mk because
simply including the .cpp file in graphics/blit-alpha.cpp was a better
option because then I didn't need to instantiate every version of the
templates that I needed.
Some bluetooth keyboards also need "navigation" supported as configuration change
Tested with a new Lamtech bluetooth (BLE5) keyboard and also this is suggested here as well:
https://stackoverflow.com/a/27238892
It was wrong (other engines are allowed to do infinite recursions?) and
Future Wars still isn't working properly at all times. I've decided to
remove it (i.e. Future Wars and Operation Stealth are not supported
anymore).
Small updates in readme.txt.
exit() can be handled at user level via atexit(), there's no need to use
the critical handler routine.
Removed GEM restore from the critical handler as this uncovered its
instability while being in the critical handler.
