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

ControllerInterface/DolphinQt: Improve input detection. #7829

Merged
merged 2 commits into from Mar 13, 2019

Conversation

3 participants
@jordan-woyak
Copy link
Member

jordan-woyak commented Feb 28, 2019

As you may know, all Input states in ControllerInterface are represented by a floating point value from 0.0 to 1.0.

Axes receive two inputs (one for each direction) (e.g. X- and X+). Input backends were expected to make each return a value from 0.0 to 1.0 by clamping off negative values (so a negative X does not affect the X+ Input).

Unfortunately some silly devices like to represent inputs (usually triggers) across an entire axis so a neutral state is seen as a fully activated X- or X+.

FullAnalogSurface was introduced to solve this which maps the complete range of an axis from 0.0 to 1.0.

These workaround "full surface" inputs are added in addition to the regular ones because we have no way of knowing which representation is sensible until the user tries to use them.

Input detection logic unfortunately did poorly at determining which virtual input is desired because when a user physically moves an axis both the regular "X+" and "full surface" "X-+" are seen moving from 0.0 to 1.0 (just at slightly different rates).

What this change does is allow input backends to return negative values when opposing inputs are activated (negatives are clamped later).

Mapping logic can observe these negatives to properly detect the difference between a user moving an axis from neutral vs. a move from full negative to full positive.

The negatives are still clamped off before they reach expression parser (everything should remain the same other than mapping detection logic).

It appears by an oversight of what was expected, Android never clamped negative values. I suspect this change will fix all axes on Android from being overly sensitive because of bad math.

Note: I have purposely not "unclamped" Axis::GetState in a few backends because of some other pending cleanups.

I should mention providing the unclamped value is not required. It just allows mapping logic to detect false positives.

I hope that all makes sense. ;P

I also removed the std::async hackery in DolphinQt when mapping "All Devices".
This will make PR #7590 obsolete.

@JMC47

This comment has been minimized.

Copy link
Contributor

JMC47 commented Feb 28, 2019

This makes using controls on Android a lot easier. I can actually walk around in Super Mario 64 instead of nearly instantly going to max speed the moment I shift my thumb one pixel.

@jordan-woyak jordan-woyak force-pushed the jordan-woyak:detect-input-improve branch from c7a6536 to c389d68 Mar 4, 2019

@BhaaLseN
Copy link
Member

BhaaLseN left a comment

Code seems fine, untested tho.

@JMC47 JMC47 merged commit 011ecd9 into dolphin-emu:master Mar 13, 2019

10 checks passed

default Very basic checks passed, handed off to Buildbot.
Details
lint Build succeeded on builder lint
Details
pr-android Build succeeded on builder pr-android
Details
pr-deb-dbg-x64 Build succeeded on builder pr-deb-dbg-x64
Details
pr-deb-x64 Build succeeded on builder pr-deb-x64
Details
pr-freebsd-x64 Build succeeded on builder pr-freebsd-x64
Details
pr-osx-x64 Build succeeded on builder pr-osx-x64
Details
pr-ubu-x64 Build succeeded on builder pr-ubu-x64
Details
pr-win-dbg-x64 Build succeeded on builder pr-win-dbg-x64
Details
pr-win-x64 Build succeeded on builder pr-win-x64
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.