[Gamepad] Remove default gamepad axis deadzone on MacOS/GLFW

[dmg46664]

Please, before submitting a new issue verify and check:

• I tested it on latest raylib version from master branch
• I checked there is no similar issue already reported
• I checked the documentation on the wiki
• My code has no errors or misuse of raylib

Issue description

Edit: The following sentence isn't relevant as it was misdiagnosed: Raylib expects a compile time constant to set the deadzone

Raylib does not appear to have an API to set the deadzone of a controller, yet it exists and is defaulted on the GLFW backend on MacOS.

This should be up to the user in game as

1. Gamepads with HALL-effect sensors may have zero drift, and users will be hamstrung by arbitrary drift. This may be needed for FPSs and simulator games requiring precision control.
2. Users with older potentiometer controllers may have larger drift amounts that need to be manually set.

In order to accommodate this an API is required for setting the dead-zone independently for each controller axis, of each gamepad.

In addition hard coding this requires recompilation of the library if used by JS, Python or other scripting wrapper (I'm using Vybe), preventing the wrapper from hosting "it just works out the box" compiled version of Raylib in their library.

Solutions in ascending order of difficulty:

1. A stepping stone solution would simply be to default it 0.0 which would allow all games to handle this in game code. Solves for wrappers.
2. An API that allows settings a single setting across all controller axis in game.
3. An API that allows setting for each hardware axis independently for each controller (this properly models reality of user's controllers).

No expectations, just posting to start a discussion. Thanks for the library :-)

Environment

Platform backend: DESKTOP (GLFW) on MacOS

Issue Screenshot

N/A

Code Example

In issue description.

[Peter0x44]

The code you linked to is part of rgfw, not raylib
https://github.com/ColleagueRiley/RGFW/blob/main/RGFW.h
So if it's a problem with that, it should go in that repo.

Note you also don't have to use raylib's API for controllers, I personally don't and use SDL instead.

[dmg46664]

@Peter0x44 Thanks for your response.
Apologies, I'm busy working out how the whole thing is put together.

I didn't realise that Raylib had different backends.
I see that I'm using INFO: Platform backend: DESKTOP (GLFW) on MacOS.
And I'm doing

(vr.c/get-gamepad-axis-movement 0 (raylib/GAMEPAD_AXIS_LEFT_X))

which would be calling the native

GetGamepadAxisMovement(0, GAMEPAD_AXIS_LEFT_X)

I can see the deadzone behaviour anywhere on both the X and Y axis (not just around 0,0). I've just misdiagnosed where exactly the problem stems from. Thank you for your tip re SDL.

[Peter0x44]

If you are using glfw, you are not using the code you linked, and it isn't relevant.

[dmg46664]

Thanks @Peter0x44. I've updated the issue that the problem exists despite the misdiagnosed code.

[dmg46664]

Thanks for the code snippet @asdqwe .
If I comment out the section

// Calculate deadzones:
        /* if (dz) { */
        /*     if (lax > -laxdz && lax < laxdz) { lax = 0.0f; } */
        /*     if (lay > -laydz && lay < laydz) { lay = 0.0f; } */
        /*     if (rax > -raxdz && rax < raxdz) { rax = 0.0f; } */
        /*     if (ray > -raydz && ray < raydz) { ray = 0.0f; } */
        /* } */

There is still a deadzone being applied to the controller input!
No such deadzone exists if I check with https://hardwaretester.com/gamepad

I agree that if I wanted to increase the deadzone, such client code is sufficient and I wouldn't request it being added.

[dmg46664]

Renamed issue now that I can infer from your comments that a default deadzone wasn't intentional.

[dmg46664]

Thanks @asdqwe for pulling up the documentation.

So I ran the following test.

git clone https://github.com/glfw/glfw.git
cd glfw
cmake -S . -B build
cd build
make
./tests/joysticks.app/Contents/MacOS/joysticks

... and I can confirm no artificially set deadzone 🤷‍♂️ 🤔
It can't be MacOS or GLFW. Must be a version difference or the way it's configured.

[dmg46664]

@asdqwe For the example you provided I'm just doing

brew install raylib --HEAD
gcc drift.c $(pkg-config --libs --cflags raylib) -o drift

... although I might add that brew install raylib which installed 5.0 didn't detect Gamepad at all.

[dmg46664]

@asdqwe So what does the following code do?

https://github.com/raysan5/raylib/blob/4cd243f0a3a8e9f59e5d5453f88360f5acbc29f7/src/rcore.c#L3298C1-L3299C1

// 0.1f = GAMEPAD_AXIS_MINIMUM_DRIFT/DELTA
        if (movement > value + 0.1f) value = CORE.Input.Gamepad.axisState[gamepad][axis];

[dmg46664]

Looks suspicious 😆

[dmg46664]

Whoop! 🦸‍♂️ At least I'm not going mad re testing!
Don't mind if you want to default it, but there must be a means of disabling it. Ideally at runtime. This goes back to my original suggestions.

Also it's bad as implemented, because this will affect the whole axis! Not only around the origin, which I think is the way it's usually done in games (could be wrong).

[dmg46664]

Now I have to figure out how to build raylib...

@asdqwe But how does that fix it for me? I'm using it prebuilt from Vybe https://github.com/pfeodrippe/vybe (so I can make edits at runtime).

• If there isn't an option to set it at runtime, then it should be defaulted to off.
• If there is an option to set it at runtime, then I don't mind it defaulted to on to preserve behaviour. This is what I meant previously.