Sign in to follow this  

Handling input; polling vs callbacks?

This topic is 1901 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,
I was reading through GLFW Users Guide (http://www.glfw.org/GLFWUsersGuide276.pdf, section 4.2.1) where it specifically says the recommended way of handling inputs is by specifying a callback to GLFW rather than polling() every now and then.

I was under the impression that polling() was a more 'controlled' way of doing it though, as a callback could occur at any time at any execution, so polling at a specific location in the game loop gives a more controlled way of handling input, especially in multithreaded applications.

Why would GLFW recommend callbacks, and what is the most optimal way of handling input, through callbacks or polling?

Share this post


Link to post
Share on other sites
[quote name='KaiserJohan' timestamp='1348738156' post='4984293']
Which approach would be prefered, and why?
[/quote]
As waterlimion said, I would prefer a combination of both. Using only polling could result in missing input, i.e. when you press a key to open a dialog and the key press is only valid for 20ms and your frame has a duration of 40ms, then you could miss this event when polling.

I would use a callback and save the event in a key map with a timestamp, the game loop would then poll this keymap (timestamp>= last_frame_timestamp) to react accordingly (good if you like to check several keys concurrently like WASD + Shift). Addtionally I would save the pressed key in an input buffer to handle typed text, if this is necessary.

Share this post


Link to post
Share on other sites
i store two sets of key states, one which saves the input state the game systems will use, and one which saves the actual state. Every frame before I poll the input both are the same, i.e. the actual input state is copied to the input state used by the game logic. Then while processing the inputs every button press is registered in both states, but button releases are only registered in the actual state.

Share this post


Link to post
Share on other sites
i use a callback system to create a queue of input between frames, at the start of the next frame, all input get's handled, then my gamestate runs off that merged input. this can potentially lead to missed input(such as a fast up/down release, which both occur in the same capture frame, so my final keystate remains "UP", however, since it received a down state, the key does get a "press" state, and since it received an up state, a corresponding "released" state flag gets set as well, which gets cleared on the next merger, so i never miss presses/releases, which allows for presses/releases to be activated regardless of how fast the user works.

Share this post


Link to post
Share on other sites

This topic is 1901 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this