View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0018480||Runner||[All Projects] Input Devices||Public||2015-07-21 17:10||2016-10-24 11:57|
|Reporter||Nacky Slocker||Assigned To||Suggestions List|
|Priority||High||Severity||C - General||Reproducibility||100%|
|Target Version||Fixed in Version|
|Summary||0018480: Input Devices: Gamepad Deadzone is inaccurate at higher values|
|Description||Your 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 Reproduce||1) 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 Information||Original helpdesk ticket: http://help.yoyogames.com/tickets/89038|
|1.4 Found In||1.4.1598|
|2.x Runtime Found In|
|2.x Runtime Verified In|
Deadzones_gm.zip (173,982 bytes)
||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.|