Xbox 360 Controller - Mac Os & Linux Problems !
BlitzMax Forums/BlitzMax Programming/Xbox 360 Controller - Mac Os & Linux Problems !
| ||
| I add Xbox 360 controller support to my game and it's working perfectly under windows (as always I want to say...). Of course, under Linux. While dmesg return : input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input5 Under BlitzMax JoyCount() return nothing ! And under MacOsX (when tattiebogle.net drivers installed) the joystick worked but JoyZ() and JoyR() act differently from the Windows One. Zero if the joystick is centered, -1.0 if Up, 1.0 if Down or a value inbetween. Under Windows it's working this way JoyZ goes to -1.0 if the right trigger is pressed down and goes to 1.0 if the left trigger is pressed down. but under MacOs JoyZ() start at -1.0 and goes to 1.0 when left trigger is pressed down and JoyR() (?) start at -1.0 and goes to 1.0 when right trigger is pressed down ! The problem is that under windows JoyR() is nothing related to the trigger but is in fact the Y Axis of the right Numb-Stick ! Windows JoyR and JoyU becomes JoyU and JoyV under Mac Os !? I will probably use the pre-compiler ?MacOs for the Mac problem (even if it's not a good solution at all, shouldn't this work the same way on every os ?) but What Can I do for the first one !? Last edited 2011 |
| ||
| I read somewhere in the forum from user RiK that I'm not the only one to discover that : In that OSX driver, the L trigger is mapped to JoyZ and the right one to JoyR. Left stick is JoyX/JoyY and right stick is JoyU/JoyV. What if the driver owner change his mind to do it the way it should or if someone at Apple/Microsoft release an official 360 Driver ? A schizophrenic Patch occur ^^ But most important ! If it's not a XBox 360 Controller then no need to use this driver, then this error does not occur and the ?MacOs need to test the joystick name to apply the patch or not... What a mess ! Is this the same mess under Linux ? Last edited 2011 |
| ||
| ...JoyHat() is not working under Mac too... Even under windows JoyHat() return 0.0 for UP and -1.0 for center. It's a non-sense because if there is a joystick without D-PAD then JoyHat() will always return 0.0 meaning always UP. I suppose I have to use something like : If JoyAxisCaps(port) & (1 Shl JOY_HAT) ... ' Joy Hat stuff endif I do not have tons of joystick to see how they are working under each os, each drivers. I will simply have to disable most of the joystick features when it's not a 360 under Windows. PFFFF it cost me a lot on this one ! It's like building a website in the 2000 with IE/Mozilla/Opera custom mess. Last edited 2011 |
| ||
| If you make a gamepad/joystick configuration system then it's up to the user to make it work right, and it works cross platform, and it work with more than just the 360 controller, and it doesn't matter if someone changes a driver, etc... More work but fixed functions always have problems, and there are also always people that have problems with them... most games let you customize the button layout even on consoles... |
| ||
| Yeah, you can already choose the mapping layout in my game for buttons, but I though that a D-Pad or a Stick would at least run the same way on every platform and configuration. I think that I have no choice but to add some kind of sub-configuration mapping switch in my game options. But about the JoyCount() not working under Linux and the JoyHat not detected under MacOs (while working in the system tool) there is not much I can do. By the way, it's probably a bad driver conception since when I unplug the 360 Controller from the Macbook, the keyboard stop working and I'm forced to restart the whole system (and this take a lot of time). Anyway JoyCount() is a bit like the CountGraphicsModes() they refuse to work correctly under certain configuration or drivers (mainly under Linux). |
| ||
| Are you using some drivers you installed under MacOS, or just what's active when you plug it in on a clean system? Unless there's a really wonky driver unplugging a device shouldn't affect the rest of the system... I don't have a wired 360 controller to test with unfortunately, but I know PS3 controllers play nice if you plug them in and then yank them out... Re:linux I don't dive too deep there with bmax unfortunately but it's always been a bastion of driver related headaches... love it as a core OS, but you really gotta know your stuff to set up a smooth system. |
| ||
| If you plug a wired Xbox 360 Controller in a Macbook nothing happen and nothing is detected. To solve this you have to install the only Driver I found here : http://tattiebogle.net/index.php/ProjectRoot/Xbox360Controller Since it is a personal driver, it's possible there is problem while using it. This explain why Z/R/V/U axis are messed-up. Does someone knows if in general the Z (corresponding to back trigger) R & U axis (corresponding to the right analog stick) respect the freejoy "template" ? Leave my user choose which axis does what in my game is pretty overwhelming. I'm 100% with you about Linux. When it's working it's really something good, but as soon as you have to setup drivers it's the worst thing I ever use ! I still use the only working nvidia graphic driver probably from 2007 on Mint or Ubuntu. By default, the Max IDE as well as any software build with it appear in the middle of my dual monitor. And if I switch to fullscreen depending on the Driver I get a giant resolution including both screen or a crash :) |
| ||
The button mappings between Windows and OS X(tattiebogle driver) are also different. I use this for mapping the buttons for Windows and Mac.?Win32 Const X360_A:Int=0 Const X360_B:Int=1 Const X360_X:Int=2 Const X360_Y:Int=3 Const X360_LB:Int=4 Const X360_RB:Int=5 Const X360_BACK:Int=6 Const X360_START:Int=7 Const X360_LSTICK:Int=8 Const X360_RSTICK:Int=9 Const X360_BIGX:Int=10 ?MacOS Const X360_A:Int=0 Const X360_B:Int=1 Const X360_X:Int=2 Const X360_Y:Int=3 Const X360_LB:Int=4 Const X360_RB:Int=5 Const X360_BACK:Int=9 Const X360_START:Int=8 Const X360_LSTICK:Int=6 Const X360_RSTICK:Int=7 Const X360_BIGX:Int=10 ?Hope you find it useful, but letting the user configure their own controls is probably the best option. Last edited 2011 |
| ||
| Thanks Oddball Yes this is probably more acceptable to have button not at the same place seeing how much joystick can be different. Since I already had a small configuration mapper in my game options, I enhance it to let the user choose which axis does does what but also add a Fix Analog Stick in order to allow Mac Os X User (and maybe Linux user using XBCD Driver, main source of TattieBogle I think) to work with the Tattiebogle driver. Because it non only support EOM XBox 360 but also many other Game Controller like Madcatz (or something). I let you imagine with 4 axis one D-Pad and 31 buttons how many preset it would have been possible to create... So better let the user setup this himself. To bad about the Tattiebogle not working exactly like it should with FreeJoy. |
| ||
| A word from Colin Munro, the developer behind the Tattiebogle driver: Hi, I'm aware of that difference, it was actually an intentional choice by me :) The reason I did it was that there is an implicit loss of information with creating a sum of the two separate readouts. The controller represents each trigger as an independent axis, and indeed, "native" XBox 360 games also see these axis separately. However, for whatever reason in the XNA driver Microsoft decided to throw away this information - if both triggers are pulled, the resulting value is the same as if neither are pulled. To me, that seems almost pointless (one example is Burnout Revenge, left trigger is brakes and right trigger is accelerator - often you're pulling both at the same time, and with the XNA driver, the game wouldn't be able to differentiate, just "throttle is at neutral", which is an important distinction between braking and accelerating :) ) Replicating the XNA behaviour would have obviously been simple, but I just couldn't abide by such a loss of data, so I decided my driver had to represent as much data as the controller reported, nothing less :) Sadly, I can't actually change the mapping of my driver anyway, some commercially released games have been hardcoded to use my driver and its current layout (made a huge mess when I didn't know this and released an update that changed the IORegistry layout!) Thanks, Colin So a pretty logic answer to a problem already discuss here in the Forum. I knew already the answer before asking, my intention wasn't to change this features but see if there was any easy workaround. Hope it will help some folks around :) |
| ||
| Good notes. Interesting yet depressingly not surprising that MS doesn't have proper drivers for their own hardware... Discarding data, especially when the console uses it is just stupid, the kind of stupid that makes me mad. Oh well, I'll stick to a ps3 controller emulated as 360... Dont like the layout as much but wireless+wire works (stupid charge and play cable is in reality just a charge cable if anyone is curious) |
| ||
| However, for whatever reason in the XNA driver Microsoft decided to throw away this information - if both triggers are pulled, the resulting value is the same as if neither are pulled. This isn't quite true. When using the XInput driver ( correct software to hardware driver for Windows ) it reports both triggers accurately and independently. I believe XNA uses a different dll but I'm sure the binary inside it will be the same, however I don't know this for a fact. The standard BMax driver also reports both triggers as cancelling each other out, hence why I wrote :- This Unfortunately it's Windows only as it uses the XInput.dll ( can you use Windows drivers on MacOS and Linux nowadays? ), but I'm only posting to point out that the statement above is incorrect. The other drivers must be missing something crucial. |
| ||
| If you have problems with the computer reading the X_360 controller it's probably because you're using a wireless controller and hooking it up to the computer with the play and charge kit. The play and charge kit's wire only transfer electricity to charge , nothing else. If you want to plug it in and use it , you need to buy a WIRED controller (I prefer the afterglow controller for 29.99 US$ ) |
   |