DirectInput vs. WM_INPUT vs. Raw windows input

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • In the documentation you find that DirectInput is no longer recommended, what it does is create a thread to listen to RAW input and then lets you query it, it is advised you to do it yourself.

      msdn.microsoft.com/en-us/library/windows/desktop/ee416842(v=vs.85).aspx

      Personally I use a combination of RAW and WM. I sometimes use wm_char for GUI, I also use wm_mouse related stuff for gui mostly, for actual gameplay I listen for RAW to have fast/precise mouse input, which is also relative and not absolute (even if you convert the WM_MOUSE to relative it will still get stack at the edges!) and comes more frequently.

      I also take to key presses (which I think is from WM_KEYDOWN and not RAW ?) for input which seems to be good enough.

      The post was edited 1 time, last by Shanee ().

    • I quite like dinput, it works fine for me. One of the things I like about it is that since it uses one interface you can design a base class that does all the donkey work, like polling for data, then you can just inherit for mouse, keyboard or joystick. Plus dinput's joystick support is way better than that new media rubbish MS has come out with.

    • Shanee is correct, DirectInput is indeed deprecated and just creates a thread to listen for Windows messages using the new stuff. In my own engine, I use DirectInput, though that's really just because I've been using it for 7+ years and haven't found a compelling reason to switch. I remember messing with the new windows raw input at some point and not being able to get reliable values between windowed and fullscreen mode, or something like that. I don't recall the exact problem, but it was enough make it not worth the headache.

      If I were to write a new game engine (or at least reimplement my input scheme from the ground up), I would probably use the newer raw input interface simply to be more current. Using deprecated libs is just asking for incompatibility issues with later versions.

      -Rez

    • WM_INPUT still having issues

      I have implemented two different ways of using WM_INPUT for capturing Kbd and Mouse messages however in both the mouse is unresponsive when the app is running although clicks, dbl-clicks, and key strokes are captured. I am not sure why the app hangs and why I can't do simple things like drag the window or maximize it.

      Using WM_INPUT is not easy, and I am also wondering if it makes more sense to just capture WM_LBUTTONDOWN and WM_CHAR messages since my game is a 2D platformer and doesn't need super fast input handling for the game play.

      Does anyone have any opinions on WM_INPUT, working examples, or opinions on windows input in general.

      Thanks in advance.

    • RE: WM_INPUT still having issues

      Originally posted by sosa
      I have implemented two different ways of using WM_INPUT for capturing Kbd and Mouse messages however in both the mouse is unresponsive when the app is running although clicks, dbl-clicks, and key strokes are captured. I am not sure why the app hangs and why I can't do simple things like drag the window or maximize it.

      I'm not sure what's up with this without being able to see the code. Are you letting the default windows procedure handle this event as well? What are the exact symptoms you're seeing? If you want to post your window proc function, that would help.


      Using WM_INPUT is not easy, and I am also wondering if it makes more sense to just capture WM_LBUTTONDOWN and WM_CHAR messages since my game is a 2D platformer and doesn't need super fast input handling for the game play.

      That's probably fine, just not very scalable. It's basically what we did in the book. Once the code is published, take a look at HumanView::VOnMsgProc() in HumanView.cpp, somewhere around line 225, to see how we handle input. WM_KEYDOWN and WM_KEYUP handle more things, while WM_CHAR is only used for the console.


      Does anyone have any opinions on WM_INPUT, working examples, or opinions on windows input in general.

      I've done it before, but I don't recall the specifics. As I said in my earlier post, I ended up just continuing with DirectInput in my own projects. There's not enough of a reason for me to rip out and refactor code that works just fine. Using the Windows message system is a bit of a pain and architecturally very different than DirectInput, so I'd have to completely change my input abstraction layer.

      If you just want something that works, take a look at that HumanView::VOnMsgProc() function.

      -Rez