I got the impression a while back that writing games using Windows Messages was a bad thing. For example, Messages on WM_TIMER and messages for WSAAsyncSelect (winsock). I just wondered; can anyone explain why it would be a bad thing to use it?
I can only think of one reason really.
1. If you handle controls on WM_KEYDOWN and a key is helt down, then the message will not be sent to the window for a bit, but then sent rapidly, and this would make a strange control scheme, but for menus and such it may still be just what you need, so maybe it's OK for menus.
Other than that, I prefer WM_TIMER handling most as I feel its more flexible and right for games, at the same time as it seems to hammer the CPU less. For WinSock I usually handle messages in the handling of the set message when calling WSAAsyncSelect, but again I think it all comes down to how to make it work optimally.
Hope this helps at all :U
in WSAAsyncSelect, it'd be best if the hWnd is created in another thread. Otherwise, you hammer your main thread with WM_SOCKET messages all the time. (30-100 times per second, usually)
There's not much wrong about using WM_KEYDOWN/WM_CHAR in your game - Counter-Strike:Source does things this way, and thus chatting is perfect. Actually, not using WM_CHAR in games with chat is awful - the MMORPG "Endless-Online", for instance, gets pretty nagging while you're typing.
Chat aside, it's good enough to use GetAsyncKeyState for reading the default input (player's left/right/up/down, button1,button2,..). (I mean, instead of processing the WM_KEYDOWN).
Using WM_TIMER is not good enough, I actually never use it in my games. Instead, I setup a "GameMessages" queue(array), each element is:
GameMsg struct
TimeLeftToProcess dd ?
MessageType dd ?
MessageArg1 dd ?
MessageArg2 dd ?
GameMsg ends
Also, for some effects (gfx and sfx) that need delays, I use something similar to the GameMessages.