Hey all. After going back and looking into some of Casey's initial input handling videos I'm trying to understand exactly how his scheme actually captures additional button presses per frame. Not sure if this he has implemented multiple polling in future lessons but initially he is just polling windows once for input and it seems like he saying this could potentially captures multiple button presses through one poll event. My question is if he is only polling once then would his processInput() function, which increments his transition count, only ever be able to capture 1 button press per frame? Meaning in order to take full advantage of his input scheme you would have to poll input multiple times? Or can the OS, in this case Windows, capture multiple inputs (if the user is really smashing the buttons) and call the processInput() function twice through one poll thus making use of Casey's input scheme from the start?
Edited by Jason
on
Reason: Initial post
If you're talking about an episode precisely give us the number so we can talk about the same thing.
When you press and release a key, windows will add messages in the message queue (first in, first out): WN_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN and WM_SYSKEYUP.
When you process key messages, you use either PeekMessage or GetMessage. Those functions will give you the next available message in the queue until there is no more message in the queue. If you press the same key several times there will be several key up/down messages in the queue for that key. If you keep calling the PeekMessage or GetMessage function, you'll get several messages and so you can count the transition count.
In pseudo code:
When you press and release a key, windows will add messages in the message queue (first in, first out): WN_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN and WM_SYSKEYUP.
When you process key messages, you use either PeekMessage or GetMessage. Those functions will give you the next available message in the queue until there is no more message in the queue. If you press the same key several times there will be several key up/down messages in the queue for that key. If you keep calling the PeekMessage or GetMessage function, you'll get several messages and so you can count the transition count.
In pseudo code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | main( ){
while (running) {
// Start input
while (message in the queue){
get the next message
update the transition count
}
// End input
update( )
render( )
}
}
|
I'm pretty sure Casey meant "polling once per frame". Not just "once for key". A mrmixer explained - you typically poll for all currently queued messages which will deliver you all the keys pressed since last time, including multiple presses. You will get messages like these: "key A down", "key A up", "key A down", .. etc, and then it is up to you to correctly update press count / down state.
Edited by Mārtiņš Možeiko
on