Right now I'm kinda stuck. I can't decide on how I should get my input for the mouse/keyboard. I've been thinking of using directinput since I'm using directx anyway but is it really any better than the window messages? Then there's always other options like SDL or somesuch. I guess I just need to know more information before I make a commitement.

The best way to get input depends a lot on your requirements. So what are your requirements? Are you writing something that you want to port to another platform? Do you prefer ease of use over performance? Do you want to eventually support other devices in addition to the mouse and keyboard? And so on.

I haven't really planned to take my program onto any other platform other than windows which was why I chose directx and overall I would prefer performance over dev time.

Quote:Original post by eedok
Do you prefer to get input through a queue or do you prefer to check if a key is up or down?

A queue would seem safer than checking the key yourself, since then there's no risk of missing inputs, and you don't have to do interrupts...

Here's how I do it, which is something I'm particularly proud of. The input reader gets the input [in my case, through direct input], compares it to a mask of what keys/buttons/axis are accepting input, throws away the bad input [stuff like a mouse wheel spin when nothing in your game listens for mouse wheel spins],time stamps the good input, then uses one of several options of dispatch [in my case, a void function that accepting the input message, a queue accepting input message objects, or an address to a input message to be filled with available messages], sending the time-stamped and time-sorted input on it's way. These masks can be applied and removed dynamicly, with very little effort, and a single message can be sent to several devices if several are listening to the given key/button/ect.

The advantage of doing buffered input [which is what the above is] in general is that you get the chance to have the non-buffered data simply by applying the buffered data to a set of states, while you can't always derive a buffered input set from non-buffered data. This alone is a reason to ALWAYS go with buffered data, even if you're going to be converting it all into a non-buffered form anyway. Buffered data has the added advantage of not missing keys if your frame rate skips and your player pushes buttons quickly [a button pressed and released between input polls will show a button never having been pressed with non-buffered data, just as a button being released and reapplied will show as a button never having been released, and button clicks that occur while moving the mouse can be registered inaccurately, as either being at the old position, or the new position, as opposed to somewhere between]

KISS and use Windows messages. DirectInput will just give you an annoying-to-setup-and-use layer on top of the WM_INPUT message anyway. Myself, I just watch for WM_KEYDOWN/WM_KEYUP/WM_SYSKEYDOWN/WM_SYSKEYUP/WM_*MOUSE* messages. When I get them I append them to a list of input events held in my Window wrapper class. Then each frame I clear the list, process window events which populates the list, then iterate over it and handle them accordingly.

Ditto with what penwan said. I started off using DirectInput, but found it a little unwieldly for general use (for example, if you are trying to input a name into a textbox for example - i didnt find a way to handle the shift keys etc automatically). The windows messages provides an easier way in this regard.
It depends on your Game requirements though.

Alex