gamepad: The way the analog stick deadzone is implemented may limit developers

[DNin01]

The gamepad extension uses a deadzone mechanism to automatically zero out the value of the analog sticks unless they are tilted past a certain threshold. I believe this is done on each axis individually. If I did my pseudocode correctly, this is how that would be done:

outX = (if (abs(inX) > deadzoneX) then inX else 0)
outY = (if (abs(inY) > deadzoneY) then inY else 0)

It can be visualized like this, where the left side shows the actual position of the stick with the deadzones highlighted in red, and the right is the output - what the game sees.

analog.stick.with.additive.deadzone.webm

This is an issue for point-and-shoot games, where due to the deadzone, any attempt to shoot slightly off from a cardinal direction will always snap to that cardinal direction. This is what I experienced when I tried to make such a game on TurboWarp.

This can be solved by checking both axes at the same time. If either one is past the deadzone, we return the value of both axes. Or we can check if the stick's distance from the center is greater than a certain value. This is what that looks like:

if (sqrt(inX^2 + inY^2) > deadzone) then
  outX = inX
  outY = inY
else
  outX = 0
  outY = 0

analog.stick.with.radial.deadzone.webm

I don't know if this is a good thing in general, but I think it is. If you agree, I don't know how you feel about preserving backwards-compatibility in any edge cases, but I think I would make this change anyway. If you disagree, then there is also a similar issue, #1011, which is a feature request to make the deadzone customizable, for those who need it. The option to customize the deadzone radius could also solve other problems, one of which is better physical steering wheel support which was explained in that issue.

[GarboMuffin]

changing the deadzone to be circular as eg. steam does is reasonable