Not sure if this is in the correct forum, but seeing as we're hoping for the controller plugin with 360 controller support, maybe it is.
Anyway, I finally got around to getting one today, and just like the ones for my 360, it's great, but I'm not happy that the driver doesn't seem to have any dead-zone support.
I've looked around the Internet for a solution, and there does seem to be a couple of hacks involving 3rd party software, but this is less than ideal.
So seeing as a few of you on here have already said they have one, I wondered how you managed with the lack of a dead-zone.
The specific problem is that if a game doesn't offer any built-in dead-zone setup, then the controller is read as being pushed in a direction even if it's only in the first couple of levels of the analogue range.
EDIT: Just in case it wasn't clear, this is with reference to playing games with it, not writing routines for it, which would be easy.
Maybe it's broken
The next build will have some support for XBox 360 controllers, but Davo's the only one with an XBox 360 controller out of the devs so talk to him
Develop games in your browser. Powerful, performant & highly capable.
Maybe it's broken
If only it was that simple.
It seems that it's a known problem, and a 3rd party solution is the only way forward.
I've found a program that comes well recommended by 360 controller users, although it's shareware.
I'm going to give it a go for the trial period and see how it goes.
For those in the same boat, here's the link:
Topic moved to OT.
Lots of analogue controllers have deadzones. The 360 plugin compensates for them so you dont have to worry about your character slowly moving when the user has the thumb stick in the 'neutral' zone.
I'm trying to work on a direct input plugin as well so other controllers work as well, but every controller seems to use different buttons and different 'axis' for stuff (as well as having different deadzones, arg!)
I tried designing a controller abstraction on top of SDL's once.
This bugged me too. SDL joysticks have axis, buttons, balls (yes, balls) and POVs.
Usually the first two axis and buttons are predictable, the rest isn't.
POVs can be considered as buttons, as I did. They're not that different and also makes for stronger controller logic. I merged balls and axis as a float, also made buttons a float that was either 0 or 1.
Thus, unified data from any input (keyboard was in there too).
My solution to the issue of what-is-where was to load an .ini file based on the joystick's reported name (by the driver) and use that to load proper string and image descriptions for each control.
This combined with configurable controls (for which there's already a plugin) makes for a sane and comfy system for the user, as you could show a cute icon with the button to press that matched the joystick you were playing with, like consoles do.
Also, making 'packs' for certain joystick models becomes really easy and one could always have a default set to use when the proper files are not installed.
Not even DirectX has it that good.
There is a third party driver program to run the 360 controller in XP. If you use Vista, the deadzone issue is resolved... however on XP you need the third party driver.
I can't remember what it is off-hand, but I'll go have a look on my other computer and report back here a bit later with a link.
Nevermind... I just had an appiphony