Scale input to account for deadzones

[BenjaminBrienen]

Objective

Fixes #3450

Solution

Scale the input to account for the range

Testing

Updated unit tests

Migration Guide

GamepadButtonChangedEvent.value is now linearly rescaled to be from 0.0..=1.0 (instead of low..=high) and GamepadAxisChangedEvent.value is now linearly rescaled to be from -1.0..=0.0/0.0..=1.0 (accounting for the deadzone).

[BenjaminBrienen]

I can't work on fixing the unit tests until this is fixed:

error[E0599]: no method named `to_string` found for reference `&str` in the current scope
   --> crates\bevy_ecs\src\name.rs:252:24
    |
252 |         Ok(Name::new(v.to_string()))
    |                        ^^^^^^^^^ method not found in `&str`
    |
    = help: items from traits can only be used if the trait is in scope
help: trait `ToString` which provides `to_string` is implemented but not in scope; perhaps you want to import it
    |
3   + use crate::alloc::string::ToString;

[alice-i-cecile]

I agree that this is the right default behavior. Otherwise setting a deadzone makes it very hard / impossible to get small directional inputs.

This PR needs a bit of cleanup still. It would be particularly helpful to cleanup the tests: right now, the values just look like magic numbers. Maybe we should add some algebra + consts inside of the Some arms?

[alice-i-cecile]

For the alloc error, I think you need to fix the feature flags in a new PR. @bushrat011899, FYI.

[BenjaminBrienen]

For the alloc error, I think you need to fix the feature flags in a new PR. @bushrat011899, FYI.

He's already got that fixed in the no_std bevy_input PR.

[bushrat011899]

Can confirm I have this issue resolved in the no_std bevy_input PR, along with some other issues with how bevy_input feature gates bevy_reflect

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

[alice-i-cecile]

Let's do a quick migration guide noting this change (since it's otherwise surprising), but this LGTM now. Good work on the tests; I like the balance you struck.

[BenjaminBrienen]

Sorry for the noise. I realized that I could make the implementation and test data cleaner by storing the raw values in the gamepad, which means the old values will be raw values. Everything is very optimal now, imo.

[BenjaminBrienen]

Migration guide made me realize the doc comment should be improved. Both are done now.

[alice-i-cecile]

I like the latest changes, and particularly appreciate the comments on the tests.

[Shatur]

Looks good to me! Left a few small suggestions.

Personally, I think deadzone is a more high-level functionality and should be handled by input managers🤔 But since we already have this feature, it's definitely an improvement!
I handle deadzones in the same way in the bevy_enhanced_input library.

[Shatur]

Never inline private methods. Same for other places. Here is a good article about it.

Suggested change

#[inline(always)]

[Shatur]

Use . in the end for all doc comments in Rust:

Suggested change

	/// A linear remapping of `value` from `old` to `new`
	/// A linear remapping of `value` from `old` to `new`.

[Shatur]

I would suggest to split this single test into multiple small tests named like enough_increase_to_change instead of comments. But it's up to you since it was like this before :)

[alice-i-cecile]

Personally, I think deadzone is a more high-level functionality and should be handled by input managers

Agreed. In the medium term, I think this functionality should be removed from bevy_input and moved up a level. But until we have a first party input manager / action crate we're blocked there.

[BenjaminBrienen]

I think deadzones and scaling are good here because they address hardware limitations. Before then, the events are "raw". The part I would move into another crate is actually the clamping/rounding. Those are more about what "feels right". But then again, the same applies for the press/release/change thresholds, and I don't think those can be moved out.

[Shatur]

I would consider bevy_input as a source for raw input and its processing being a higher-level abstraction. That's what I currently do with my crate (I use methods that return raw values and let user apply any modifiers on top of them).

We on the same page with @alice-i-cecile, this PR is good.
I just wanted to share my thoughts for possible future considerations.