Is it usually possible for the player to press and release a button within a single frame, so that the game engine doesn't have time to detect it?

How do programmers usually handle this situation? Is it even necessary to handle it?

While testing, I was able to press and release a button within about 14 or 15 milliseconds (over 1 click/frame). I was not, however, able to do this while holding the joystick normally, and the press-release cycle would have to start at almost the exact time the frame starts.

Specifically, I am asking about GLFW's joystick input capabilities.

I am currently using GLFW to make a game, and I've noticed that keyboard and mouse have callback functions, while joysticks do not. Also, it does not appear to be possible to enable "sticky keys" for a joystick. (I have only recently started using GLFW, so please correct me if I am wrong, as having either of those would solve the problem.)

Although I am asking about GLFW, answers related to any library/engine/language are welcome.

3 Answers
3

On Nintendo and Sony hardware we sometimes polled the input at a higher rate than we drew frames; use a timer-driven thread to look at the controller I/O at 120hz, for example, even when we were rendering at 30hz. By "a timer-driven thread" I mean there was a hardware timer that poked an interrupt that caused a particular function to get called in realtime. On these system the controller appeared as memory-mapped I/O, so you'd simply load a word out of a particular memory location and that would have the position of the joystick's X-axis at that moment. You'd save that off somewhere in main memory, and then when your main game loop ran it would have a history of 4 or 8 or however many samples of input data at a consistent time interval.

This wasn't to detect button-mashing, but to get crisp intraframe timing for fighting games where it mattered (because you were allowed to queue up inputs "before" a critical trigger frame in the animation, and the animation rate might not be as stable as we like, so we needed to distinguish whether you'd hit the button before the frame boundary or on it).

I don't know if it's possible with GFWL. DirectX's input system is pretty tightly bound to the render cycle, and there's a heck of a lot of operating system between you and the switches in the USB gamepad.

This is the best solution I have seen so far. As far as I know, joystick input, at least on Windows, is not tied to the render system in any way. By default, I'm polling input once per frame (when I swap buffers), but it's certainly possible to move this into a thread.
–
AlchemicalApplesJun 8 '12 at 20:09

Are you sure about that? I can possibly see a state transition going that fast here and there, but you do realize it would take a sustained 70 presses per second to see a button down every 14ms? Sorry but that is not physically possible, although perhaps you can induce it here and there with some crazy all-knuckles button-mashing, and maybe there is even some bounce in the hardware itself. Have you ever watched a video of professional StarCraft players, where they use all the fingers on one hand plus a mouse and click so fast it's a blur? Those guys are gods if they can do 300 actions per minute which is 5 per second using both hands...

That said, in general with a lot of games you just see input polled every frame. The possibility of an entire press-release-press happening within a frame and getting lost is pretty remote at interactive framerates, and I have never known a game developer to worry about this.

On some systems you may get buffered input. The system monitors the input devices asynchronously and fills up a queue with all the state changes that took place since the last query, and generally you would let the buffer fill up between frames and process it each frame, so the resolution may be higher than polling the state each frame.

Some systems are event driven, so you can register a callback that fires every time input state changes, although the resolution will be dependent on the rest of the software stack and may or may not be significantly better than a per-frame check. For example if the API is just polling the hardware every frame, comparing it to the last frame and then firing the applicable callbacks, you aren't doing any better.

With embedded systems and some old game systems that were programmed to the metal, you would have had interrupts for the buttons. An interrupt is a little piece of code you register with the system that runs every time something happens. In the case of a button interrupt, the hardware would be physically designed so that when the voltage on the wire connected to the button goes from low to high or high to low, it runs this bit of code. This would be the most direct and responsive system but most games these days have a ton of hardware and software between you and the buttons.

I do agree with what you're saying, but in this situation the average number of presses per second doesn't matter so much as how fast a single tap lasts. For example, in my tests, my average tap time (measured by the amount of time the button was in the "down" state) was around 50 ms. This does not mean, however, that I was pressing the button 20 times per second, as the average time the button was in the "released" state was about 150 ms. This shows that it is much easier to press and release a button in one frame rather than keep up an average 60 taps per second.
–
AlchemicalApplesJun 8 '12 at 20:05

OK, I see. That makes sense, similar to the situation Crashworks discussed with fighting games, where high-resolution timing of events is important. I definitely understand how this could be an issue for your, probably want to do asynchronous input sampling as he suggested.
–
SuboptimusJun 8 '12 at 20:45

Assuming a game running at 60 fps, each frame is about 17 milliseconds. Highly unlikely someone could press and release in that amount of time. If you can click fast enough to get about 60 clicks per second, then you'd be pressing and releasing fast enough to beat the frames.

This is true, but I can still see some edge cases where it can happen. Perhaps it is best to simply not worry about this, as a user pressing a button that quickly is probably doing it accidentally or is using a cheating tool. Though, I am still looking for a solution to the problem.
–
AlchemicalApplesJun 8 '12 at 4:51

No professional game does anything special to handle this, and you don't hear people complaining. Human being's can't press buttons that fast.
–
Sean MiddleditchJun 8 '12 at 6:29

2

@DBRalir If you're polling input there's no way to detect this, since as far as your program is concerned, it didn't happen. There are more important things to worry about than this exceptionally rare edge case.
–
Byte56♦Jun 8 '12 at 6:51

@Byte56 Yeah, I'm ignoring it. I can regularly get tap times under 15 ms, but that's usually going to overlap with the polling routine. For the program to miss the tap entirely, it would have to last around 7 ms, which doesn't seem possible. Thanks for your answer.
–
AlchemicalApplesJun 8 '12 at 6:56

Good to hear. Sounds like your game will be fast paced! That'll be fun. Good luck with it :)
–
Byte56♦Jun 8 '12 at 6:57