Direct Input MADNESS!

This is a discussion on Direct Input MADNESS! within the Game Programming forums, part of the General Programming Boards category; Unless you're retrieving joystick data, you shouldn't use DirectInput. Even MS actively discourages its use for anything other than Joysticks. ...

  1. #16
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    Unless you're retrieving joystick data, you shouldn't use DirectInput. Even MS actively discourages its use for anything other than Joysticks.
    Wrong.

    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.

    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.
    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.

    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.
    Last edited by VirtualAce; 09-03-2009 at 04:41 PM.

  2. #17
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    Threads merged since they are basically the same thing.

  3. #18
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,600
    Well, to be sure, when using a well-behaved API, mucking around with the internals is just making an ugly hack of what could have been a portable solution. But yes, as we all know, there are *some* API's out there that are just plain incomplete, and a hack is the only real solution. Worse yet, some aren't well documented and so you have to find things out by experimentation.

    On a side note, I have noticed that writing a robust keyboard translation routine for Win32 is really quite a pain. I often wonder just how many wasted man-hours have been devoted to the task? Way too many, I'm sure.

  4. #19
    Registered User
    Join Date
    Apr 2008
    Posts
    58
    I'm very sorry if I'm not explaining this clearly. I did not redefine the key defines or the macros. I was using the Direct Input macros and key defines.

    I used the Direct Input GetDeviceState() method and copied it to the "BYTE" array of 256 (BYTE is typedef'ed as an unsigned short by microsoft.), and then checked the state of array[30].

    When I checked this state, after pressing F2, the value of the array[30] was 128.
    However, after pressing F3, the value of array[30] was 32768. (Which is not a random number, it is the 15th bit in a short data type.)


    This was all done using DirectInput's pre-defined keys and macros -not my own defines!


    So...if I AND array[30] with 128, I get one key; Array[30] AND 32768 gives me a second key; Also, Array[30] AND (128 OR 32768) gives me both keys


    My question, was why are two keys being stored in a single array location?

    Thank you for any help you can provide.
    Last edited by arcaine01; 09-03-2009 at 06:42 PM.

  5. #20
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Quote Originally Posted by arcaine01 View Post
    I used the Direct Input GetDeviceState() method and copied it to the "BYTE" array of 256 (BYTE is typedef'ed as an unsigned short by microsoft.),
    What, did you think I don't have a copy of windef.h?
    Quote Originally Posted by windef.h
    typedef unsigned char BYTE;
    And you would think you would have noticed by now that DIK_F2 is 60, but you find it in index spot 30, and Num1 is 2, but you find it in spot 1, and Num3 is 4, but you find it in spot 2..............
    Last edited by tabstop; 09-03-2009 at 07:04 PM.

  6. #21
    Registered User
    Join Date
    Apr 2008
    Posts
    58
    ...wow. I'm very very very sorry for all the trouble I've caused. I guess when I was afk at work, someone redefined BYTE as an unsigned short in one of my included headers. That actually explains a ton...and makes me feel completely stupid for not seeing that before.

    Thank you for your help, and patience everyone.


    This thread can be closed now....and hopefully deleted so that no one knows about this embarrassing incident.

  7. #22
    Dae
    Dae is offline
    Deprecated Dae's Avatar
    Join Date
    Oct 2004
    Location
    Canada
    Posts
    1,034
    Quote Originally Posted by arcaine01 View Post
    ...wow. I'm very very very sorry for all the trouble i've caused. I guess when i was afk at work, someone redefined byte as an unsigned short in one of my included headers. That actually explains a ton...and makes me feel completely stupid for not seeing that before.

    Thank you for your help, and patience everyone.


    This thread can be closed now....and hopefully deleted so that no one knows about this embarrassing incident.
    MADNESS? This… is… SPARTA!






    Couldn't help myself, but the topic is being closed anyway.
    Warning: Have doubt in anything I post.

    GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101

  8. #23
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    No trouble caused just trying to point out some serious flaws. I'm glad you found the problem and hope that DirectInput does what you need it to from now on. If you have any more problems just ask here on the appropriate board and we will do our best to help you.

    It has been my experience on this board that there are very few issues, if any, that collectively we cannot solve.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. can someone help me with these errors please code included
    By geekrockergal in forum C Programming
    Replies: 7
    Last Post: 02-10-2009, 01:20 PM
  2. I would love some input on my BST tree.
    By StevenGarcia in forum C++ Programming
    Replies: 4
    Last Post: 01-15-2007, 12:22 AM
  3. About aes
    By gumit in forum C Programming
    Replies: 13
    Last Post: 10-24-2006, 03:42 PM
  4. Structure and Linked List User Input Question
    By kevndale79 in forum C Programming
    Replies: 16
    Last Post: 10-05-2006, 11:09 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21