Deadzone definition for sticks

[OperationNT414C]

Add the possibility to define deadzone for left and right sticks neutral position in "missioncontrol.ini" file (when built-in HOS calibration tool is not efficient enough)
Only tested with DS4 controller (but should work with any controller)

[Banz99]

Me and @ndeadly have been discussing this for months (you can see an implementation of these deadzones already in my (now outdated) pull request), the idea is to not create any more processing of inputs in the sysmodule than necessary and to reuse as many features already available as possible. Should also be noted that a global deadzone approach isn't very ideal considering the multiple controllers that could be attached (that's the reason for the existance of the per controller profiles and virtual SPIs). As for the approach that might eventually be taken, what I've implemented in #376 allows us to specify an inner and outer deadzone directly in the virtual spi (https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering/blob/master/spi_flash_notes.md#stick-parameters-1--2)

[OperationNT414C]

Indeed, I developped this feature from 0.6.0 version where stick calibration results were not applied.
With 0.6.1 version, those changes could be considered as "redundant".
However, with what you proposed, is it possible to manually configure the deadzone parameters? Because, with the HOS built-in calibration tool and the fact that a stick drift can be "slightly random", I am not sure it always gives appropriate results.

[Banz99]

Indeed, I developped this feature from 0.6.0 version where stick calibration results were not applied. With 0.6.1 version, those changes could be considered as "redundant". However, with what you proposed, is it possible to manually configure the deadzone parameters? Because, with the HOS built-in calibration tool and the fact that a stick drift can be "slightly random", I am not sure it always gives appropriate results.

It's possible as in editing the virtual spi directly once created (which will probably be the same approach that will be used for overriding colors). If you have an hex editor, you can change the two bytes written at 0x6089 of the virtual spi flash when the controller is disconnected (that right now should be 0x00 (3)1, it's a weird packed format, basically the value is Little Endian and fused toghether with the subsequent bytes, the actual value is 1 00 and right now can go up to 4 d3, which is roughly 60% of deadzone (more than enough for basically any working controller out there). Also as a note, Nintendo's implementations of deadzones isn't a true deadzone in the standard way of thinking it. Once it cuts off values near the center, it rescales the remaining values back to the full range.

[OperationNT414C]

Thank you for the clarification, even if it's not a very user friendly edition. :-)

Once it cuts off values near the center, it rescales the remaining values back to the full range.

In those commits, I also do a rescaling of the remaining values (check "zone_scale_factor" usage in "SwitchAnalogStick::ForceDeadzone"). However, unlike "sys-con" plugin, each axis stays independant: I do not compute the distance with the center in order to have a disk deadzone (it is a square deadzone).

[OperationNT414C]

Some additional options to support outer deadzones (in cases where HOS built-in calibration tool doesn't seem to enough)

However, those changes are still not "controller specific" and they imply additional checks in "EmulatedSwitchController::HandleIncomingReport" where performances could be critical.