-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Decrease the default deadzone value for actions to better match real world use cases #7069
Comments
Sounds reasonable to me. If I remember correctly, UE uses something like 0.25 and Unity somewhere around 0.15. |
On principle, this change sounds good to me. Maybe we could even go as low as Also, the way this should be implemented should not change existing user-created actions to avoid breaking compatibility. Only built-in actions and newly created actions should be affected by this change. |
@Calinou Good point regarding binary actions! Would it technically be possible to separate them?
|
This would add a lot of complexity to the deadzone implementation (what if you bind both a stick and a trigger to a single action?). I'm not sure if it's worth the added complexity. I'd suggest trying various AAA/indie games and see what happens when you bind axes to binary actions such as shooting, jumping, etc. Run the game in a window (or on a second monitor), keep a gamepad visualizer open (such as the Godot Joypads demo) and see at which strength the action is triggered in the game. |
Thanks for your thoughts! In my quick test also a default value of Great idea regarding testing other games: I play mostly on console, so I have to check which games run on my machine or if I ping a friend regarding this, but def. wanna try. Your point regarding multiple bindings on one action, also brings up the question of where to define the deadzone … From a user perspective the following is more intuitive:
So defining it on an action level is probably not even the best/most useful way. |
Did a bit of trigger sensitivity testing with the Godot joypads tool and an Xbox Series controller.
Feel free to add to the list so we can figure out more. :) From the sample it seems that something around 0.200–0.250 could be a better default. Let me know if I should do more or different testing. |
Thanks for the investigation @jancborchardt! Honestly I don't have enough experience to conclude anything. I think everything lower than the current @Calinou: |
Feel free to open a PR with But as I said, the implementation must not interfere with existing projects in any way as I said above:
Built-in actions probably don't need to be modified in fact, since these are only used for binary actions unless the user is using them for non-UI purposes (which isn't recommended). Footnotes
|
@Calinou Sounds great. |
Implemented by godotengine/godot#97281. |
Describe the project you are working on
A game allowing a gamepad as input.
Describe the problem or limitation you are having in your project
The default deadzone value is
0.5
. By being the default value this implies that it's a reasonable choice.Other people recommend a much lower deadzone value (0.05) and even the Godot docs use 0.2 as an example value.
According to my experience this also behaves weirdly (on my Xbox 360 controller this feels more like using a d-pad than a stick). This might also confuse newer devs that have never heard about deadzones.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Change the default value to something that is more realistic but also works with older/worse hardware.
Maybe to the
0.2
mentioned in the Godot docs.Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Change the default value.
If this enhancement will not be used often, can it be worked around with a few lines of script?
Basically everyone must change the setting in the input map.
Is there a reason why this should be core and not an add-on in the asset library?
It's already core, it's just about changing the default.
The text was updated successfully, but these errors were encountered: