I've tried to figure out how to handle player input properly, but without luck so far.

As far as I have figured out, I can either:

Call the respective methods directly through the callback fired when an input event is detected.


Save the input in an array and detect it through my main loop.

I would like some thoughts on this in terms of if there is any restrictions/benefits using one over the other.


2 Answers 2


If you handle input directly from the OS's event callback (or similar platform events), you generally only have access to the data the OS gave you for that event. That data usually only pertains to the immediate input action (pressing this key or moving the mouse on that axis, and maybe some information about what modifiers were down). This can make it difficult to properly translate to handling your game's input if your game has more complicated inter-relationships with other input state.

If you instead do you input handling in your main update loop body via cached input state, you have access to all of that information. You may also more easily have access to information that lets you determine if a key is "still down" in a useful way (OS input events may be biased by key repeat delay).

Frankly, I think you should support both. Certain types of input lend themselves to being more easily handling with the first option, others with the second. Possibly even within the same game.

You can implement the second option in terms of the first; listen to input events from the OS or platform and in response, cache that somewhere for your main update loop to handle later. You can also implement a method of letting you game register callback hooks that you fire in response to those platform events, after you have cached the appropriate state.

That way, your game code can handle the input in whichever way makes the most sense for it.


Whether you handle input through callbacks or in the game loop have their advantages and disadvantages:

  • Using callbacks: this method make sure to detect any key the user press ,or any other form of input. Being an asynchronous event, any callback is fired at any time, granting real-time input detection. CONS: user input may affect your simulation at any possible moment, and this may lead to inconsistency between your game logic and what actually happens. It is absolutely acceptable for network packets to arrive at any moment, but their computation must not break the internal game logic.

  • Using game loop: Being the detection of input synchronized with the game loop, the input will be detected at a given moment, like just before computing physics and rendering. CONS: the user expects its input to be performed almost instantly, if your game loop cycles at a quite low frequency, a player may press a key right after input detection was performed, and at the next iteration such input could even be lost, forcing the player to press that key again. And maybe, getting upset.

Then, you can implement a hybrid system to detect input: you use callbacks to detect input in real-time, and save the current input scheme in the game, in order to be performed at the right time when the game loop iterates user input again.

Still, any method becomes seamless if your engine works at a high enough sync rate. Important is, not letting the input being computed at any moment, in order not to break game logic. A player pressing the Jump key expects his character to jump while standing on a floor, but not being in mid-air right over the edge of a platform.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .