libretro: fix the Wiimote gyroscope and make MotionPlus a device type - #472
Open
XenuIsWatching wants to merge 1 commit into
Open
libretro: fix the Wiimote gyroscope and make MotionPlus a device type#472XenuIsWatching wants to merge 1 commit into
XenuIsWatching wants to merge 1 commit into
Conversation
Three defects kept the gyroscope from ever working The sign was destroyed before it arrived. SensorDevice published each gyro axis as one signed input, but ControlExpression clamps a control to >= 0 (ExpressionParser.cpp, "We clamp off the negative values here"), so half the travel was discarded. With Pitch Up bound to GyroX and Pitch Down to GyroX*-1, IMUGyroscope::GetRawState() returned controls[1] minus controls[0], which works out to -2*max(0, GyroX): half the signal gone, the rest doubled and inverted. Each axis is now a one-sided pair (GyroX+/GyroX- and so on), which is what the accelerometer beside it already did and what every upstream gyro backend does for this exact reason. The binding was also nested inside the accelerometer branch, so a frontend offering a gyroscope but no accelerometer bound neither. It is now a sibling. Shutdown() crossed the two sensors over, disabling the gyroscope when the accelerometer had been enabled and vice versa, and addressed port 0 every time regardless of which port it was tearing down. MotionPlus becomes per-port hardware rather than a core option, because one player having the dongle fitted while another does not is the ordinary case, and Dolphin already stores the setting per Wiimote. It doubles the device list rather than adding one entry: the dongle passes the port through, so every extension still plugs in, into the dongle instead of into the remote. wiimote_base_device() collapses the new ids back to their twins so every existing branch stays written against the five it already knew.
Author
|
A video showing it working if interested |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three defects kept the gyroscope from ever working
The sign was destroyed before it arrived. SensorDevice published each
gyro axis as one signed input, but ControlExpression clamps a control
to >= 0 (ExpressionParser.cpp, "We clamp off the negative values here"), so
half the travel was discarded. With Pitch Up bound to GyroX and Pitch
Down to GyroX*-1, IMUGyroscope::GetRawState() returned controls[1] minus
controls[0], which works out to -2*max(0, GyroX): half the signal gone,
the rest doubled and inverted. Each axis is now a one-sided pair
(GyroX+/GyroX- and so on), which is what the accelerometer beside it
already did and what every upstream gyro backend does for this exact
reason.
The binding was also nested inside the accelerometer branch, so a
frontend offering a gyroscope but no accelerometer bound neither. It is
now a sibling.
Shutdown() crossed the two sensors over, disabling the gyroscope when the
accelerometer had been enabled and vice versa, and addressed port 0 every
time regardless of which port it was tearing down.
MotionPlus becomes per-port hardware rather than a core option, because
one player having the dongle fitted while another does not is the
ordinary case, and Dolphin already stores the setting per Wiimote. It
doubles the device list rather than adding one entry: the dongle passes
the port through, so every extension still plugs in, into the dongle
instead of into the remote. wiimote_base_device() collapses the new ids
back to their twins so every existing branch stays written against the
five it already knew.