Xbox 360 Controllers for Windows diff coming to TGE 1.3 / T2D
by Jason Cahill · in Torque Game Builder · 11/21/2005 (12:24 am) · 49 replies
Who wants it? Because I'm putting the finishing touches on this sweet little bad boy (which will be ready before Thanksgiving on TDN). And, I'm not talking about doing it the crappy way (using the driver's built-in Joystick emulation). I'm talking about using the actual MS XInput APIs to go right to the device! That means actual mappings to things like:
actionMap.bind("xinput0", "A", "APressed();" "AReleased();");
actionMap.bind("xinput0", "START", "StartPressed();" "StartReleased();");
Oh yeah, that means graceful connection & disconnection of gamepads, support for up to four controllers on a single PC (mapped to "xinput0" to "xinput3"), the analog triggers work correctly (unlike the Joystick driver)... and wait for it... RUMBLE!
My source diff will also fix up TGE 1.3's poor support for traditional gamepads and also supports "fixed function" force-feedback rumble, in case you have an older Xbox 1 controller that you modded for your PC with XBCD drivers, or a PS-compatible dual strike controller with rumble.
In any event... it's all goodness for you guys. All I ask in return? That we politely voice our words of support to our GG gate keepers to get us a build of T2D 1.1. :-)
See... I'm a reasonable guy. I have something to offer quid... pro... quo.
actionMap.bind("xinput0", "A", "APressed();" "AReleased();");
actionMap.bind("xinput0", "START", "StartPressed();" "StartReleased();");
Oh yeah, that means graceful connection & disconnection of gamepads, support for up to four controllers on a single PC (mapped to "xinput0" to "xinput3"), the analog triggers work correctly (unlike the Joystick driver)... and wait for it... RUMBLE!
My source diff will also fix up TGE 1.3's poor support for traditional gamepads and also supports "fixed function" force-feedback rumble, in case you have an older Xbox 1 controller that you modded for your PC with XBCD drivers, or a PS-compatible dual strike controller with rumble.
In any event... it's all goodness for you guys. All I ask in return? That we politely voice our words of support to our GG gate keepers to get us a build of T2D 1.1. :-)
See... I'm a reasonable guy. I have something to offer quid... pro... quo.
Disclaimer: This diff will only work on Windows PCs running Windows 2000 or above with Direct X 9 (October 2005 edition) available for download right now at MSDN... You will need to purchase an Xbox 360 Game Controller (wired) or and Xbox 360 Game Controller (wireless) with the optional USB plug+charge cable attached... Sorry, no wireless controllers to the PC. :-(
About the author
#23
02/28/2006 (5:26 pm)
You have to have the DirectX SDK (October 2005) or later, as specified in the resource. Please download it from the link provided and you should be all set. If that doesn't fix it, it's because your Visual C++ directories are not including the DirectX include directory.
#25
Now for the issues!
I'm not sure what the deal is.
A week or two ago I downloaded the engine files and the examples. Everything worked great. Compiled my own executables no problem. Ran the samples, everything worked as it should.
I've changed nothing since then except copied my T2D directory to another folder. I went to recompile the engine (still using the files for adding 360 controller support). The executables all compile with no errors or warnings. However when i run the sample programs it will tell me there is no 360 controller connected.
If I copy the pre-compiled executable that came with the samples into my T2d Games directory then everything works great.
I figured it was me and did a clean install of everything to a completely different PC but i'm getting the same thing. I can compile all the source code a ok but it won't detect the controller.
I'm just using the pre-compiled executable for now but i'd really like to get to the bottom of this. Any insight would be greatly appreciated!
03/12/2006 (12:33 am)
First off I just want to say this is awsome and exactly what I needed. Huge 'Thank you' to Jason. Now for the issues!
I'm not sure what the deal is.
A week or two ago I downloaded the engine files and the examples. Everything worked great. Compiled my own executables no problem. Ran the samples, everything worked as it should.
I've changed nothing since then except copied my T2D directory to another folder. I went to recompile the engine (still using the files for adding 360 controller support). The executables all compile with no errors or warnings. However when i run the sample programs it will tell me there is no 360 controller connected.
If I copy the pre-compiled executable that came with the samples into my T2d Games directory then everything works great.
I figured it was me and did a clean install of everything to a completely different PC but i'm getting the same thing. I can compile all the source code a ok but it won't detect the controller.
I'm just using the pre-compiled executable for now but i'd really like to get to the bottom of this. Any insight would be greatly appreciated!
#26
The fact that the precompiled exe works, but your build doesn't tells me there's obviously something wrong with your build and not your machine. If you compare the console.log after running the precompiled exe and your exe, I'm curious if there's a difference? I do a little bit of console logging (consistent with other input devices being acquired). Do you ever see "XInput failed to acquire" or any other errors like that?
The other possibility (and please don't take this as me calling you an idiot), are you sure you have all of the source files for the diff in place and are you sure you are running the exe that you compiled? For example, Visual Studio, by default, builds a debug build resulting in T2D_DEBUG.exe. If you were running T2D.exe, and you didn't explicitly build a RELEASE build, then you might be running the wrong build. If none of these suggestions help, post back here and we'll work through it.
03/12/2006 (9:46 am)
Well, *that's* interesting.The fact that the precompiled exe works, but your build doesn't tells me there's obviously something wrong with your build and not your machine. If you compare the console.log after running the precompiled exe and your exe, I'm curious if there's a difference? I do a little bit of console logging (consistent with other input devices being acquired). Do you ever see "XInput failed to acquire" or any other errors like that?
The other possibility (and please don't take this as me calling you an idiot), are you sure you have all of the source files for the diff in place and are you sure you are running the exe that you compiled? For example, Visual Studio, by default, builds a debug build resulting in T2D_DEBUG.exe. If you were running T2D.exe, and you didn't explicitly build a RELEASE build, then you might be running the wrong build. If none of these suggestions help, post back here and we'll work through it.
#27
...
Or maybe I can.
I don't feel as dumb as I could have but for some reason the files in Visual Studio are the old versions despite the files in explorer being the new ones and the old versions not existing anywhere, but in Visual Studio.
*sigh*
Thanks for the help!
Hopefully if i have to post anything again its something more intelligent ;)
Quick Update:
Deleted all my T2d stuff, ran crap cleaner, re-installed everything and now it works.
03/12/2006 (12:10 pm)
Oh don't worry about the 'idiot' bit. This is most definitely PEBCAK, i just can't figure out what I'm doing wrong....
Or maybe I can.
I don't feel as dumb as I could have but for some reason the files in Visual Studio are the old versions despite the files in explorer being the new ones and the old versions not existing anywhere, but in Visual Studio.
*sigh*
Thanks for the help!
Hopefully if i have to post anything again its something more intelligent ;)
Quick Update:
Deleted all my T2d stuff, ran crap cleaner, re-installed everything and now it works.
#28
03/12/2006 (4:23 pm)
Awesome. Glad to help anytime Frank!
#29
05/10/2006 (11:23 am)
Unfortunately my diff wasn't checked into HEAD, so here's the download for the compiled B3 EXE (Ship build) with the XInput diff applied. No changes where necessary between the B2 and B3 diff of my code. If you want to do the integration yourself, simple continue to follow the instructions with this diff (given above). For those who don't want to build. Download the updated build here TGB-XInput-B3.zip.
#31
06/02/2006 (10:25 am)
Will this go into stock engine? I am thinking of binary-only people who may want to use this. And I am thinking of myself who recently tries to get by without source modifications (because that development so much easier).
#32
06/02/2006 (2:37 pm)
I've given the diff to Pat in the past and GG has my full blessing to check it into the code base. I wish they would too :-)
#33
06/03/2006 (7:37 am)
It would make sense with the XBox360 Live Arcade being so popular these days as an "indie" dev platform. :) 
#34
I am concerned with the implications of putting XInput into stock TGB and the reason is that it creates a dependancy on a very recent version of DirectX. The reason this concerns me is that I don't want newbies making a game with dependancies that will limit their target platforms.
I am not sure how to deal with this, and I'd actually like to get some feedback from you guys. Should this stay a resource? Should this have a seperate project file which links that library and compiles with a pre-processor define? What about the binary-only people? I don't want the binary relying on the semi-latest version of DirectX (since the casual games market is...how it is) and I don't want the binary users feeling ticked, and we also really can't do 2 exe's inside the binary-only SDK because that just added several megabytes to the download size. Then there is the issue of Mac/Windows...
I don't know, guys. Discuss. Tell me what you are thinking, because Justin and I talked about it more yesterday and we decided to punt on the problem.
06/03/2006 (10:54 am)
Hey, I've been mulling this over for a while and Justin and I discussed it a bit.I am concerned with the implications of putting XInput into stock TGB and the reason is that it creates a dependancy on a very recent version of DirectX. The reason this concerns me is that I don't want newbies making a game with dependancies that will limit their target platforms.
I am not sure how to deal with this, and I'd actually like to get some feedback from you guys. Should this stay a resource? Should this have a seperate project file which links that library and compiles with a pre-processor define? What about the binary-only people? I don't want the binary relying on the semi-latest version of DirectX (since the casual games market is...how it is) and I don't want the binary users feeling ticked, and we also really can't do 2 exe's inside the binary-only SDK because that just added several megabytes to the download size. Then there is the issue of Mac/Windows...
I don't know, guys. Discuss. Tell me what you are thinking, because Justin and I talked about it more yesterday and we decided to punt on the problem.
#35
06/03/2006 (7:41 pm)
Well, here's my thought: the whole XInput code is guarded so that if the latest version of the SDK isn't there, it doesn't work, but it fails gracefully. No one should be writing a game that depends solely on XInput. They should have a fallback to keyboard, at least. I say check it in! :-)
#36
What I've been thinking since reading Pat's post is this:
To me, it's not so much that it's implementing *Xbox 360* support as it is supporting game pads with that feature set *in general*. If that support is there - at the same level, mind you - without the code, I'd say leave the code out; but if good gamepad support isn't there without this code, I would have to vote for putting it in the binary build.
Ultimately it's just about having a robust set of choices. For our project, we've tried enough variations to decide that mouse and keyboard may in fact be a better route for the current implementation of our design. But, we were able to make that decision in the most informed way possible, thanks to this resource.
- Don
edited for spelling
06/03/2006 (7:48 pm)
Granted, I have a minimal understanding of the implications of including this code. I installed it as directed, compiled it, it ran, I moved on to mapping our game to the controller.What I've been thinking since reading Pat's post is this:
To me, it's not so much that it's implementing *Xbox 360* support as it is supporting game pads with that feature set *in general*. If that support is there - at the same level, mind you - without the code, I'd say leave the code out; but if good gamepad support isn't there without this code, I would have to vote for putting it in the binary build.
Ultimately it's just about having a robust set of choices. For our project, we've tried enough variations to decide that mouse and keyboard may in fact be a better route for the current implementation of our design. But, we were able to make that decision in the most informed way possible, thanks to this resource.
- Don
edited for spelling
#37
The best thing would be: The executable somehow checks at run-time if directX 9 is available and disables XInput if it isn't and provides some script hooks so scripters can have a fallback solution. But I guess this would not be easy with the actionMap code given.
06/04/2006 (1:46 am)
The same here: I just want good gamepad support. I didn't think so much of the consequences for the users and it is really a good point. I don't want to force my players to have dx9 for just the gamepad.The best thing would be: The executable somehow checks at run-time if directX 9 is available and disables XInput if it isn't and provides some script hooks so scripters can have a fallback solution. But I guess this would not be easy with the actionMap code given.
#38
I will do some experiments with this now :)
06/04/2006 (2:46 am)
Another question to you Pat: What about James Urguhart's DynamicLibrary resource? Will that be included (with some sort of script wrapper)? It would not help in this specific case, I guess. But it would open a way of adding custom resources to binary only users.I will do some experiments with this now :)
#39
is it safe to assume that your updating the sourcefiles for RC3? I've become pretty dependent on your 360 controller MOD..:)
Thanks!
06/17/2006 (12:01 pm)
Jason,is it safe to assume that your updating the sourcefiles for RC3? I've become pretty dependent on your 360 controller MOD..:)
Thanks!
#40
06/17/2006 (2:29 pm)
If this is just for XBox 360 controllers and not controllers in general and not for all of Torque's platforms, it might be better as a resource. 
Associate Melv May
Thanks for the extraordinary amount of work you've put in getting this article up there. Whilst I'm here, I'm kinda wondering about something as I recently posted here.
- Melv.