Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input Configuration is Too Sensitive #10

Open
ghost opened this issue Sep 5, 2014 · 9 comments
Open

Input Configuration is Too Sensitive #10

ghost opened this issue Sep 5, 2014 · 9 comments

Comments

@ghost
Copy link

ghost commented Sep 5, 2014

Manual import from http://sourceforge.net/p/m64py/tickets/13/

@ssokolow wrote:

When trying to configure my joysticks, I found the input configuration far too sensitive and, in the end, found it MUCH easier to just stumble around enough to get a feel for the keywords written to the config file and then manually edit the file.
Rather than relying on the dead zone configuration (nonexistant under evdev, either broken or cripplingly fragile under joydev), I think it'd make much more sense for the input configurator to only accept an axis measurement as intended if it exceeds 50% of the axis's range in that direction.
That would also make it MUCH easier to ensure that, when I press a stick horizontally, it won't be mis-detected as vertical movement (or vice-versa) due to a bit of initial imprecision when pushing the stick.

@ghost
Copy link
Author

ghost commented Sep 5, 2014

@gen2brain wrote:

Hi,
Can you try to change values in joystick.py, currently it have this:
SDL_JOYSTICK_DEFAULT_EVENT_TIMEOUT = 25
SDL_JOYSTICK_DEFAULT_AUTOREPEAT_DELAY = 250
If that helps, I can move that to settings instead of hard coding it.
For your suggestion, you should send that request to mupen64plus.
Thanks

@ghost
Copy link
Author

ghost commented Sep 5, 2014

@ssokolow wrote:

Hi, as you may have guessed from my slow responses, I'm a but behind on a few more urgent things at the moment but I'll leave this tab open as a reminder to try that as soon as I can spare a moment and I'll let you know what the results are.
As for "my suggestion", which one?

@ghost
Copy link
Author

ghost commented Sep 5, 2014

Anonymous wrote:

Excuse me, but I don't see a joystick.py file in the m64py installation directory. :/

@ghost ghost changed the title http://sourceforge.net/p/m64py/tickets/13/ nput Configuration is Too Sensitive Sep 5, 2014
@ghost ghost changed the title nput Configuration is Too Sensitive Input Configuration is Too Sensitive Sep 5, 2014
@ghost
Copy link
Author

ghost commented Oct 12, 2014

It seems that some Joysticks like the the Dualshock controllers have 27 axis. And some axis jump all over the place when (from -32768 to 0 for example) when the actual axis is moved. Not sure what m64py can do here.

Has anyone an idea? One thing would be to use the linux event system through SDL2 and drop SDL support. The input plugin settings would also have to be changed from SDL_JoystickUpdate to correct event handling via SDL_PollEvent. SDL1.2 just isn't able to handle modern joysticks anymore. Even their own testtool testjoystick just prints garbage for these devices when using SDL1.2. SDL2 works quite fine.

I have now implemented a better version of the detection (at least here under Linux with Dualshock controllers) for SDL2. But it will only use the new version when you start it in SDL2 mode. You also have to use mupen64plus compiled against SDL2. It can be found as pull request #28

$ m64py --sdl2

@Papermanzero
Copy link

In general a manual adaptation of the mupen64plus configuration file can help to find the right sensitivity.
I had a similar issue with the 360 Pad. However I adjusted the deadzone in the cfg file and now it is working without problems.
Look: https://code.google.com/p/mupen64plus/wiki/ControllerSetup

@ssokolow
Copy link

ssokolow commented Feb 7, 2016

I finally managed to find time to poke at this again with both the 0.2.3 .deb download and 010b279 from git.

Whether or not I use --sdl2, whether or not I increase the dead zone fields in the dialog to exceed what jstest-gtk says is necessary,the input configurator is far too prone to latching onto some value like "axis 0-" on my XBox 360 pad rather than the whatever I'm actually pressing.

(I'm trying to reconfigure my XBox 360 pad because the autodetection in Mupen64Plus 2.0 gets the Z button reversed so I have to hold down the left trigger and release it to press the Z button.)

I can't try the ControllerSetup page because Google's Code Archive is erroring out and I'm not sure whether anything in the first reply to my initial post is still relevant.

@ssokolow
Copy link

ssokolow commented Feb 7, 2016

Ok, I managed to find the new location of the ControllerSetup page. Looks like I found the problem in the autoconfiguration for 2.0 at least. (It's applying the "both triggers are one axis" interpretation from Windows under Linux.)

@FixerUpper16
Copy link

I recognize this is a very old topic, but I was having the same problem of dealing with super high sensitivity of the analog stick on an XBOX gamepad on MUPEN64 Py on Windows that was making it impossible to play the game, and I solved it for anyone who is interested! Go to your Mupen64Py directory and look for "InputAutoCfg.ini." Open it, and find in the brackets whatever your controller pops up as on the main UI when you are configuring the controls (for me, it was Xinput Controller #). Go to the deadzone values and replace the values with "10000" for each axis (or higher I suppose if needed). Recognize that on the actual controller configuration screen itself, changing these values doesn't do anything to the sensitivity and the sticks will be crazy sensitive, but when you are playing the actual game, the sensitivity is at a playable configuration :)

@Unounited
Copy link

Unounited commented Jul 11, 2021

For me the best sensitivity's worked great. On the x axes is 4092, and the y axes is 32768.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants