Tighter button debounce (or a way to set it)

I recently posted about some newly discovered trouble with my game on device. You press a button rapidly to increment a score, but very rapid pressing (which is expected in a certain context; see video in thread) isn't upping the score as fast, and after trying every relevant approach from the docs and the forum, I'm betting it's the system's button debounce, based also on this explanation.

Assuming there's a path via software, I'm imagining a way for extra-rapid button presses to be recognized in fewer cycles; a call to set/request a smaller debounce window for edge cases like mine. Thanks love u bye


Based on @dave ’s description, the maximum rate is 50hz. Humans can only press buttons in the 10-20hz range so this should be fine (note that this is different than timing a single press to a single 60hz frame. )

However, what I guess is happening is that the fast tapping, while being relatively slow, is spending less time pressed than unpressed. Either it’s not being held long enough to register, or it’s unregistering before your update.

Still interested in a definitive answer here, if Dave or someone from the team could lend one. I'm small potatoes, but in some respects this is make-or-break for the intent of the game...!

If we change from the current state mask to an event list we'd be able to handle multiple presses per frame: Inconsistent d-pad button input order - #3 by dave I'll try that soon, let y'all know how it works out.


Thanks for the info Dave! Looking forward to what comes.

Okay, here's what I wound up doing.. I decided this new behavior should be opt-in so that it doesn't present any surprises to existing code, so in Lua I've added playdate.setButtonQueueSize() to tell the system how many button events in a single frame you want to be able to handle. The callbacks come the normal way, through the playdate.[left/right/up/down/A/B]Button[Up/Down]() callbacks, and there's a new bonus argument to those functions in this case: the timestamp when the button press/release was recorded.

This was a nice excuse to finally add button callbacks to the C API, so over there I added playdate->system->setButtonCallback(cb, userdata, queuesize), where the callback looks like int buttoncb(PDButtons button, int down, uint32_t when, void* userdata).

Let me know if you have any feedback or questions! I've scheduled this for 2.2 (needs to wait for a minor release since it's an API addition), and I have no idea when we'll have that out. :person_shrugging:


Sounds good Dave -- no problem waiting, I just appreciate the work! Once that's live I'll update here again.

Hi @dave, was wondering if this is still slated for 2.2.x.

1 Like

Looks like it got moved to 2.4. :confused:

1 Like