Separate gamepad state code from gamepad event code and other customizations #700

simpuid · 2020-10-18T19:37:53Z

Earlier implementation of bevy_gilrs controls both the state and event part of gamepad input. In this PR the gamepad state part is moved to bevy_input. Now bevy_gilrs generates raw events in form of GamepadEvent in FIRST stage and then bevy_input reads those events in EVENT_UPDATE stage and update the gamepad states stored as Input<GamepadButton>, Axis<GamepadButton> and Axis<GamepadAxis>.
Gilrs uses same events(the events exposed in the API) to maintain gamepad state, so there is no way to query the state of connected gamepad during the connection event. This makes querying for default states of buttons and axis on connection event redundant. So this PR simplifies the connection event code.
Internally, gilrs' buttons can be classified into 2 types:
1. which takes continuous values between 0.0 and 1.0 (both inclusive) from platform code.
2. which takes discrete pressed/released event from platform code.
Both buttons can generate ButtonPressed, ButtonReleased and ButtonChange event in gilrs.
For buttons of first type, values from this function is used to generate ButtonPressed and ButtonRelease event internally in gilrs.
For buttons of second type, (pressed, released) is mapped to (1.0, 0.0) which generates ButtonChange event internally in gilrs.
So this PR emulates the button press/release from only ButtonChange event in bevy_input crate (ButtonPressed and ButtonReleased becomes redundant)
Resource GamepadProperty holds the data required for this button press/release emulation. The data is stored as ButtonProperty struct and can be changed anytime, which was not possible in earlier implementation as GilrsBuilder::set_axis_to_btn can be called only during initialization. Moreover, user can set default struct as well as specific struct for each GamepadButton as required. Default value of gilrs is used as default.
AxisProperty is used to store the deadzones and threshold for GamepadAxis in the same way as ButtonProperty. Arbitrary default value is used for deadzone and default value of gilrs is used for threshold.
ButtonAxisProperty is used to store the deadzones and threshold for GamepadButton that behave as axis in the same way as ButtonProperty. Arbitrary default value is used for deadzone and default value of gilrs is used for threshold.
gamepad_input example is updated to print axis values only on change.
gamepad_input_event example is added which uses the raw events (ButtonChange and AxisChange)
Parameter of Axis<T>::get and Axis<T>::remove is changed from &T to T to make is more analogous to Input<T> (separate commit, can be reverted)

… more customizable

cart · 2020-10-20T19:47:48Z

crates/bevy_gilrs/src/lib.rs

-                        stage::EVENT_UPDATE,
-                        gilrs_update_system.thread_local_system(),
-                    );
+                    .add_startup_system_to_stage(


nit: this is equivalent to add_startup_system(...), which is the approach we use everywhere else for "adding to the default stage".

cart · 2020-10-20T20:10:07Z

crates/bevy_input/src/gamepad.rs

+}
+
+#[derive(Debug, Clone)]
+pub struct ButtonProperty {


"Property" already has meaning in Bevy (ex: the bevy_property crate). Can we rename everything that is XProperty to XSettings?

Renamed to *Setting

cart · 2020-10-20T20:14:04Z

crates/bevy_input/src/gamepad.rs

+    event: Res<Events<GamepadEvent>>,
+    properties: Res<GamepadProperty>,
+) {
+    button.update();


nit: lets use a slightly more descriptive name here like button_input

cart · 2020-10-20T20:14:57Z

crates/bevy_input/src/gamepad.rs

+    mut button: ResMut<Input<GamepadButton>>,
+    mut axis: ResMut<Axis<GamepadAxis>>,
+    mut button_axis: ResMut<Axis<GamepadButton>>,
+    event: Res<Events<GamepadEvent>>,


nit: lets make this events because its a collection

cart · 2020-10-20T20:18:45Z

crates/bevy_input/src/lib.rs

+                gamepad_event_system.system(),
+            )
+            .add_system_to_stage(bevy_app::stage::EVENT_UPDATE, gamepad_event_system.system())
+            .init_resource::<Axis<GamepadButton>>()


