I am developing 2D game and faced problem with simultaneous multiple key press / release detection needed, for instance, for character diagonal movement.
Problem is when I "simultaneous" (it has nothing to do with my reaction I press / release very quickly) press / release multiple (two) keys delay between messages often is much more than single frame (16ms with VSync), for instance, it can reach 50-100 millisecond, so character starts moving single direction and only after slight delay diagonal (as intended).
Is it normal for WinAPI messages or is it hardware limit? Is it possible to detect input faster or how games deal with it?
Only solution that kinda helps is process inputs in game logics with periodic delay (for instance every 100 ms), but this sacrifices control responsiveness very much.
I am dispatching WinAPI WM_KEYDOWN / WM_KEYUP messages in while loop.
while (PeekMessage(&message, 0, 0, 0, PM_REMOVE))
DispatchMessage(&message);
I also tried to dispatch input in seperate from render thread with GetMessage.
Delay measurement test project : pastebin
Actual OpenGL diagonal movement test project : pastebin
The straight answer is yes, delays of the order of 50 ms or so are common in processing key presses through the normal Windows message queue. I believe there are multiple sources of these delays.
First, the keyboard itself has a serial interface. Historically this was very slow, and probably tied to the underlying 55ms clock. A USB keyboard is likely to be much faster but the point is that each individual key press or release will be sent and processed individually, even if they appear to absolutely simultaneous.
The Windows code paths leading to the processing of Windows messages are long and the flow of intervening messages can be high. If there are many messages to process your simultaneous key releases may become separated by many other messages. You can reduce this by peeking messages instead of waiting for them, to a point.
So you really will have to use Raw Input, you're going to need to handle events quickly and you still need to anticipate delays. My guess is you're going to need to 'debounce' your input to the tune of at least 20ms to get smooth behaviour. There is lots of reading out there to help you on your way.