-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Add gamepad_stick_input
example
#3721
Conversation
Still adding some stuff. I want to mark the deadzone regions with boxes. |
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.
This seems like a good addition to me. We don't expose gamepad settings anywhere else and it looks nice!
Can we add a circle with radius 1 to verify that the joystick never leaves it? |
Not sure how to render a circle but I'll try and figure it out. |
you can't currently without adding a lot of unrelated complexity (or using a picture of a circle) |
I think either "picture of a circle" or just leaving it would be fine for this initial example. |
The circle thing adds a bit of complexity because the way the outside deadzone is currently shown is that the clear color is the deadzone color and the livezone is shown with a lighter gray sprite. If I want to show the circle I'd probably to have the livezone be a light gray circle and then render four sprites around the edges for the outside deadzone. I can do that but I think it might be better not to in the interest of simplicity. Let me know what you think. |
Also, all of this will need to change when #3464 lands, because it will no longer be possible to visualize the deadzone areas unless we add a way to get the raw unscaled input (incidentally I think that would be handy because then I could show two crosshairs, one for scaled and one for unscaled, but admittedly I can't think of a use-case for that in an actual game). |
I don't think this is something that controllers generally guarantee. In hardware joysticks are usually a pair of linear variable resistors for each of the x & y axes, with the radius only being constrained physically by the cutout in the plastic form, not electrically. You can verify this by testing your own controllers with something like gamepad-tester.com. Here's an xbox controllers which has an interesting rounded-square shape because the variable resistors actually max out before being restricted when positioned at the extremes directly along the x/y axes, though it does become constrained by the circular cutout elsewhere: Many controllers have differently shaped cutouts, some circular and some octagonal, and there may be some that happen to not limit the radius of the stick at all beyond the extremes of each axis (so x: 1.0, y: 1.0 may be valid/attainable). |
@mfdorst would you mind rewriting the most recent commit message to not include the |
@rparrett oh I'm sorry, I wasn't aware of the spam issue. I will fix that. |
This PR adds a new example. Adding module and item level doc comments, as described in:
would be really useful to those who will browse examples. |
@rparrett could I get your approval on this? This is a super cool example that I'd like to include. |
# Objective Bevy users often want to create circles and other simple shapes. All the machinery is in place to accomplish this, and there are external crates that help. But when writing code for e.g. a new bevy example, it's not really possible to draw a circle without bringing in a new asset, writing a bunch of scary looking mesh code, or adding a dependency. In particular, this PR was inspired by this interaction in another PR: #3721 (comment) ## Solution This PR adds `shape::RegularPolygon` and `shape::Circle` (which is just a `RegularPolygon` that defaults to a large number of sides) ## Discussion There's a lot of ongoing discussion about shapes in <bevyengine/rfcs#12> and at least one other lingering shape PR (although it seems incomplete). That RFC currently includes `RegularPolygon` and `Circle` shapes, so I don't think that having working mesh generation code in the engine for those shapes would add much burden to an author of an implementation. But if we'd prefer not to add additional shapes until after that's sorted out, I'm happy to close this for now. ## Alternatives for users For any users stumbling on this issue, here are some plugins that will help if you need more shapes. https://github.com/Nilirad/bevy_prototype_lyon https://github.com/johanhelsing/bevy_smud https://github.com/Weasy666/bevy_svg https://github.com/redpandamonium/bevy_more_shapes https://github.com/ForesightMiningSoftwareCorporation/bevy_polyline
This PR needs to be updated due to #4519 being merged. index 8f9e2cfed..bf8bb4f01 100644
--- a/examples/input/gamepad_stick_input.rs
+++ b/examples/input/gamepad_stick_input.rs
@@ -39,10 +39,10 @@ fn update_position(
for gamepad in gamepads.iter() {
// We only use input from the left stick.
let x = axes
- .get(GamepadAxis(*gamepad, GamepadAxisType::LeftStickX))
+ .get(GamepadAxis::new(*gamepad, GamepadAxisType::LeftStickX))
.unwrap();
let y = axes
- .get(GamepadAxis(*gamepad, GamepadAxisType::LeftStickY))
+ .get(GamepadAxis::new(*gamepad, GamepadAxisType::LeftStickY))
.unwrap();
transform.translation.x = x * WINDOW_SIZE / 2.0;
transform.translation.y = y * WINDOW_SIZE / 2.0; |
Oh and we also merged #3730, so we can add a unit circle indicator :D |
I do think it would be a good idea to rework this so that it's window-size-agnostic / just displays the thing in the center of the screen. (Thinking about https://bevyengine.org/examples/)
Drawing the edges that way shouldn't be necessary. In order of increasing Z you can spawn
|
# Objective Bevy users often want to create circles and other simple shapes. All the machinery is in place to accomplish this, and there are external crates that help. But when writing code for e.g. a new bevy example, it's not really possible to draw a circle without bringing in a new asset, writing a bunch of scary looking mesh code, or adding a dependency. In particular, this PR was inspired by this interaction in another PR: bevyengine#3721 (comment) ## Solution This PR adds `shape::RegularPolygon` and `shape::Circle` (which is just a `RegularPolygon` that defaults to a large number of sides) ## Discussion There's a lot of ongoing discussion about shapes in <bevyengine/rfcs#12> and at least one other lingering shape PR (although it seems incomplete). That RFC currently includes `RegularPolygon` and `Circle` shapes, so I don't think that having working mesh generation code in the engine for those shapes would add much burden to an author of an implementation. But if we'd prefer not to add additional shapes until after that's sorted out, I'm happy to close this for now. ## Alternatives for users For any users stumbling on this issue, here are some plugins that will help if you need more shapes. https://github.com/Nilirad/bevy_prototype_lyon https://github.com/johanhelsing/bevy_smud https://github.com/Weasy666/bevy_svg https://github.com/redpandamonium/bevy_more_shapes https://github.com/ForesightMiningSoftwareCorporation/bevy_polyline
# Objective Bevy users often want to create circles and other simple shapes. All the machinery is in place to accomplish this, and there are external crates that help. But when writing code for e.g. a new bevy example, it's not really possible to draw a circle without bringing in a new asset, writing a bunch of scary looking mesh code, or adding a dependency. In particular, this PR was inspired by this interaction in another PR: bevyengine#3721 (comment) ## Solution This PR adds `shape::RegularPolygon` and `shape::Circle` (which is just a `RegularPolygon` that defaults to a large number of sides) ## Discussion There's a lot of ongoing discussion about shapes in <bevyengine/rfcs#12> and at least one other lingering shape PR (although it seems incomplete). That RFC currently includes `RegularPolygon` and `Circle` shapes, so I don't think that having working mesh generation code in the engine for those shapes would add much burden to an author of an implementation. But if we'd prefer not to add additional shapes until after that's sorted out, I'm happy to close this for now. ## Alternatives for users For any users stumbling on this issue, here are some plugins that will help if you need more shapes. https://github.com/Nilirad/bevy_prototype_lyon https://github.com/johanhelsing/bevy_smud https://github.com/Weasy666/bevy_svg https://github.com/redpandamonium/bevy_more_shapes https://github.com/ForesightMiningSoftwareCorporation/bevy_polyline
Closing in favor of the rebased #6052 <3 Excellent work with the prototyping here though; thanks! |
# Objective Bevy users often want to create circles and other simple shapes. All the machinery is in place to accomplish this, and there are external crates that help. But when writing code for e.g. a new bevy example, it's not really possible to draw a circle without bringing in a new asset, writing a bunch of scary looking mesh code, or adding a dependency. In particular, this PR was inspired by this interaction in another PR: bevyengine#3721 (comment) ## Solution This PR adds `shape::RegularPolygon` and `shape::Circle` (which is just a `RegularPolygon` that defaults to a large number of sides) ## Discussion There's a lot of ongoing discussion about shapes in <bevyengine/rfcs#12> and at least one other lingering shape PR (although it seems incomplete). That RFC currently includes `RegularPolygon` and `Circle` shapes, so I don't think that having working mesh generation code in the engine for those shapes would add much burden to an author of an implementation. But if we'd prefer not to add additional shapes until after that's sorted out, I'm happy to close this for now. ## Alternatives for users For any users stumbling on this issue, here are some plugins that will help if you need more shapes. https://github.com/Nilirad/bevy_prototype_lyon https://github.com/johanhelsing/bevy_smud https://github.com/Weasy666/bevy_svg https://github.com/redpandamonium/bevy_more_shapes https://github.com/ForesightMiningSoftwareCorporation/bevy_polyline
Objective
In pursuit of #3691 I felt that it would be handy to have a way to visualize the gamepad stick input.
Solution
Add an example that shows gamepad stick input.
The dark gray regions in the center and the outer border are the default deadzones.