Skip to content

libretro: read the Nunchuk's accelerometer - #484

Draft
XenuIsWatching wants to merge 2 commits into
libretro:masterfrom
XenuIsWatching:libretro-sensor-idx-nunchuck
Draft

libretro: read the Nunchuk's accelerometer#484
XenuIsWatching wants to merge 2 commits into
libretro:masterfrom
XenuIsWatching:libretro-sensor-idx-nunchuck

Conversation

@XenuIsWatching

Copy link
Copy Markdown

Adds a sub-device dimension to the sensor storage so one port can carry more than one accelerometer, and registers a SensorDevice per (port, sub-device). Sub-device 0 keeps the plain name Sensor, so existing control expressions resolve unchanged; the Nunchuk's is Sensor1. Its accelerometer binds to the Nunchuk's IMUAccelerometer group, which already existed and had never been bound.

Additive, BuildDesiredExtensionState composes that group with swing/tilt/shake and substitutes a flat device when nothing is bound, so gamepad players are unaffected. A frontend that can't offer a second sensor leaves the flag clear and nothing binds.

The first commit patches Externals/libretro-common/include/libretro.h with the sub-device encoding, mirroring libretro/RetroArch#19453; drop it when that lands upstream.

Two fixes ride along, each its own commit-sized change if you'd rather split them:

  • Seating a Nunchuk unbound the remote's own accelerometer and the MotionPlus gyro, because the sensor block sat in the else of "is there a Nunchuk" -- which skipped the analog tilt fallback too. Hoisted out; the fallback now picks the right stick when a Nunchuk is fitted, since the left is the Nunchuk's.
  • Shutdown() disabled sensors on port 0 every time and crossed accel/gyro over, so a multi-remote session left sensors running.

Also drops an #if 0 around two unused Nunchuk group pointers.

A Wii Remote with a Nunchuk is one player on one port with two
accelerometers, and the sensor interface addresses exactly one of each
kind per port. Carry a sub-device index in the high bits of the existing
id, the way RETRO_DEVICE_SUBCLASS already encodes a subclass into a
device id.

Index 0 encodes to exactly the values in use today, so nothing existing
changes, and no environment number or capability flag is needed: a
frontend that has never heard of this answers false from
set_sensor_state and 0 from get_sensor_input, which is the fallback the
header already documents.

Mirrors libretro/RetroArch#19453; drop this patch when it lands.

Header only; the reader follows.
The sensor storage gains a sub-device dimension, so one port can carry
more than one accelerometer, and a SensorDevice is registered per
(port, sub-device). Sub-device 0 keeps the plain name "Sensor", so every
control expression written before this still resolves to exactly the
device it always did; the Nunchuk's is "Sensor1". Its accelerometer
binds to the Nunchuk's own IMUAccelerometer group, which already
existed and had simply never been bound.

Binding it is additive. BuildDesiredExtensionState composes that group
with swing, tilt and shake and substitutes a device lying flat when
nothing is bound, so the L2 shake stays and a gamepad player sees no
change. A frontend that cannot offer a second sensor says so, the flag
stays clear, and nothing binds.

Two fixes come with it, both separable in review:

Seating a Nunchuk used to unbind the REMOTE's own accelerometer and the
MotionPlus gyroscope as well. The whole sensor block sat in the else of
"is there a Nunchuk", which also skipped the analog tilt fallback, so
both hands went dead the moment the second one was plugged in. The
block is hoisted out to cover every remote configuration. Its fallback
now picks the right analog stick when a Nunchuk is fitted, since the
left one is the Nunchuk's own -- which is what descWiimoteNunchuk has
been advertising all along with nothing behind it.

The remote's shake listened on L2 while every Wiimote descriptor
advertises R2 for it. So the remote's shake button did nothing at all,
and with a Nunchuk fitted L2 shook the remote and the Nunchuk together.

Also drops the #if 0 around two unused Nunchuk group pointers. The
bindings that used them were deleted rather than commented, so it read
as though the groups were compiled out when they were only unbound.
@XenuIsWatching

Copy link
Copy Markdown
Author

draft until libretro/RetroArch#19453 is approved

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

Successfully merging this pull request may close these issues.

1 participant