Skip to content
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

DPad Buttons Presses Not Detected #149

Closed
zicklag opened this issue Jul 5, 2022 · 3 comments
Closed

DPad Buttons Presses Not Detected #149

zicklag opened this issue Jul 5, 2022 · 3 comments
Labels
bug Something isn't working

Comments

@zicklag
Copy link
Collaborator

zicklag commented Jul 5, 2022

Version

Version 0.3.0

Operating system & version

Pop!_OS ( Ubuntu ) 20.04

What you did

I took the minimal example in this repo and set the jump action to be bound like this:

input_map: InputMap::new([(Action::Jump, GamepadButtonType::DPadUp)])
                .set_gamepad(Gamepad(0))
                .build()

I also had to add the bevy_gilrs feature to the list of Bevy features in the Cargo.toml.

What you expected to happen

Pressing up on the dpad should print "I'm jumping"

What actually happened

Nothing.

Additional information

This does work with non-dpad controller buttons.

I'm still investigating, but it looks like Bevy handles the dpad as an axis type, not as a button type, so the "pressed" detection doesn't work for the dpad like it is expected to in the current code.

Also, I would be interesting in adding basic support for triggering user actions based on analog sticks anyway, because I'm wanting that for my game. I'm assuming you'd be open to a PR? :)

I think the implementation direction for fixing this is probably just about the same for supporting analog sticks, because Bevy treats the dpad almost the same or exactly the same as the analog sticks.

@zicklag zicklag added the bug Something isn't working label Jul 5, 2022
@zicklag zicklag changed the title DPad Buttons Presses Not Detect DPad Buttons Presses Not Detected Jul 5, 2022
@alice-i-cecile
Copy link
Contributor

I'm still investigating, but it looks like Bevy handles the dpad as an axis type, not as a button type, so the "pressed" detection doesn't work for the dpad like it is expected to in the current code.

