Inconsistent d-pad button input order

Hi! While debugging an input issue, I noticed that there is an inconsistency in the button callbacks and input handlers when quickly sweeping the d-pad from one side to the other. When going from right to left, leftButtonDown() can be called before rightButtonUp(), creating a brief moment where both sides are down. When going from left to right, leftButtonUp() is always called before rightButtonDown(). The same issue also occurs when going from down to up.

It's easy to reproduce in the simulator using the keyboard but it can happen on the hardware with the physical d-pad as well if you're fast enough.

I can work around this in the game logic easily enough but I think it should be fair to assume that the button up inputs will always happen before the opposite button down inputs for a d-pad.

Code:

function playdate.leftButtonDown()
    print("left: down")
end

function playdate.leftButtonUp()
    print("left: up")
end

function playdate.rightButtonDown()
    print("right: down")
end

function playdate.rightButtonUp()
    print("right: up")
end

function playdate.upButtonDown()
    print("up: down")
end

function playdate.upButtonUp()
    print("up: up")
end

function playdate.downButtonDown()
    print("down: down")
end

function playdate.downButtonUp()
    print("down: up")
end

function playdate.update() end

Output:

// left -> right:
left: down
left: up
right: down
right: up

// right -> left:
right: down
left: down
right: up
left: up

// up -> down:
up: down
up: up
down: down
down: up

// down->up:
down: down
up: down
down: up
up: up

I'll file an issue so we can investigate. Thanks for the feedback!

This surprised me since there's code that forces e.g. a right-up if it's currently down and a left-down comes in, but after changing the demo to track the state for each button and alert if both sides are down, I'm seeing it too. In the simulator it's easy, you hold left and press and release right. On the device if you press hard enough you can trigger the buttons in the same way.

Yeah, I see the problem.. The root issue is the button handler code doesn't know what order the ups and downs came in from the hardware/simulator, just whether there was an event and what the current state is. If we change that interface to an event list we can fix this problem and also Tighter button debounce (or a way to set it). I don't expect that'll be too tricky. :crossed_fingers:

3 Likes