This is the only way to get Wiimotes working under Android now.
This, just like the Wii U Gamecube Controller Adapter, completely goes around Android's limitations and talks with the device directly through USBManager.
Couple notes.
Continuous scanning must be enabled otherwise the Wiimotes won't be seen.
The UI doesn't expose support for this yet. One must change the Wiimote source and continuous scanning settings manually.
Testing up to two wiimotes in Taiko No Tatsujin, no reason to believe all four won't work.
if the configured local pad is none, it will make dolphin behave
incorrectly (due to the game expecting inputs from the device while it
doesn’t exist).
Remote devices would always enter an error path and get disconnected
from the gamecube, breaking netplay in the process.
Culprit is still InGamePadToLocalPad
if it was used in netplay, it would read memory out of bounds
(due to the mapping method returning 4 if the device was remote) which
was 0 more often than not, causing the device in this position to be a konga.
(which may or not be the gcadapter due to the swap between local and
ingame controllers)
Introduced in 6e13496d8, pads would get assigned to their netplay
position, which breaks assumptions. With this behavior, the SI devices
should be mapped properly.
if a pad or wiimote number was outside bounds (e.g. 42353543232),
it would still have been read from the array, which could lead to
inappropriate consequences, like a segfault.
This is only queried, there's no need to expose it for writing.
Even if it was written to, a data member shouldn't be part of
your public API unless its part of a dumb object or trivial struct.
CBoot::BootUp() did call CoreTiming::Advance which itself blocks on the GPU,
but the GPU thread wasn't started already. This commit moves the SyncGPU
initialization into the Fifo.cpp file and call it after BootUp().
Pierre Bourdon
Lioncash
Matt Mastracci
Ryan Houdek
Tillmann Karras
degasus
Aestek
mathieui
Pal Lockheart