No true analog deadzone setting in frontend, but misleading option called "deadzone"

[rsn8887]

Description

There's no real analog deadzone setting. There is currently an option called deadzone but what that really is is an analog-to-digital conversion threshold (default at 50%). Instead of having a frontend deadzone setting, seemingly every core that uses true analog controls implements its own deadzone hard-coded, or maybe with a core-specific option sometimes? See e.g. dosbox with a hardcoded deadzone of 30% for analog joystick mouse control, making that IMO borderline unusable at least for control with a large dynamic range of pointer speeds.

Cheap or old controllers sometimes need a larger deadzone choice than new modern controllers. It is good to have a menu option for this. It could always be set with default of zero, if desired.

Expected behavior

There should be a frontend option to set the analog deadzone that does exactly that. If set to 10%, analog stick motion should be reported as zero, unless the stick is moved more than 10% away from the center, at which point it should start at 0 from there and go to the max possible value (e.g. circular re-scaled, see here: http://www.third-helix.com/2013/04/12/doing-thumbstick-dead-zones-right.html )

The current option "deadzone" should be renamed to "analog-to-digital threshold" or similar to reduce the confusion.

Actual behavior

It looks like every core that uses analog controls has its own, sometimes hard-coded analog deadzone implementation, or uses zero deadzone.

Steps to reproduce the bug

One example: load dosbox core, turn on gamepad mouse, observe no mouse motion until moving stick by 30% or more. Look for deadzone option, notice it doesn't affect this at all...

Bisect Results

AFAIK this has always been a problem, see https://github.com/libretro/RetroArch/issues/704 for example.

Version/Commit

You can find this information under Information/System Information

• RetroArch: March 19 2019 nightly

Environment information

• OS: Switch (libnx)

[markwkidd]

The current option "deadzone" should be renamed to "analog-to-digital threshold" or similar to reduce the confusion.

Given what you have said about this feature, renaming it would be an obvious improvement.

I guess I will be the first one to tag @fr500 who will inevitably be asked for an opinion

[hizzlekizzle]

Having a frontend-configurable universal deadzone would indeed be a good feature, as would a universal analog value multiplier (e.g., 50%-200%)

[ghost]

I noticed this too just yesterday. My xbone controller's right analog was drifting for some reason... I tried setting the deadzone option even to 1.0 and it still had no effect. I think the frontend should definitely have both a real deadzone and a sensitivity/multiplier option.

[orbea]

@rsn8887 Can you please test the master and see if PR https://github.com/libretro/RetroArch/pull/8527 solves this for you?

[keknyJi]

Also note that anti-deadzone will be very useful too. Basically, specifying both input and output ranges of an axis. And it should be able to be saved as a game override.

[ghost]

@shortcat359 Can the desired effect be reached by tweaking both the analog deadzone and sensitivity settings in the frontend?

[keknyJi]

@bparker06 depends on what "sensitivity" means, but anti-deadzone should be a separate setting probably. Alternatively, deadzone and saturation could be set to negative values, Edit: I'm sorry I just noticed there are such options already. I'll have to figure out what does sensitivety do.

[keknyJi]

No, these settings aren't enough. For example Driver 2 for PSX has a lot of internal inner deadzone and no outer deadzone. It's possible to get rid of the deadzone by setting sensitivity to a huge negative value but it adds a ton of outer deadzone at the same time.

[rsn8887]

@orbea my issue is fixed. I am closing this. I think “anti-deadzone” should be discussed in a new issue, because it has nothing to do with my issue here.