I think is that this is an oddity in gilrs. I remember this behaving differently for users based on what hardware is used :(

Also, I would be interesting in adding basic support for triggering user actions based on analog sticks anyway, because I'm wanting that for my game. I'm assuming you'd be open to a PR? :)

Yes please! See #78 for initial thoughts.

@zicklag
Copy link
Collaborator Author

zicklag commented Jul 5, 2022

I think is that this is an oddity in gilrs. I remember this behaving differently for users based on what hardware is used :(

I was able to trace this to bevy_gilrs disabling one of the default gilrs event filters that is used to convert dpad axes events into dpad button events. I'll make a PR to bevy to update that, which should close this issue, but I'll still look into getting axis support in leafwing-input-manager so that we can use analog sticks, too.

@zicklag
Copy link
Collaborator Author

zicklag commented Jul 5, 2022

Since this is verified as a Bevy issue I think it's reasonable to close this now. I opened a PR that should fix on the Bevy side: bevyengine/bevy#5220.

@zicklag zicklag closed this as completed Jul 5, 2022
bors bot pushed a commit to bevyengine/bevy that referenced this issue Jul 11, 2022
# Objective

- Enable the `axis_dpad_to_button` gilrs filter to map hats to dpad buttons on supported remotes.
- Fixes Leafwing-Studios/leafwing-input-manager#149
- Might have fixed the confusion related to #3229

## Solution

- Enables the `axis_dpad_to_button` filter in `gilrs` which will use it's remote mapping information to see if there are hats mapped to dpads for that remote model. I don't really understand the logic it uses exactly, but it is usually enabled by default in gilrs and I believe it probably leads to more intuitive mapping compared to the current situation of dpad buttons being mapped to an axis.
- Removes the `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` enum variants to avoid user confusion. Those variants should never be emitted anyway, for all supported remotes.

---

## Changelog

### Changed

- Removed `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` in favor of using `GamepadButtonType::DPad[Up/Down/Left/Right]` instead.

## Migration Guide

If your game reads gamepad events or queries the axis state of `GamePadAxisType::DPadX` or `GamePadAxisType::DPadY`, then you must migrate your code to check whether or not the `GamepadButtonType::DPadUp`, `GamepadButtonType::DPadDown`, etc. buttons were pressed instead.
inodentry pushed a commit to IyesGames/bevy that referenced this issue Aug 8, 2022
# Objective

- Enable the `axis_dpad_to_button` gilrs filter to map hats to dpad buttons on supported remotes.
- Fixes Leafwing-Studios/leafwing-input-manager#149
- Might have fixed the confusion related to bevyengine#3229

## Solution

- Enables the `axis_dpad_to_button` filter in `gilrs` which will use it's remote mapping information to see if there are hats mapped to dpads for that remote model. I don't really understand the logic it uses exactly, but it is usually enabled by default in gilrs and I believe it probably leads to more intuitive mapping compared to the current situation of dpad buttons being mapped to an axis.
- Removes the `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` enum variants to avoid user confusion. Those variants should never be emitted anyway, for all supported remotes.

---

## Changelog

### Changed

- Removed `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` in favor of using `GamepadButtonType::DPad[Up/Down/Left/Right]` instead.

## Migration Guide

If your game reads gamepad events or queries the axis state of `GamePadAxisType::DPadX` or `GamePadAxisType::DPadY`, then you must migrate your code to check whether or not the `GamepadButtonType::DPadUp`, `GamepadButtonType::DPadDown`, etc. buttons were pressed instead.
james7132 pushed a commit to james7132/bevy that referenced this issue Oct 28, 2022
# Objective

- Enable the `axis_dpad_to_button` gilrs filter to map hats to dpad buttons on supported remotes.
- Fixes Leafwing-Studios/leafwing-input-manager#149
- Might have fixed the confusion related to bevyengine#3229

## Solution

- Enables the `axis_dpad_to_button` filter in `gilrs` which will use it's remote mapping information to see if there are hats mapped to dpads for that remote model. I don't really understand the logic it uses exactly, but it is usually enabled by default in gilrs and I believe it probably leads to more intuitive mapping compared to the current situation of dpad buttons being mapped to an axis.
- Removes the `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` enum variants to avoid user confusion. Those variants should never be emitted anyway, for all supported remotes.

---

## Changelog

### Changed

- Removed `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` in favor of using `GamepadButtonType::DPad[Up/Down/Left/Right]` instead.

## Migration Guide

If your game reads gamepad events or queries the axis state of `GamePadAxisType::DPadX` or `GamePadAxisType::DPadY`, then you must migrate your code to check whether or not the `GamepadButtonType::DPadUp`, `GamepadButtonType::DPadDown`, etc. buttons were pressed instead.
ItsDoot pushed a commit to ItsDoot/bevy that referenced this issue Feb 1, 2023
# Objective

- Enable the `axis_dpad_to_button` gilrs filter to map hats to dpad buttons on supported remotes.
- Fixes Leafwing-Studios/leafwing-input-manager#149
- Might have fixed the confusion related to bevyengine#3229

## Solution

- Enables the `axis_dpad_to_button` filter in `gilrs` which will use it's remote mapping information to see if there are hats mapped to dpads for that remote model. I don't really understand the logic it uses exactly, but it is usually enabled by default in gilrs and I believe it probably leads to more intuitive mapping compared to the current situation of dpad buttons being mapped to an axis.
- Removes the `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` enum variants to avoid user confusion. Those variants should never be emitted anyway, for all supported remotes.

---

## Changelog

### Changed

- Removed `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` in favor of using `GamepadButtonType::DPad[Up/Down/Left/Right]` instead.

## Migration Guide

If your game reads gamepad events or queries the axis state of `GamePadAxisType::DPadX` or `GamePadAxisType::DPadY`, then you must migrate your code to check whether or not the `GamepadButtonType::DPadUp`, `GamepadButtonType::DPadDown`, etc. buttons were pressed instead.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants