Accessible DeadZone input handling

[atlv24]

What problem does this solve?

DeadZoneShape is not accessibility friendly

What solution would you like?

This discussion is a good read: https://github.com/godotengine/godot-docs/issues/5378#issuecomment-965734470

my conclusions: there should be two primary modes: circle, and cross. Circle has no amount of axis snapping, because sometimes its not desirable, and cross has some amount of axis snapping. Both circle and cross do range shifting such that all possible inputs are reachable and continuous, (meaning, a small change in input vector causes at most a proportionally small change in output vector. all current deadzones in LWIM do not do this, because crossing the deadzone threshold snaps from 0 to whatever the value is outside the deadzone).

Single axis: if input.abs() < deadzone { None } else { Some(input.sign() * (input.abs() - deadzone)) } Circle: if input.magnitude() < deadzone { None } else { Some(input.normalized() * (input.magnitude() - deadzone)) } Cross: handled like single-axis for each axis individually

[Optional] How could this be implemented?

Allow deadzone shapes to mutate the passed-in input by returning an Option<Vec2> instead of a bool. This allows input to be continuous and have unreachable input range, by rescaling/shifting live areas to be zero input on deadzone edges as follows:

This should also be implemented for single axis deadzones, otherwise they will have small unreachable input ranges near zero

[Optional] What alternatives have you considered?

• Make users do deadzone handling this is not ideal because games should be accessible by default. an engine should strive to make it easy for users to get things right, even if they don't know what they are doing.

• Axis snapping decoupled from DeadZoneShape different shapes have different sizes, making snap be a distinct functionality would make it hard to maintain input continuity.

• forget about DeadZoneShape and just do single axis deadzones with range shifting on both axes this works, but we lose the ability to choose different deadzone behaviors. for example, ellipse deadzone should not have any axis snapping but still do range shifting by rescaling input magnitude to zero at the edge of the deadzone.

Related work

Lots of other deadzones that can be supported in the future: https://imgur.com/a/xSfcP (most interesting concepts are Back 4 Blood's unregistered diagonal wedges and Anarchy Reigns' two-threshold central deadzone where once you start moving, a smaller threshold must be returned to to stop moving)

[atlv24]

We may even want to make DeadZoneShape be a user-impl-able trait to support custom deadzone logic cleanly tbh

[alice-i-cecile]

We may even want to make DeadZoneShape be a user-impl-able trait to support custom deadzone logic cleanly tbh

Honestly, I agree with this. It's not performance sensitive and it's very good to add flexibility.