Handle deadzones "correctly"

[alice-i-cecile]

Problem

Gamepad axis deadzone handling is a mess. Our current solution is an extremely naive, unscaled axial approach.

Users can control the dead zone size, but not the behavior.

Proposed Solution

1. Use an enum to allow configuration between raw (no deadzone), axial and radial deadzones.
2. Use a second enum to allow the falloff curve to be configured: raw, linear, or custom. Other than for the raw passthrough feedback curve, the values here should always be in [0, 1].
3. Use linearly rescaled radial deadzones by default.
4. Ensure that we have a configurable threshold for both the inner and outer values.
5. Ensure that Bevy users can still easily access the raw axis values no matter which configuration mode they're using.

enum DeadzoneShape {
  None,
  Axial(DeadzoneRescaling).
  Radial(DeadzoneRescaling),
}

// Maps from the raw axis input values received
// into the input values observed in `Input<GamepadAxis>`
// The input is in the range [-1, 1]
// The output should also be in the range [-1, 1]
enum DeadzoneRescaling {
  Raw,
  Linear,
  Custom(Fn(f32) -> f32),
}

Additional context

#3450 and the associated #3464 are an initial attempt at handling falloff curves. This work should be coordinated with that work, one way or another.

xinput.h defines some constants they expect you to use for your deadzone... N.B. someone will complain these are too small to be reasonable defaults, and someone else will complain they are too large. I've seen at least one controller worn out enough to drift with defaults. So you'll probably want some kind of scaling option. Oh, and the outer limits may or may not be the integer max. Depends on the controller. And some weirdos like the axial dead zones weird cross shaped deadzone nonsense. And then they'll have strong opinions about the falloff curve from inner to outer - should it be linear? squared? cubed?

• MaulingMonkey from the Rust Gamedev Discord <3

Additional in-depth opinions from Third Helix

[alice-i-cecile]

IMO, the size of the X and Y deadzones should always match. But for bonus points, we could also do drift correction, and apply a constant offset to the raw input events, which should allow players to configure each specific controller to compensate for a constant drift and reduce the deadzone threshold further.

[mfdorst]

I'm interested in taking this on. I'm not knowledgeable in this area though, so it will take me some time to learn. If someone gets to it first, feel free.

I think I might start by adding an example that shows the controller input graphically. I suspect that will make it much easier to debug these changes.

[alice-i-cecile]

I think I might start by adding an example that shows the controller input graphically. I suspect that will make it much easier to debug these changes.

Yes please, this sounds extremely useful.

I'm interested in taking this on. I'm not knowledgeable in this area though, so it will take me some time to learn. If someone gets to it first, feel free.

Sounds good! It's not too complex now that we have an expert spec to work to. Please branch off of #3464; I expect that we'll merge that in first.