Quote:
Original post by Noobwaker Quote:
Original post by iNsAn1tY
Generally, using GetAsyncKeyState is frowned on. It's good for debugging and for demos and stuff, but not really that good for games.
Really? Why is that, may I ask? I would like to know if I should stop using GetAsyncKeyState in favor of something else.
To start with, it's inefficent. To monitor n keys, you need to make n calls to GetAsyncKeyState. It would be better to use something like GetKeyboardState. I think GetAsyncKeyState is also a rather slow function, but I couldn't dig up any evidence to support this; I'm probably wrong on that.
Also, why use it in the first place? Games are, in the vast majority of cases, fast enough to process Windows messages, and a good main loop should process all waiting Windows messages before continuing to update the game. This means that your input handling system (be it a simple bool array, or a sophisticated input routing system) can be completely updated by Windows messages, which you'll receive and have to process in one way or another anyway. You also get a lot more information from Windows messages through LPARAM and WPARAM, and the benefit of being able to rely on basic Windows functionality like repeat rates.
Granted, Windows messaging won't work very well for input if your game's update rate is very slow, if your message queue gets clogged by many instances of one message, like WM_MOUSEMOVE or WM_PAINT, or if you absolutely need to know at the instant of checking whether or not a particular key is physically down.
All of this is slightly superfluous in the end, though. In practice, it's probably not going to affect any aspect of your program if you poll the keyboard for input using GetAsyncKeyState, or run an event-driven system waiting for Windows keyboard messages. If what you're using works, keep using it unless it becomes a problem. Then look for a better solution.