This is redundant. We already init this on line 56

cart · 2020-10-20T20:20:31Z

examples/input/gamepad_input.rs

-                println!("Pressed {:?}", GamepadButton(*gamepad, *button_type));
+            let gamepad_button = GamepadButton(*gamepad, *button_type);
+            if inputs.just_pressed(gamepad_button) {
+                println!("{:?} Pressed", gamepad_button);
            } else if inputs.just_released(GamepadButton(*gamepad, *button_type)) {


you could use gamepad_button here too

Renamed to button_inputs

cart · 2020-10-20T20:35:01Z

examples/input/gamepad_input.rs

@@ -19,17 +20,24 @@ struct GamepadLobby {
    gamepad_event_reader: EventReader<GamepadEvent>,
 }

+#[derive(Default)]


I think this example is a good way to test that the implementation works correctly, but I don't think its the best illustration of how people should actually use the api. I'd prefer it if we trimmed it down to be more like the other input examples. The GamepadLobby should probably stay as-is, but can we remove GamepadData (and all "previous value" testing), print pressed, released, and the Axis<GamepadButton> axis for a single button (instead of an array), and print a single Axis value? (printing each frame is fine)

Now it prints press/release events for South button, value of button RightTrigger2, value for LeftStickX all in the same system gamepad_system

simpuid · 2020-10-21T02:18:02Z

I shall merge all to a single commit before merge

cart · 2020-10-21T17:26:40Z

Looks good to me! I prefer XSettings over XSetting because in each case, its a "collection of configurable things", but I think I'll just merge this now and then follow up with a pr.

simpuid force-pushed the gilrs_extra branch 2 times, most recently from 96b0aa5 to aaaa15f Compare October 18, 2020 20:10

simpuid changed the title ~~Separate gamepad state code from gamepad event code~~ Separate gamepad state code from gamepad event code and other goodies Oct 18, 2020

simpuid changed the title ~~Separate gamepad state code from gamepad event code and other goodies~~ Separate gamepad state code from gamepad event code and other customizations Oct 18, 2020

simpuid force-pushed the gilrs_extra branch from aaaa15f to cd9c4c2 Compare October 18, 2020 20:38

simpuid added 2 commits October 19, 2020 02:16

Separated gamepad event and gamepad state code and made gamepad input…

20fbe83

… more customizable

Changed parameter of get and remove of Axis<T> from &T to T

5363b09

simpuid force-pushed the gilrs_extra branch from cd9c4c2 to 5363b09 Compare October 18, 2020 20:51

memoryruins added C-Code-Quality A section of code that is hard to understand or change A-Input Player input via keyboard, mouse, gamepad, and more labels Oct 20, 2020

cart reviewed Oct 20, 2020

View reviewed changes

Simplify gamepad_input example and refactor bevy_input::gamepad

853af82

simpuid force-pushed the gilrs_extra branch from 77e1c63 to 853af82 Compare October 21, 2020 01:53

cart merged commit d01ba9e into bevyengine:master Oct 21, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Separate gamepad state code from gamepad event code and other customizations #700

Separate gamepad state code from gamepad event code and other customizations #700

simpuid commented Oct 18, 2020 •

edited

Loading

cart Oct 20, 2020

simpuid Oct 21, 2020

cart Oct 20, 2020

simpuid Oct 21, 2020

cart Oct 20, 2020

simpuid Oct 21, 2020

cart Oct 20, 2020

simpuid Oct 21, 2020

cart Oct 20, 2020

simpuid Oct 21, 2020

cart Oct 20, 2020

simpuid Oct 21, 2020

cart Oct 20, 2020

simpuid Oct 21, 2020

simpuid commented Oct 21, 2020

cart commented Oct 21, 2020

Separate gamepad state code from gamepad event code and other customizations #700

Separate gamepad state code from gamepad event code and other customizations #700

Conversation

simpuid commented Oct 18, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simpuid commented Oct 21, 2020

cart commented Oct 21, 2020

simpuid commented Oct 18, 2020 •

edited

Loading