Dolphin has supported the recalibration shortcut (X+Y+Start) for quite a long while. So if someont's axises are terrible, you could easily
recalibrate.
Games even get the initial calibration upon boot(Most of the time).
While changing over the GCAdapter code, I was testing to make sure the reset and calibration shortcuts still worked, turns out they didn't work at
all.
Looking in to the problem, we capture the combination properly, and we wait three seconds until we actually fire that off recalibration.
The problem is for Nintendo's SDK to properly handle recalibrating, we need to send back data saying that it needs to recalibrate.
On hardware this is done as part of the 64bits of data the controller sends back to us.
On holding of the controller, bit 61 of the return value is set, which the Nintendo SDK catches, and then signals immediately afterwards a CMD_ORIGIN
command in order to recalibrate the controller.
We were outright ignoring this bit, so the library wasn't ever recalibrating. I suspect in the past the class itself used to use the calibration data
to to offset the data, but somewhere along the lines it got munged out of existence.
The Gamecube adapter does this shortcut in a bit of a unique way, instead of sending the command and having the library support it and what have you.
Once holding the shortcut for the amount of time, the adapter reports back that the controller has actually been disconnected. Then when you let go of
the combination, the adapter states that a new device has been connected to that port, and the recalibration happens because a new device is
"connected."
This fixes controller calibration for both emulated GC controllers and also the Wii Gamecube Adapter.
The Wii U Gamecube controller adapter setup has always been a bit weird. It tries to be as automatic as possible to make the user experience as easy
as possible.
The problem with this approach is that it brings a large disconnect in the user experience because you have the Gamecube controller setup with regular
gamepads and then for some reason below that you have a "direct connect" option which will cause the Gamecube Adapter to overwrite the regular inputs
if something was connected.
While this works and allows the user to only click one checkbox to get the device working, it breaks the user's experience because they don't really
know what "direct connect" means and won't look it up to figure out what it is. Just expecting the device to work (At least one occurence of this in
the IRC channel in the last week).
This way around also had the terrible nature of making the code more filthy than it needed to be. The GCAdapter namespace was parasitic and hooked in
to the regular GC Controller SI class to overwrite the data that it was getting from the default configuration.
Now instead we have a specific SIDevice class for the Wii U Gamecube adapter. This class is fairly simple and is a child of the regular SI Gamecube
Pad device and only reimplements what it needs to.
This also gives the ability to configure controllers individually, which allows the user to configure rumble individually per pad input.
Overall the code is cleaner, and it fits more in line with how the rest of Dolphin works.
Lets the user set the following in intervals of 10 between 10 and 100;
- Stick/Radius (default 100,000000)
- Triggers/Threshold (default 90,000000)
- Tilt/Modifier/Range (default 50,000000) + mapped Tilt/Modifier button
to the configurations for wiimotes & nunchuks
By default unique_ptr will call delete on the given type if an array
qualifier isn't present, not delete[]. It's important to explicitly
specify an array is being handled.
This fixes the crashes occuring at startup with a non-empty shader cache.
Because LinearDiskCache reads/writes to the storage of ShaderUid, ShaderUid must be trivially copyable.
Additionally, adds a static assert to LinearDiskCache to ensure this doesn't happen in the future.
The initialization of ShaderUid data has been moved to the code generation functions, so the above condition holds true.
Ryan Houdek