Wrong.Unless you're retrieving joystick data, you shouldn't use DirectInput. Even MS actively discourages its use for anything other than Joysticks.
For FPS games or where the mouse is used as a camera control you should use DirectInput.
For interfacing with an on-screen GUI you should use GetCursorPos().
The only reason for the disparity is b/c DirectInput returns mouse coordinates in device coordinates and not physical coords. There is no way to get the 'mickeys' in DirectInput and thus no way to translate the mousestate data into physical coords. GetCursorPos() returns the information in physical pixels which is much simpler to work with for GUI. However GetCursorPos() is terrible for mouse control such as those found in FPS's b/c it is both imprecise and cumbersome since it returns the absolute coords of the mouse instead of the relative coords. DirectInput can be put into absolute coordinate mode but it will still suffer from the issues I have mentioned.
DirectInput is also fine and preferred for reading keyboard data since this does not have 'mickeys' or any data that needs to be transformed between coordinate spaces. If you are using GetAsyncKeyState() or another Win32 API function you are slowing the system down b/c the Win32 API does not have the fastest functions b/c they were written for robustness not for speed. DirectInput is about as close to the hardware as you will get and therefore keyboard polling and buffering is extremely fast.
But what you cannot do here or on any other planet in the universe is AND some result with any old value and expect a meaningful result. The DirectX SDK clearly states you should AND with 0x80 to see if a key is down or up. Why in the world would you pick some other value and then claim that it does not work when it is you who made it not work? This makes no sense at all.
Normally yes but in this case it is perfectly ok to write your own key down function. All the pre-defined macro is going to do is AND the keystate array that you supply with 0x80. It is no different than preferring to manually release/delete and set your pointers to 0 as opposed to using SAFE_RELEASE() and SAFE_DELETE() provided by Microsoft. Also what is not provided and rarely, if ever, talked about is a way to detect if a full keypress occurred. All of the code I see on the internet and in books fails to supply this very simple function. However it is extremely important because if you just use key down you will run into issues. Let's say you want to switch camera views with some key. As long as the user holds the key down the views will continue to switch. What this means is you are forcing the user to use very very quick keystrokes just so the camera doesn't change two or more times. You must have a keypress check function in order to detect a complete key down/key up cycle.The moral of the story is that if you want to get things running properly, you should stick with the API defines and macros/functions to access everything. Even if you were to successfully process the data-structures "by-hand" (an interesting excercise, actually, if you've got some spare time on your hands, to be sure) it wouldn't be sufficient for production-quality code, since the underlying layout can change from system to system. In other words, aside from the purely academic excercise in curiosity, the approach is basically worthless.
Writing keyboard code for DirectInput is not much different than writing an old INT 9h interrupt handler that does the same. The only difference is you do not have to manually fill the array with data but other than that it is almost identical to old school keyboard input from way back in the DOS days. It is very simple and very fast. And guess what...back then you also had to AND the result with 0x80 to get anything meaningful from the data.
Originally Posted by arcaine01
