* UPDATE: It's like the input problem in your other games: depending on how you press the key, it may skip screens, or it may just take a single input. If I press key "1," it will automatically choose level 1 (Normal). If I press the disc, it will stop at the menu. You should clear the buffer and wait for release before any key press.
Maybe Valter should consider writing a routine he can GOSUB to for discrete keypresses that first waits for nothing to be pressed, and then recognizes a new keypress. Or, even break it in two. I found with my own code that a "waitnokey" routine was extremely helpful all by itself. My "wait key" routine first did a "wait no key" before waiting for a key. And by "key", I mean any controller input in this context.
You want to act on a controller input as soon as it's recognized and debounced. And by acting on it, I mean drawing the next screen and setting things up to interpret new inputs in the context of a menu or title screen. But, you don't want to interpret new inputs until you've seen the controller(s) go "idle", so you don't recognize the first input as more than one input. I'm pretty sure that's the principle that dZ is highlighting above.
Once the game is live, that's a different story. But for title screens and menus, you want to cater to more deliberate actions.
As far as debouncing goes: The simplest algorithm works best for discrete inputs. If you see something change, wait a millisecond or two and sample again. If it's still the same, consider the input. If it's not, wait a millisecond or two and sample again. Loop until two consecutive samples are the same. As long as your loop is at least a millisecond or two, that'll eat most glitches. Just keep it below 16ms if you want to support 60Hz games.
Edited by intvnut, Sat Nov 29, 2014 4:05 AM.