Controls remapping not working when Switch Pro Controller is connected #3142
Comments
|
I read your link and disabled all potential sources of interference but the problem persists. I don't encounter it with OpenEmu 2.0.4. |
|
This isn't happening for other users that have the Switch controller, so it has to be something listed in the guide. Also, you should update to 2.0.5. You will first want to clear out your bindings file if you already have pre-existing mappings for the Switch controller, though. |
This is happening to me as well. The predefined controls seem good enough though… the worst part is that the left analog doesn't seem sensible enough though, I push it all the way and Mario (on Super Mario 64) walks really slowly, as if I were doing it very lightly. :/ |
|
I just found #3102, that's exactly what I'm experiencing, sorry. As for the original issue, I deleted OpenEmu and its Application Support directory, restarted the computer and installed it all over again. When I opened it the problem was still there. Then I opened Super Mario 64 and it crashed. I opened it again and now the mapping works just like it should. 🤷♂️ |
|
Also I'm sorry to bring this up here, but the #3102 issue is locked… couldn't we just allow the users to Edit: or let the user choose a value to "amplify" the axis value, getting it closer to 1.0 before multiplying by 80… anyway, you get what I mean. Now that I'm thinking about it, couldn't we just check if the controller is a nintendo controller on |
|
@dbmrq Both of the Nintendo analog gamepads that we support (Wii U Pro and Switch Pro) have abnormal values for their ranges, because they aren't made for PC use in the first place. We appear to not be getting the full range and I've even read that the plastic around the sticks blocks part of it (#1748). Worse yet, the analog ranges can be different from controller-to-controller and even vary stick-to-stick on the same controller! So the long term solution is some kind of built-in calibration method for these gamepads. That isn't happening soon. However, if we can find an optimal value to use for normalizing the range we can implement an acceptable short-term fix in two possible ways:
Either way, the majority of the work will be happening in OpenEmu-SDK where the input system lives. I do not have a Switch Pro controller to test with, so if you are up to this task then by all means go for it. |
|
@clobber Alright, my objective C is not that great and this seems a little out of my league, but I'll try to figure it out little by little. Thank you for your help! |
|
@dbmrq Please try the following test build with your Switch Pro controller:
This will help me determine the real maximum range of this device and then I can probably fix it. |
|
@clobber As soon as I clear the console it gets populated again with seemingly random values, even if I'm not touching the controller. Here are the results anyway: https://gist.github.com/dbmrq/09bd1c763f92d220fdb36830088d4ee7 There are a few spots when the values go from 5 digits to 4, like line 666 and below, line 975 and below and so on. I imagine those are the times when I was rotating the sticks, but I'm not sure. Thanks again. :) |
|
Looking a little closer I imagine the values from around 30000 to 37000 are a sort of deadzone, when the stick is actually still. If I hold it to the left I get values around 10000 intermittently: If I hold it to the right I get values around 52000 intermittently: If I hold it up I get values around 9600: And if I hold it down, around 59000: This is just holding the left stick in one direction at a time. The gist has the full results with me making full circles. Let me know if there's anything else I can do. |
|
Thanks. No need to evaluate all the numbers, I'm just going to pull out the maximum and the minimum from you doing full circles. I also need one for the right stick too please. Edit: and yes it is going to spam values, because the device is constantly sending axis data even when still. |
|
Okay so from your data we have: left stick: right stick: Quite the difference between the sticks. As you can see the Switch Pro does not give us its full range - the minimum never reaches anywhere near 0 and the max never reaches near 65535. This is why Mario walks and never runs :P Would you be willing to do one more test like this? I want to be absolutely sure these are the minimum and maximum values for both sticks. If you do it again, this time rotate the sticks slowly and make sure you are doing full, complete circles so that you are pushing the analog sticks as far as they can go in all directions, hitting the plastic edge of the ring it sits in. Do maybe 5 rotations. |
|
Thanks! Wow these differed quite a bit from the first results too. left stick: right stick: All this output spam in Console is annoying and hard to parse, plus we may be missing some values. In a few hours, I'm going to clean up the logging so that it will only output the min/max value after you are done rotating your sticks and press a button on the gamepad. I'll let you know when it's ready and upload a new build so you can test again. |
|
Ok then, thanks. :) |
|
@dbmrq Okay I've put together a much more accurate and streamlined test which doesn't require you to copy and paste massive lines or repeat steps. Here's all you have to do:
|
|
Alright, I gave it a few tries: Often the results showed up in the console before I pressed any buttons though, I was just moving the right stick, paying attention not to press anything by accident, and those lines would appear. |
|
Thanks! That definitely looks better from the results we saw before. I'm seeing much lower minimum and higher maximum range values reached.
Yep, any button you press including the analog "stick" buttons and the shoulders/triggers will make that output appear because they are all actual HID buttons. Sorry, I should have mentioned that. When I make a build for general testing for people in issue #3102 I will fix it so only pressing "Button A" on the gamepad triggers the logging. |
|
Actually, I just fixed that now in case you would like to verify that only pressing Button A will log the axis output. Here's the build: [removed] |
|
Whoops, just realized that build won't pull data for the right-stick axis. Here is a corrected build: https://transfer.sh/116OzR/OpenEmu-inputtest4.zip Just want to see if only pressing "A" logs the data. |
|
Yep, now the results only show up if I press A. :) |
|
Great. Now for hopefully our last test, see if this build fixes movement in games like Mario 64 and Zelda: https://transfer.sh/pmHQb/OpenEmu-n64fix.zip |
|
It's definitely playable and a lot better than before, but when Mario moves backwards or to the left he moves slightly faster than forward or to the right. I think moving right is the slowest now. It's not that bad, but still noticeable. |
|
I don't know if this is relevant or helpful, but Dolphin has these images showing the position of the sticks and you can see that, when resting in their natural position, they show up a little off-center:
The left stick seems to be a little to bottom right, and the right stick seems to be a lot closer to the top. |
Hrm okay. Sounds like I may need to lower the maximum range a bit more then. I set it to 60000 because it seemed you were able to reach that, but perhaps I should try 59000. Either that, or we need to go more granular and do min/max ranges for each individual axis.
Yep, I experience that too with my DualShock 4. Unfortunately these analog gamepads aren't the best of quality despite their premium prices. |
|
Since the normal position is already off center I guess my controller is reaching 6000 when going left, but not when going right (in the Dolphin image there's less space for the stick to travel form the little dot to the right edge than from the dot to the left edge). I'm afraid 59000 will still not cut it, since, like I mentioned here, holding the stick left gives me values around 59000, but holding it right only goes as far as about 52000. Maybe setting the maximum range to 52000 wouldn't be that bad though? Using version 2.5.2 of the Mupen64Plus core works reasonably well for me, and I assume it's using values way above the real input for all sides. With 2.5.2 the problem is the opposite, the sticks are too sensitive and sometimes Mario will start walking slowly even if I'm not touching the controller, but that's still better than him not going fast enough. |
We can't rely on that data. Both analog sticks were spamming console at once and you can be sure that outputs were getting dropped, so we weren't getting the full or accurate story there. If we really want to see the per-axis ranges then I need to modify my code a bit to account for that, which I may do later.
You confused me there. But I think you are saying the older version of Mupen64Plus works for Mario 64, but I can assure you that input will be broken in other games because we were not passing correct values based on the N64 gamepad range limit. As for Mario sometimes walking if you are not touching the controller, I think I probably know the reason for that. So far the changes I made were to just test a specific range and I didn't do any bounds checking to limit and scale the actual analog value currently being sent. I still need to adjust that. Testing all this is a bit difficult for me because I don't have a Switch Pro controller. |
|
Yes, I imagine that data isn't very reliable, but I thought it could still be suggestive, since the difference between right and left matches the Dolphin image and my tests with Mario 64. Also I know the older version of Mupen64Plus can cause other problems, but I thought they'd be related to the values being interpreted as way higher than they actually are (since the value is multiplied by Anyway, this was already a big improvement, and you don't have to look into it right now, of course, I just wanted to help however I could. If you need me to perform any other tests I'll be glad to help out. |
|
Okay, so this is another test build that will log the ranges for each individual axis. Maybe give us a better idea if there is a serious difference in ranges (hope not!): https://transfer.sh/HUOQu/OpenEmu-inputtest5.zip |
|
Here you go, two different attempts: |
e: for a more complete picture, here are the approximate zero positions of the axes (sampled without moving the sticks) |
|
Wow. Okay I was worried that ranges would vary from device to device, but not that bad. I like the look of @torque's numbers, as they don't differ so much and it makes it easy to hack in some default ranges. But @dbmrq, your y-axis numbers are way off! If it were my device, I'd probably return it to the store for another one as that looks somewhat defective (please don't take that the wrong way, just an honest opinion based on observing the output). Although maybe it's not so much of a problem when using it on the Switch with its calibration option. But if you are using it primarily for PC gameplay, I'd return it for a new one either way. Also, just so we are clear, are you running any kind of input modifier software in the background that could be affecting the values? Just wanted to check. Anyway @dbmrq, based on your new output I put together a new test build for N64 that maybe improves Mario's movement. Let me know. https://transfer.sh/ltZ7z/OpenEmu-n64fix2.zip (Note: This is only modified for the left analog stick x/y-axes at the moment). |
|
Wow, that really is a big difference. Unfortunately I don't think I can return it, but your latest build works alright. Sometimes Mario moves even if I'm not touching the controller, but I can live with that. I hope it works fine with the Switch, I didn't get mine yet actually, I just got the controller to warm up until then. It works pretty much perfectly with Dolphin, so I'll try not to lose hope. Thank you for your help! |
|
Wow! I started googling general problems with the Pro Controller's calibration and read something about issues with the bluetooth connection, interferences and so on. So I tried the test with the controller wired in via USB, the results were even crazier! For the first two attempts that "right analog X axis min" was 16… then I disconnected the controller, connected it again and gave it a third try: Also the controls seem to be working perfectly well, even the problem with Mario moving all by himself is gone. At least that makes me think these issues are not about the actual hardware of the controller, but maybe something related to the driver, I don't know. 🤷♂️ |
|
Very interesting. I've seen issues resolved before with removing the device in Bluetooth preferences and re-pairing it. As far as I know, the Switch Pro will not operate (send/receive) inputs while plugged in to USB (it's strictly for charging), so you may be seeing some kind of garbage HID output being reported from IOKit.
There is no driver unless you have manually installed something or are using third party input modifier software. The gamepad should be working as a standard Bluetooth HID-compliant device. So which build are you using to play Mario with, and are you using it via Bluetooth? |
|
Oh, ok, when I plug the controller it automatically connects via Bluetooth again. So I must have been using it via Bluetooth without realizing it. If I plug it in and then disconnect it on the Bluetooth pref pane, OpenEmu crashes (but apparently there's no reason to do that; I just thought I'd let you know). On my previous tests I disconnected the controller and connected it back again many times, that didn't seem to change the results that much. After plugging it in the difference was drastic, as you could see. I never actually removed it from the Bluetooth pref pane, just disconnected and connected back again. I left it plugged in overnight and now I unplugged it and gave it another try, the results are still along those lines: I tried playing Mario with the last three builds you uploaded here (https://transfer.sh/HUOQu/OpenEmu-inputtest5.zip, https://transfer.sh/ltZ7z/OpenEmu-n64fix2.zip and https://transfer.sh/pmHQb/OpenEmu-n64fix.zip), now everything seems to be working perfectly well on all of them. :) |
|
Just to clarify in case I need to recommend those steps to anyone else that sees weird range values, you just plugged in the controller and unplugged it and that resolved the range, or were there steps with you connecting/disconnecting with Bluetooth too? Could you list it out step by step like 1), 2), ... ? That would make it easier for someone to follow. Also, was that the first time you plugged in the device to a PC? How did you normally charge it? So Mario moves fine in inputtest5 build too? There are no changes to the code besides the logging, so if it works there that would mean it also works fine on vanilla OpenEmu 2.0.5. I'm curious so let me know. |
|
Oh, I'm sorry, I had multiple versions of the Mupen64Plus core and I mixed them up, I was using 2.5.2. Now I tried 2.5.3:
What I did, as far as I recall, was:
The stick position reported in Dolphin also changed, in case that matters:
After writing this I tried the steps above one more time. When I plugged the controller in it would still show up as disconnected and trying to play Mario would make OpenEmu crash. I unplugged it and plugged it in again, and then it connected via Bluetooth (without me doing anything, I just plugged it in). I tried playing Mario again and the experience was the same as described above. I ran the tests again and the results changed a bit, especially for the "left analog Y axis min": And the position reported on Dolphin was different yet again:
Edit: I forgot to answer about the charging. I bought the controller about 10 days ago, charged it by connecting it to the computer and used it for a couple of hours every day. The battery was still fine, so I didn't charge it again until yesterday, when I plugged it in just to see if it had any influence on the test's results. |
|
Hey does that problem is solved now ? I tried to plug the switch controler but the buttons doesn't seem mapped so well (tried with Neo Geo games) |
|
I'm not sure if there was an update recently but diagonals are gone entirely for my left analog stick |
When the Switch Pro Controller is connected, I'm unable to remap controls for it or for any other connected controllers. OpenEmu 2.0.5, macOS 10.12.3.
The text was updated successfully, but these errors were encountered: