🔒 Locked

Best way to handle joysticks on Windows (XP onwards)

Started by Kylotan Jan 18, 2010 at 4:39 AM 8 replies 3.8k views

Original Post

Jan 18, 2010 at 4:39 AM

The other day I wrote some code using mmsystem.h and joyGetPosEx to read from my Xbox 360 controller, and it worked fine. The only exceptions were that the d-pad didn't register and the triggers were combined into one axis, but that was fine for my purposes. However I remember seeing recently that some people still recommend DirectInput for joysticks (as opposed to keyboard/mouse where it's deprecated). So I looked into that and although it seems to support lots more information (eg. axis rotation, velocity, etc), most of that I don't need. It also only seems to support 5 axes at most (x, y, z, plus rglSlider[2]) which implies it's not going to give an advantage over joyGetPosEx on that front. So does anybody have any experience of comparing these two systems have anything to say regarding them? I doubt I'll ever have any need to read a torque value or more than 15 buttons, if that makes a difference.

NineYearCycle

Jan 18, 2010 at 4:54 AM

Wierd coincidence, I added XInput to read from my X360 pad to a project last night :) I based it around a code-project example/tutorial Xbox 360 Controller Input in C++ with XInput.

If you're only reading from an X360 pad then I'd recommend using that. If you need to support legacy pads/joysticks/footpedal then you could try DirectInput.

Andy

Kylotan

Jan 18, 2010 at 4:57 AM

XInput isn't one of the 2 options I posted. :P

NineYearCycle

Jan 18, 2010 at 5:01 AM

True, but my un-written subtext (ah ha! maybe I should have written it instead?) was that joyGetPosEx is probably good enough unless you really need more info, in which case you should skip DirectInput and go straight to XInput since you're using an X360 pad anyway :)

Kylotan

Jan 18, 2010 at 5:09 AM

Mainly I'd like to avoid any extra dependency (eg. on XInput) plus the wider compatibility of joyGetPosEx is a good thing. It seems strange that they keep writing new libraries for this, each not being a complete superset of the last.

Promethium

Jan 18, 2010 at 5:11 AM

Another option (which you didn't post either! :P) you could try capturing Raw Input. It will probably require more work than any of the other two methods, but on the other hand it gives you total control over the input data.

For your OP I think DirectInput is still a good choice for non-mouse/keyboard input, but my own experience with DI is that it's rather convoluted and opaque. YMMV.

NineYearCycle

Jan 18, 2010 at 5:17 AM

Quote:
Original post by Promethium
For your OP I think DirectInput is still a good choice for non-mouse/keyboard input, but my own experience with DI is that it's rather convoluted and opaque. YMMV.

Indeed, I've never found DirectInput to be intuitive. It seems full of edge cases caused by trying to manage a wide range of different controllers within one API.

Endurion

Jan 18, 2010 at 10:26 AM

I've used both, joyGetPosEx for non-DirectX support (does 2 joysticks with 2 axis and 32 buttons) and DirectInput.

In both cases I'm using window messages for keyboard and mouse. Everything else is done with DirectInput.

Note that you should use the EnumObject function to really get everything a controller provides, not only the predefined GUIDs. It's a tad more work but usually you don't exchange configurations between different PCs.

I'm happy enough with DirectInput. The only advantage I see with XInput is that you know which button is where on the device. This you won't get with DInput, it's pretty much random.

You should do a input mapper anyhow, so that problem is rather moot.

I haven't looked into Raw Input, can it process every controller?

So far I see no alternative to DirectInput/window messages that lets me really use every controller.

magic_man

Jan 18, 2010 at 10:39 AM

Quote:
Original post by Kylotan
Mainly I'd like to avoid any extra dependency (eg. on XInput) plus the wider compatibility of joyGetPosEx is a good thing. It seems strange that they keep writing new libraries for this, each not being a complete superset of the last.

I find it interesting you say an extra dependency as it is shipped with DirectX runtime and SDK. DirectInput is a generic library whilst XInput is device specific, although if you look at the header there seems to be forward support for keyboards devices etc.
There is also the possibility of using Raw Input.

Kylotan

Jan 18, 2010 at 10:45 AM

I hadn't realised until today that XInput was distributed as part of DirectX 9. Generally the main thing against XInput for me is the limit to which controllers it can support.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.