In brief, why is Unity giving me the wrong data despite the Windows control panel applet working just fine?
Clearly the fault is within Unity… or I’m missing some initialization of the Input class?
Here is a paint (hi-tech) graph representation of the problem:
I’d just sat down to write a network daemon to serve the real data that I could subscribe to within Unity and then it hit me - WTF am I doing? It should work already.
So please, if anyone has any idea why the Unity input class is lying, help me
This is about XBox controllers, right? I don’t have an answer, but I know there’s been quite a bit of discussion in the past regarding idiosyncrasies with those controllers (and other controllers as well). Also, I think I remember mention of the axes for some controller or other generating data in the range [0, 1] rather than [-1, 1] (although that still doesn’t explain what you’re seeing).
Something else I’ve noticed is that (apparently) GetAxisRaw() doesn’t actually return the raw input value for controller axes, but rather the raw value scaled by the ‘sensitivity’ setting for that axis. However, that wouldn’t explain the mapping you’re seeing either.
From what you’ve described, it does seem like a potential bug (unless there’s something fundamental about controller input in Unity that I don’t understand). If it is in fact a bug, filing a bug report (if you haven’t already) would probably be your best bet, I think. I know that doesn’t help solve your problem in the short term, but it might be the best you can do right now.
But, maybe someone else will be able to provide a better answer.
I did notice after meddling with the scale variable that the raw data wasn’t really what it said on the tin. In fact, a weird side-effect of whatever is happening internally - when scaled down to 0.25, from left to right I got a little play left of the center, some on the right, then a large dead zone and a negative value again as if it wrapped around. Very wrong.
In other news I checked the raw USB data in WinDriver. On the X axis it’s an almost perfect FF to 00, left to right. So sadly, it looks like Unity’s the problem.
I’m just waiting for the DirectX SDK to download so I can hack together a few tests and potentially that daemon I mentioned as an interim workaround. For the last few years I’ve only had XBox controllers in the family, I’d imagine that be true of other users, so I’d really like to fix it without resorting to an external dependency.
I just encountered the same problem. For example, when i don’t touch the gamepad’s stick so it is in the neutral center position, Input.GetAxisRaw(“Horizontal”) returns -1 whereas it should return 0.
When I move the stick gradually to the right, Input.GetAxisRaw(“Horizontal”) rises smoothly from -1 to 1.
However, everything left from the center position returns 1. It’s exactly what ourben drawed in his first picture.
I use an cheap “impact 12-Button Dual Analog Rumble Pad”, but the pad worked correctly with all my other games and even the Windows callibration thingy.
It used to work within my Unity 2.6 project, but I can’t confirm this is still the case because I don’t have that version anymore.
Is there a solution to this?
Thanks Jesse, I filed a bug because my gamepad used to work in 2.6.
A few minutes after filing the bug report I found this post by andeeee. I tried the registry file he provided. Forcing Unity to take DirectInput instead of RawInput as Ignas in andeeee’s post suggested, seemed to solve my problem. Now I’m satisfied again
Wow, I’m glad I found this post. I had just reported a bug with the exact same symptoms.
I am working on a joystick controlled flying game. Windows’ Control Panel app and various other game device test utilities confirm that my joystick is working correctly. In Unity 2.6 the controls worked great. Older (2.6 based) builds of the game confirm that the joystick is still working fine in those builds. But after upgrading Unity from 2.6 to 3.1 the readings of the joystick axis are messed up.
For instance the x-axis when I move the joystick from left to right:
full left (center) full right
1 1 1 1 1 1 1 (1) -1 -0.5 0 0.5 1
It looks like only the right positions are mapped to a linear value of -1 to 1. All the left positions are mapped to 1. The center position alternates between 1 and a value close to -1.
Unity 3.1.0f4
Windows Vista SP1 x64
joystick: MS Sidewinder Precision Pro USB
The registry hack seems to have solved my problem for now. I’ll keep my fingers crossed for the next upgrade.
I still don’t know what exactly causes this in 3.1, just some updated informations.
Thanks to the mentioned registry hack, my gamepad works fine in the editor, but then I published the project as a
webplayer build just to test for a client.
Well, There it is again. The registry hack apparently works in editor and standalone mode only.
(That is what Ignas said in a forementioned thread, I must have overread that back then).
But still then there is the important question: Do all my customer need the hack, too?
However, I bought a Xbox wireless receiver and tested my wireless Xbox controller.
So far, I can confirm that there is no problem with it. It works where my other gamepad fails, even in webplayer builds.
Gah, I have been pulling my hair out on this one I’m glad I found this thread.
I’m using Custom Input Manager(CIM) which works fine for X360 controllers and my old MS Sidewinder Precision 2 which is over 12 years old.
But it borks out with other controllers, particularly Logitech ones like my G940.
The registry hack seems to have done the trick, my problem now is that CIM seems to only support 8 Axis inputs so I’ll need to extended it and it also expects the inputs to come from joystick 0.
Please Unity, hurry up with that Input Manager rewrite so that we can stop having to do all this hackery…
Hi, I’m having the same trouble here and found Andee’s reg files too! I was wondering, where do I put the files before I double click them and add them to the registry? Any help would be great, ta!
The registry hack is no longer supported, when getting RAW input from the Joystick this is what Unity gets (as mentioned above)
1 1 1 1 1 1 1 (1) -1 -0.5 0 0.5 1
The registry hack was reportedly removed because Direct Input is not cross platform… but
Given the very specific nature of each platform feature support in Unity why isn’t there a Check box in the Player Settings for Windows Standalone Builds to use DirectInput so that the calibrated input is used. This would increase the compatibility with many controllers and get rid of the need to use a DirectInput.dll plugin to bypass Unity’s Input Manager, that just makes it redundant…
I do recall a thread somewhere, where a Unity rep referred to a list of devices Unity supports under windows which might explain why some devices work and not others?
One thing I have noticed in Unity 4.0 is that when I plug the G940 in Unity reports (<RI.Hid> Device is not supported: G940 (65280, 0x0004).
Yes indeed this problem seems to be back in full power, my friend was just about to test my sim with a logitech g25 steering wheel, and he couldnt controll it, because the input was constantly on full throttle and full left. We need a really fast fix for the inputs!
This problem persists after several years: Certain (all?) high resolution devices output a raw range that gets clipped by Unity’s Input handler.
Has anyone found a workaround for higher resolution input devices in unity that does not require a Pro license? Or does Unity just not care to address it?
Same here. I use an old Microsoft Sidewinder Freestyle Pro.
After some investigation, the windows raw values ranges from -512 to 512. Negative values seems to be the problem, and it is indeed a unity problem.
The only workaround I see is using windows dll, but only can be used Pro…
I was having a very similar problem with GetRawInput but it did not behave exactly the same. Turned out the Sensitivity in the InputManager was set to 3, and that also affects the “raw” input.for some reason. Set to 1 and the problem went away.
I had same problem when I tried using Logitech G940 on Unity 4.3…
I solved it by set Sensitivity to 0.1 and Dead to 0…
With this, what unity read will be…
~0.1…0.2…(~0.3 or -0.1)…0…0.1
and then I put this code,
the ‘v’ value would be ranged from approximately -1 to 1 and the ‘v’ values on my computer is
-0.998…-0.5…( 0 )…0.5…1
but it’ll messed up if you invert the axis… so if I were to invert the axis, I invert it in the code, not by checking the invert option…
This appears to continue to be a problem. Windows USB HID devices require zero-centered report values. Unity is clipping this to 0-127 as of version 4.5.
Has anyone figured this out yet? I tried the code that AldestP posted, but all it does is return two values, 0 and 1, no -1 or anything in between. I saw that link posted above as well, but could use some help on how do I use it.
This was killing me, even when testing virtual touch joysticks.
My issue turned out to be that one of the joysticks would sometimes report an EXTREMELY small value on an axis - to the order of -5.0293e-8 or similar. This was equating to -1 when calculating the sticks position by the script (normalizing etc).
Since it was so small is basically just had to set the ‘dead zone’ values for each joystick to 1.
I suggest debugging the actual value of the joystick on each axis BEFORE normalizing or performing any calcs. Then try setting an appropriate dead zone to see if you can at least stabalise your joystick on start.
