#2015 Arrow keys broken for gamepads on Android port

[Bob the Hamster]

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.

[TeeEmCee]

Maybe it has something to do with r6970, 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

[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

[TeeEmCee]

The correct default would be whichever it was before r6970, 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.

[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

[TeeEmCee]

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

[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.

[Bob the Hamster]

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

r7449 | 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.

[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 was doing.

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

[TeeEmCee]

This bug has been migrated to our new issue tracker on Github: https://github.com/ohrrpgce/ohrrpgce/issues/1074