JoyX/JoyY(0) locked to nonzero values
Monkey Forums/Monkey Bug Reports/JoyX/JoyY(0) locked to nonzero values
| ||
| So, I just recently built a new computer running Windows 8.1 (x64). I noticed that my code for keybind detection was absolutely broken on the new machine (glfw target), keys were stuck, and couldn't figure out why for the life of me. So, I ran the joytest banana, and noticed something wrong with the left stick axes: JoyX(0): -1.00 JoyY(0): 1.00 Now, UNLIKE my old machine, Joy_LSB / RSB actually seems to report the triggers as digital buttons, instead of mapping both triggers to JoyZ(0). However on glfw, the sticks completely refuse to work at all. This is a joypad which "emulates" sticks by means of a switch on the back -- however it worked fine on my last system (admittedly running an older build of Monkey, 78f I believe), and other games don't seem to have this axis lock / non-responsive problem. My biggest issue with this is that if it happens to me, it can happen to someone else, and having the axes locked to nonzero values screws up keybind detection. I'd have to "check" for calibration at the beginning of my program, and (I think?) I shouldn't have to do this. Any ideas? Has any similar bugs been reported? |
| ||
| What happens if you try the joystick out on the game controller settings test page? You can get to this page via control panel->devices and printers->right click on gamepad->game controller settings->properties, and it should let you test out the joystick range, buttons etc. Are joyx/joyy stuffed here too? |
| ||
| Tested the panel on Windows 8 and it seems that it's not displaying analog stick data at all. There are no calibration settings for this, either. I'm not sure I remember how joysticks were handled in glfw2 (Edit: both glfw2 and glfw3.0 seem to use winmm.dll), but I do know that analog sticks worked in at least one other game on this system (Super Meat Boy, which I believe uses xinput). But yeah, it appears that in the control panel, no analog options are given there on this machine, and I can't even calibrate. Once again I'd be fine with this if it weren't for the fact that the axis data's reporting nonzero values on the left stick. I wonder if there's any joystick apps or examples I can test with to provide better information. |
| ||
| I just wanted to give an update on this thread and note that someone compiled joyTest on XNA target for me (v79e) and my stick axises work fine there. So it's probably either a problem on the glfw target or some weird interaction with how the glfw devs implemented winmm stuff and my driver for windows 8.1 (which is an x360 wired compatible). Short of disabling the joystick when this problem is detected, is there any clue as to solve this? To narrow down the likely problems, I tested glfw builds on 78b, 79e, and 80b. All of these targets reproduced the issue. I will continue to test other targets and versions. |
| ||
| Another update. Waiting back from Samah to help me figure out how to get glfw3 working, in the meantime I booted up my work PC which is running Windows 7 32-bit on it to run joytest under 80c. It works correctly. To illustrate from before, except for on windows 8.1, it seems the standard x360 driver reports this device as supporting analog sticks, and indeed it can emulate them using a switch on the rear of the device. Once again, xinput2-based games can also access the emulated sticks, but I don't have enough games on this new machine to test "older" methods of accessing the controller. All I know is that the sticks don't work, and the left one is "stuck" in a position that screws up bind detection in my code and will likely require a switch to disable stick detection in the case of this particular situation. Here's what the dialogue looks like on windows 7:  And now, 8.1:  Remember, this is the default driver Microsoft provides, and there really aren't a whole lot of options end-users would be able to mess around with driver-wise with these controllers (Mine's a MadKatz fightpad, as stated before, an x360 compatible. I can provide pictures if necessary). I'm wondering what is causing this to beef up, but if I can find a workaround that doesn't involve you shooting in the dark, Mark, I'll update here. In the meantime, hopefully this gives some clue as to wtf is going on here. |
   |