This adds an option to enable relative input for the Wiimote IR
as described in issue 9014.
Enabling it will result in the pointer not going back to the centre
and the inputs will control the direction, not the absolute position.
Also adds a Dead Zone setting which is really needed when relative
input is enabled to prevent the cursor from slowly drifting on
most controllers. (Note: the Deadzone setting has no effect when
relative input is disabled)
This adds RemoveDevice() to ControllerInterface, fixes ExpressionParser
and some other code to support device removals without crashing,
and adds an IsValid() method to Device, to prepare for hotplugging.
This fixes warnings in:
- Source/Core/InputCommon/ControllerEmu.h: avoid shadowing other
variables (my fault)
- Source/Core/Core/IPC_HLE/WII_IPC_HLE.h: made
SDIO_EventNotify_CPUThread static as it's not used anywhere else
The Setting class was used for both numeric values and booleans, and
other parts of the code had hacks to make it work with booleans.
By splitting Setting into NumericSetting and BooleanSetting, it is
clear which settings are numeric, and which are boolean, so there is
no need to guess by checking the default values or anything like that.
Also, booleans are stored as booleans in config files, instead of 1.0.
Main Stick is changed to Control Stick and C-Stick is changed to C Stick.
A new ui_name variable is added to ControlGroup so that the UI strings
in DolphinWX can be updated without breaking backwards compatibility
with config INIs and other things that use names as IDs.
Added the option to handle whether the user wants to iterate through the
assignment of button mappings or assign them one at a time.
fixed formatting issues and code style.
I excluded this option from the config file. This stopped the check box value and the boolean from becoming offset. Since the option should always start as false.
This still causes an issue with the Wiimote input, since the class variable that keeps the state will be wiped, but the check box value will stay the same after closing/reopening without closing the entire Wiimote configuration. I am looking for a way to resolve this.
I also reduced wait time to 2.5 seconds vs. the 5 seconds previously. Seemed to be a little long.
These changes apparently did not go through.
This should fix the Wiimote issue.
This will allow us to simplify the checks for background input and push
them further down into the architecture, into the ControllerEmu layer.
The new setting isn't actually used yet, though.
Do the scaling in the code that interprets the results.
This also removes the templatization of things and changes the interface
to always take a double.
This does add a bit more code to the users of GetState, especially when
having to deal with focus management, but this will be cleaned up very
soon, as focus and focus-related options will be centralized inside the
input platforms themselves, rather than spread out across all the input
plugins.
Most users will have something in the radius or deadzone fields, so
don't bother filtering out 'extra' work. This also lets us clean up
the modifier implementation.
It was only used for really old joypads which we really don't want to
support. If users have these joypads, they should look into using
something at the OS level, as games shouldn't need to have this
transformation; it should be done by the OS and driver.
It substantially complicates the code and doesn't really provide any
functionality. According to the forums, the Android app is out of date
and has been broken for quite a while.
If we want to add this back, I'd write an app that speaks a more native
Wiimote protocol, and we can hook that up to the backend quite easily.
It could even be over our NetPlay protocol!
Léo Lam