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?
Handling input; polling vs callbacks?
You can use callbacks to make sure you get all the input and build your own polling like system on top of it...
Maybe the GLFW polling might miss input if you dont poll it frequently enough?
Maybe the GLFW polling might miss input if you dont poll it frequently enough?
GLFW actually uses polling and evokes the callbacks when new messages for the window are in the queue. This is done automatically when you swap buffers, but this can be turned off if you want to control the polling for events manually.
That is, you call glfwPollEvents() and inside this function all of the callbacks will be called.
That is, you call glfwPollEvents() and inside this function all of the callbacks will be called.
Which approach would be prefered, and why?
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement