View Issue Details

IDProjectCategoryView StatusLast Update
0018480Runner Suggestions3DPublic2019-02-11 14:59
ReporterNacky SlockerAssigned ToSuggestions List 
Status ClosedResolutionNo Change Required 
Platform OS OS Version
Summary0018480: Input Devices: Gamepad Deadzone is inaccurate at higher values
DescriptionYour function gamepad_set_axis_deadzone seems to cause "NaN"s, and seems to create "square" deadzones that end up making somewhat "Diamond" shapes in the stick movement. When the deadzone is 1... Really bizarre things happen to both my "custom" function, and the "default" function. I don't know why anyone would want it at 1, but I always like coming prepared (custom functions for users etc.).

My "custom" function isn't perfect, in fact it's somewhat logic heavy (kind of), but it's a start! and it runs pretty accurately! while creating a "circular" deadzone!

The attached sample has all 3 of them (0, custom, and default) working side by side, both sticks. At higher numbers the "default" and "custom" deadzones both act extremely clunky. (not really an issue)

Now I notice the "default" deadzone doesn't work outside of the "blue square" I placed, causing me to believe these are isolated "x" & "y" checks, rather than "x with y" checks.

The problem I have is when I tilt the stick diagonally, it starts becoming a lot less responsive with the "default" deadzone, sometimes not even responding at all. Not the most desirable

If the deadzone is 1, then all gp_axis values return as either 0, or NaN, causing this...


to return "Cannot apply sqrt to negative number.". The only way I can think of coming out with a negative number here is if I was squaring the imaginary number "i".

There! A problem and (hopefully) a solution for it.

Steps To Reproduce1) Run the attached project to see the effects of using the deadzone at differing values with our current implementation
2) In the obj_deadzone uncommented the custom deadzone code to see the effects of the suggested implementation
3) Run the application again and set the deadzone to 1 to notice that the deadzone now shows input correctly for diagonals using the default implementation too
Additional InformationOriginal helpdesk ticket:
TagsNo tags attached.


Stewart Bishop

2015-07-21 17:17

Adminstrator (173,982 bytes)

Mike Rennie

2016-10-24 11:54

Developer   ~0049833

I've fixed the problem with NaNs being generated if the deadzone is set to 1, but we can't really change the default deadzone handling without potentially affecting games in development that have tuned their input for the current system. It's possible we could implement an alternative as a different option but that would need further consideration.