Arrow keys broken for gamepads on Android port

[ohrrpgce-bugbot]

[sf#2015]

I am not sure when this started, but arrow key handling is totally broken on the Android port when playing with a gamepad (OUYA, Gamestick, FireTv)

This is most easily demonstrated with http://hamsterrepublic.com/tmp/inputtest-release-signed.apk

When playing inputtest on Windows/Mac/Linux or Android with the on-creen virtual gamepad, the arrow keys work as expected, turning red when pressed, or pink when held down.

When using a gamepad on an Android Console, pressing the analog stick causes the arrow keys to flicker green for a single tick, and then nothing. As for the D-Pad, it does absolutely nothing on a FireTV, and on an OUYA, the D-pad makes the arrow keys flicker green for one tick, remain dark for a few ticks, and then stay on solid green.

This definitely wasn't happening 10 months ago, so something has changed since then, but danged if I know what yet.

From: @bob-the-hamster
Reported version: 20130410 Beelzebufo
Operating system: Windows

[ohrrpgce-bugbot]

Comment author: @rversteegen

Maybe it has something to do with r6970 (17c8a7b), which changed anykeypressed:

Author: teeemcee <teeemcee@⁠7d344553-34f0-0310-a9b1-970ce8f1c3a2>
Date: Mon Jan 26 09:11:04 2015 +0000

    On-keypress scripts now triggered every tick when a key or mouse button is held.
    
    Previously they'd only be triggered each tick for move, use and cancel
    keys (since those also set carray()), and only triggered on mouse clicks

I think I see a bug!
DECLARE FUNCTION anykeypressed (byval checkjoystick as bool = YES, trigger_level as integer = 0) as integer
does not match
function anykeypressed (byval checkjoystick as bool = YES, trigger_level as integer = 1) as integer

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I don't know. I am seeing this in Vorpal florist which does not use an on-keypress script

I haven't had a chance to figure out which revision this started in. Lately my spare time for programming almost never happens when I am in the same room as my OUYA :P

As for that anykeypressed bug, which default for trigger_level is the correct one? The comments in the code make it clear what 0 and 1 mean, but not which is the appropriate default

[ohrrpgce-bugbot]

Comment author: @rversteegen

The correct default would be whichever it was before r6970 (17c8a7b), but I don't have a copy of the source in front of me (really ought to import it to github). I'm surprised though; I was quite sure that FB threw an error if the default arguments in the function declaration and definition don't match (if they are given in both places).

There were a few other changes to the keyboard and joystick input in allmodex.bas in the last 10 months. I would guess it's the changes to the joystick code which are to blame.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

Hmm... wait a minute... the line

DECLARE FUNCTION anykeypressed (byval checkjoystick as bool = YES, trigger_level as integer = 0) as integer

does not exist in my current copy of the source. the trigger_level defaults to 1 in both the .bas and .bi file.

Could that be a local change on your tree?

So this is probably a red herring, and unrelated to the Android gamepad bug

[ohrrpgce-bugbot]

Comment author: @rversteegen

I actually copied those lines from the diff for that commit, rather than checking the current source. Opps!

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I am now reasonably confident that this is two separate unrelated bugs

1. Analog gamepad input stopped working on Android at some point in the past year

2. D-pad input never worked on Android for FireTV, Gamestick, and certain other gamepad controllers synched with other android devices.

D-pad input on OUYA only ever worked because OUYA uses a somewhat non-standard D-pad which apparently behaves a lot more like a constrained Analog stick.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I finally had time to bisect my way through the history and find when this bug started.

r7449 (3d7ba3d) | james | 2015-09-09 10:28:58 -0700 (Wed, 09 Sep 2015) | 3 lines

Clean-up of update_virtual_gamepad_display()
It is now called on each tick, and no longer needs special arguments for being called
when advancing text boxes or inside battle

This was the revision where instead of calling update_virtual_gamepad_display() after each special menu, I switched to calling it once every tick (which fixed the "Hide V. Gamepad When Suspendplayer" feature to work properly)

I have not yet figured out exactly why this screws up just the arrow keys, and not the other buttons on the virtual gamepad.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

Okay, I have a good fix checked in for the first half of this bug. I understand why the analog stick stopped working. The code that shows/hides the virtual gamepad had to clear arrow key presses to prevent stuck keys when the shown/hidden state changed. This made the commands to show/hide the virtual gamepad unsafe to call every tick, which is exactly what revision 7449 (3d7ba3d) was doing.

As for the lack of D-pad support, I will have to look into that later.

[rversteegen]

This needs retesting.
The first joystick hat has only been mapped to dpad buttons since 2018. And joystick support was abysmally bad when it was handled in control() before 2018 (r10791 (6202343)).