Will manually controlling both an accelerometer and a gyroscope at the
same time be reasonable to do? No idea. Was this easy to implement
thanks to the input override system? Yes.
Fixes https://bugs.dolphin-emu.org/issues/12443.
This gets rid of a blocking operation, improving performance and fixing
https://bugs.dolphin-emu.org/issues/12893.
This also makes us no longer directly access the state of certain UI
elements from the CPU thread, which probably wasn't thread-safe but
doesn't seem to have caused any observable issues so far.
Up until now, there have been two settings on Android that stored the
selected Wii Remote extension: the normal one that's also used on PC,
and a SharedPreferences one that's used by the overlay controls to
determine what controls to show. It is possible for these two to end up
out of sync, and my input changes have made that more likely to happen.
To fix this, let's rework how the overlay controller setting works.
We don't want it to encode the currently selected Wii Remote extension.
However, we can't simply get rid of the setting, because for some Wii
games we need the ability to switch between a GameCube controller and a
Wii Remote. What this commit does is give the user the option to select
any of the 4 GameCube controllers and any of the 4 Wii Remotes. (Before,
controllers 2-4 weren't available in the overlay.) Could be useful for
things like the Psycho Mantis fight in Metal Gear Solid. I'm also
switching from SharedPreferences to Dolphin.ini while I'm at it.
It's missing a lot of features from the PC version for now, like
buttons for inserting functions and the ability to see what the
expression evaluates to. I mostly just wanted to get something in
place so you can set up rumble.
Co-authored-by: Charles Lombardo <clombardo169@gmail.com>
This is a small regression from KillRenderer, which caused duplicated
frames to be counted on the FPS counter when the "Skip Presenting
Duplicated Frames" option was disabled.
This way, Android (which will show groups in the order they're defined)
will show groups in a more logical order similar to DolphinQt.
The main thing that was annoying me was how early Rumble was for
Wii Remotes. Some of the other changes I'm making in this commit,
like the order of Shake/Tilt/Swing, are more arbitrary and were
made for consistency with DolphinQt. But there are also places
where I didn't go all the way with matching DolphinQt. Most notably,
DolphinQt puts sticks before buttons, but I don't see any reason
to do that for Android.
Unlike PCs, Android doesn't really have any input method (not counting
touch) that can reasonably be expected to exist on most devices.
Because of this, I don't think shipping with a default mapping for the
buttons and sticks of GameCube controllers and Wii Remotes makes sense.
I would however like to ship default mappings for a few things:
1. Mapping the Wii Remote's accelerometer and gyroscope to the device's
accelerometer and gyroscope. This functionality is useful mainly
for people who use the touchscreen, but can also be useful when
using a clip-on controller. The disadvantage of having this mapped
by default is that games disable pointer input if the accelerometer
reports that the Wii Remote is pointed at the ceiling.
2. Mapping GC keyboards for use with a physical keyboard, like on PC.
After all, there's no other way of mapping them that makes sense.
3. Mapping rumble to the device's vibrator.
Aside from the GC keyboards, this approach is effectively the same as
what we were doing before the input overhaul.
This is a battery-saving measure. Whether a sensor should be suspended
is determined in the same way as whether key events and motion events
should be handled by the OS rather than consumed by Dolphin.
Admiral H. Curtiss