So maybe setting the maximum range to just a little lower than it has to be (like around 53000) wouldn't be that bad, I thought in the worst case scenario the sticks would be a little too sensitive and get to the maximum range before actually touching the sides. 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.Īlso 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 INT8_MAX instead of 80). Testing all this is a bit difficult for me because I don't have a Switch Pro controller. 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. As for Mario sometimes walking if you are not touching the controller, I think I probably know the reason for that. 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. 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. 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. 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. 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. 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. Or implement custom device handler classes for both Wii U Pro and Switch Pro to normalize the ranges there, sort of like what we did for the Wiimote Įither way, the majority of the work will be happening in OpenEmu-SDK where the input system lives. Store the range or offset values in a new key for OEControllerNintendoSwitchProController in which will then have to be read and applied somewhere in the input system in OpenEmu-SDK. 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: 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. 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). 5) Posts that can be answered by reading the sidebar/Getting Started post may be locked and/or removed.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. More details about this here! 4) Please flair your posts. 3) Posts about Pokemon games on DS will be removed. 2) Don't post PlayStation (PSX) tutorial videos unless they follow the steps on the wiki exactly. User Guideġ) Asking/showing where to find games (ROMs) and BIOS files is not allowed. With OpenEmu it is easy to add, browse, organize and with a compatible gamepad, play those favorite games (ROMs) you already own. For the first time, the "it just works" philosophy now extends to open source video game emulation on the Mac. OpenEmu is changing the world of video game emulation. This is the reddit community for OpenEmu help and discussion.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |