any value in polling keyboard several times per update on windows platform?

Hey there,

question somehow came out like a research article. However there is a question / request for validation of my assumption at the end :slight_smile: Thanks for your input!

I’m currently converting my game from fixed time step to some semi-fixed time step model, which can lead to several physics steps per game update. Now, my game is fast paced and I want to ensure as much responsiveness as possible, so I thought of polling keyboard and mouse per physics update step instead of only once per game update. My target platform is Windows, so I checked the monogame code: Mouse Input seems to be updated once per game update internally by monogame and is just passed by Mouse.GetState(), so for mouse it doesn’t make sense to poll several times per game update. For Keyboard.GetState() with windows however, the following method gets called internally by monogame:

private static extern bool GetKeyboardState(byte[] lpKeyState);

So I thought I could at least leverage on getting super imminent keyboard input. I did a test like this:

  bool i0down = false;
  for(int i = 0; i<2; i++)
    if(i == 0 && Keyboard.GetState().KeyDown(Keys.Space)) { i0down = true };
    if(i == 1 && i0down) { Breakpoint(); }

Breakpoint() never gets called, no matter how hard I keep smashing my space key. I also tried increasing the thread sleep, to make sure my motorics are not the limiting factor, but no luck.

I did some research on the user32.dll function “GetKeyboardState”:

An application can call this function to retrieve the current status of all the virtual keys. The status changes as a thread removes keyboard messages from its message queue. The status does not change as keyboard messages are posted to the thread’s message queue, nor does it change as keyboard messages are posted to or retrieved from message queues of other threads.

Tried to figure out when a thread in windows removes messages from its queue, but couldn’t find a source that I could cope with intellectually.

My question

I assume thread messages might be “removed” / therefore detected as pressed keys, by the time Game.Update() ends, is that correct? → this would mean, just as with mouse input, there is no value in polling keyboard input more than once per game update.

I wonder if this refers just to the applications general message queue (and I would assume that’s the case) - where each single key interaction is just registered as a single Message (key up, down). So windows internally would just maintain an array to reflect those messages and gives it to you.

I’ve had a quick look into the source and indeed monogame links itself into the windows message loop on the Idle Event (so when the window has processed all waiting messages or something like that).

I assume the windows messageloop will halt until “Game.Tick” has completed - Game.Tick calls your update function.

So I guess it’s safe to say, that keyboardstate will not change during a single call of the Update Method - it would be too slow to syncronize anyway.

ok that’s what I thought. Thanks for your input!