WM_KEYDOWN || DirectInput

Unless you need the extra features offered by DirectInput, WM_KEYDOWN and WM_KEYUP messages are fine.
I like to create a wrapper for the input, so I present a nice standard controller interface to the game, and can swap it for Windows/DirectX or whatever.

yes ive planed to do something like that.

one q can i ever miss a wm_keydown message or wm_keyup message.

No, you can''t lose one.

The problem with using WM_KEYDOWN/WM_KEYUP is that you don''t get the key state immediately. You only get what was happening at the time the message was placed on the queue.

DirectInput allows you to get the state information when you need it.

If you''re using WM_KEYDOWN/WM_KEYUP handlers to set key state information and then checking those states in your game loop, you may as well use DirectInput and add getting the key state info to the game loop. (That sentence was too long. Sorry.)

If all you need is "if key x is down, do this" you could use GetAsyncKeyState(). Unless your game loop is very slow, you won''t miss any keys.

oki thanks for you comments

With Buffered input under DirectX you''ll never lose a keystroke as well. The only major difference between the two is that the Direct Input handlers don''t automatically repeat characters like the windows handlers do. For the most part, I like this because it removes a chunk of code and often times you do not need the repeating characters anyway. I found that the Direct Input version of my input code was cleaner, neater and worked pretty much flawlessly.

I''ll admit I was pleased with the outcome, never implemented Windows message pump based input and probably won''t. Either way can be effective and your needs may be different than mine. Repeatable characters were simply not that important to me, so I opted for Direct Input.

Kressilac