-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UserInput as trait #346
UserInput as trait #346
Conversation
@@ -78,7 +78,7 @@ use std::marker::PhantomData; | |||
pub struct InputMap<A: Actionlike> { | |||
/// The raw vector of [PetitSet]s used to store the input mapping, | |||
/// indexed by the `Actionlike::id` of `A` | |||
map: Vec<PetitSet<UserInput, 16>>, | |||
map: Vec<PetitSet<Box<dyn InputLikeObject>, 16>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should just swap to a HashMap here now that we're no longer trying to stack-allocate. Will simplify a lot of code.
I'm pretty sure petitset
can be killed as a dependency completely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume we still want "slots" so the inputs are ordered and we can have a "secondary" input in index 1 without the "primary" index 0 being populated. Probably accomplish this with a HashMap<usize, Box<dyn InputLikeObject>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would you think of having a type that wraps the HashMap so we can make it more clear what the purpose of the usize is? Named something like Bindings
? That way when we call things like InputMap::get we return our Bindings struct instead of a hashmap with a usize as key that is somewhat unclear what the purpose is.
cd0bf92
to
876f284
Compare
Rebased on main to fix conflict. The I think something that needs some thought is ButtonLike and AxisLike, currently they are just marker traits that could easily be replaced with a bool. I feel like they could be doing more. Maybe split up the InputStreams Trait into those traits or something, not sure if that's possible yet. I'll probably implement Gamepad next since that has axes, and might give some insight. |
I would expect we want a method to create a |
61da50f
to
d193141
Compare
# Objective Add a get_unclamped method to [Axis](https://docs.rs/bevy/0.10.1/bevy/input/struct.Axis.html) to allow it to be used in cases where being able to get a precise relative movement is important. For example, camera zoom with the mouse wheel. This would make it possible for libraries like leafwing input manager to leverage `Axis` for mouse motion and mouse wheel axis mapping. I tried to use it my PR here Leafwing-Studios/leafwing-input-manager#346 but will likely have to revert that and read the mouse wheel events for now which is what prompted this PR. ## Solution Instead of clamping the axis value when it is set, it now stores the raw value and clamps it in the `get` method. This allows a simple get_unclamped method that just returns the raw value. ## Changelog - Added a get_unclamped method to Axis that can return values outside of -1.0 to 1.0
# Objective Add a get_unclamped method to [Axis](https://docs.rs/bevy/0.10.1/bevy/input/struct.Axis.html) to allow it to be used in cases where being able to get a precise relative movement is important. For example, camera zoom with the mouse wheel. This would make it possible for libraries like leafwing input manager to leverage `Axis` for mouse motion and mouse wheel axis mapping. I tried to use it my PR here Leafwing-Studios/leafwing-input-manager#346 but will likely have to revert that and read the mouse wheel events for now which is what prompted this PR. ## Solution Instead of clamping the axis value when it is set, it now stores the raw value and clamps it in the `get` method. This allows a simple get_unclamped method that just returns the raw value. ## Changelog - Added a get_unclamped method to Axis that can return values outside of -1.0 to 1.0
@alice-i-cecile could use some input on the direction you want to go with deadzones. It used to be that SingleAxis would store the positive_low and negative_low values for deadzone. Now that SingleAxisLike is a trait, we can implement it for GamepadAxis and directly insert that into the mapping instead of converting it into a SingleAxis first which seems like a win. But now it's unclear where to handle the deadzone. Here's the solutions I've thought of so far:
Feel free to take some time to respond, I have other things I can keep working on with this. |
Currently non-functional and very messy/incomplete. Looking for input on how to solve the need to be able to Serialize InputLike but unable to do so while using dynamic dispatch.
Might be ways to make this cleaner, for now just trying to work towards compiling to make sure the InputLike trait idea works out.
I don't think this makes sense with the new InputLike trait as we don't know all the possible input types. InputLike::raw_inputs instead returns the individual inputs for InputLike collections.
It got re-added again as an empty file during a rebase on main.
Previously had implemented InputLikeObject for Box<InputLikeObject> to allow accepting boxed or unboxed InputLikeObjects, but it also created the potential to accidentally double box. By implementing From<InputLikeObject> for Box<InputLikeObject> and having methods take impl Into<Box<InputLikeObject> we can accept both without double boxing potential.
96eeb26
to
159a88e
Compare
Preference is for 3 if we can swing it: it definitely feels like managing deadzones is within the domain of the trait. |
Was fully qualified due to a conflict that no longer exists.
# Conflicts: # src/action_state.rs # src/systems.rs
# Conflicts: # benches/input_map.rs # examples/multiplayer.rs # src/action_state.rs # src/axislike.rs # src/clashing_inputs.rs # src/input_map.rs # src/input_mocking.rs # src/input_streams.rs # src/user_input.rs # tests/clashes.rs # tests/gamepad_axis.rs # tests/mouse_motion.rs # tests/mouse_wheel.rs
I might not get back to this seriously before mid September, working more hours to get a demo done for our game for a convention. If anyone wants to pick it up before then I'd be happy to answer any questions. Current status is that it passes all the tests except for the deadzone ones because that isn't re-implemented yet. Checklist on original post has been updated with some other things that need finished like docs, migration guide etc. |
I think I'll have to bow out of heading this up. I've been trying to merge or rebase from main but there are enough conflicting changes it might be cleaner to start over and just look at the Hopefully this was still valuable as an experiment to show a way it could be done using traits. Closing this PR for now, but if anyone wants to try and resurrect the branch as their own or anything you're more than welcome to use it. I'm also open to doing work related to it if there are ideas on how to make it simpler or break it into smaller changes that could be merged incrementally. |
Sounds good <3 thanks for doing this investigation; I'll take a crack at this next time I'm in the mood for something crunchy. |
Description
Change our UserInput enum to be a trait. Adds the ability for other libraries to add new inputs that can be mapped to our actions. Also removes all UserInput instances being the size of the largest variant (which was inflated due to Chords using PetiteSets stored on the stack)
Closes: #321
Current Status
Good progress has been made but still some major things to finish implementing such as deserialization.
TODO
For reference: old InputStreams & old InputKind
#![forbid(missing_docs)]