Gamepad is not working on GZDoom

[TheEvilPotatoUwU]

hi, so a few days ago i got a USB SNES styled gamepad, and i wanted to play Doom with it, but it isn't working properly, i thought it was a problem with the gamepad, so i tried my bluetooth controller and got the same problem, basically the directional buttons are "pressing themselves" the cursor on the menu keeps going up and to the left like i'm pressing those buttons on the d-pad when i'm not, in game, the same problem, the character keeps going forward and to the left, i tried in Zandronum, prBoom, and in Chocolate doom, and it worked properly it seems like its a problem with my GZDoom installation, or with my pc because i tried on android GZDoom and everything worked fine, can someone help me with this?

EDIT: i'm on arch linux 64bits

[LushKava]

hi, so a few days ago i got a USB SNES styled gamepad, and i wanted to play Doom with it, but it isn't working properly, i thought it was a problem with the gamepad, so i tried my bluetooth controller and got the same problem, basically the directional buttons are "pressing themselves" the cursor on the menu keeps going up and to the left like i'm pressing those buttons on the d-pad when i'm not, in game, the same problem, the character keeps going forward and to the left, i tried in Zandronum, prBoom, and in Chocolate doom, and it worked properly it seems like its a problem with my GZDoom installation, or with my pc because i tried on android GZDoom and everything worked fine, can someone help me with this?

EDIT: i'm on arch linux 64bits

I recently tried using GZDoom with a PS4 controller, which is directly supported by the hid-sony driver in the Linux kernel, and ran into much the same issue. Toggling on "Enable controller support" from a clean start causes the menu to go absolutely haywire. At first, I thought that the reason might be that the readings for the analogue sticks at rest might not be precisely 0 for the axes corresponding to horizontal and vertical movement. However, testing with the jstest utility indicates that this is not the case. Here are the readings for my controller while all sticks and triggers are at rest.

Code: Select all • Expand view

$ jstest --normal /dev/input/js0
Driver version is 2.1.0.
Joystick (Sony Interactive Entertainment Wireless Controller) has 8 axes (X, Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y)
and 13 buttons (BtnA, BtnB, BtnX, BtnY, BtnTL, BtnTR, BtnTL2, BtnTR2, BtnSelect, BtnStart, BtnMode, BtnThumbL, BtnThumbR).
Testing ... (interrupt to exit)
Axes:  0:     0  1:     0  2:-32767  3:     0  4:     0  5:-32767  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off

Here, we can see that the readings are zero for all axes except for Z and Rz, which correspond with the the L2 and R2 triggers on this particular controller (they extend to 32787 when fully pressed). I proceeded to conduct some experiments but, first, let's consider all of the factors here, as they are in their default state.

Code: Select all • Expand view

Axis No  Axis No (gzdoom)  PS4 Stick/Button    Reading at rest  Default Mapping
0        1                 L (horizontal)      0                Strafing
1        2                 L (vertical)        0                Moving Forward
2        3                 L2                  -32767           Looking Up/Down
3        4                 R (horizontal)      0                Turning
4        5                 R (vertical)        0                Moving Up/Down
5        6                 R2                  -32767           None
6        7                 D-pad (horizontal)  0                Unrecognised
7        8                 D-pad (vertical)    0                Unrecognised

NOTE: "Unrecognised" means that GZDoom does not expose the axis at all in its UI.

Any axes that I refer to from hereon will be starting from number 1, as GZDoom does. OK, so the first test was to determine whether Axis #3 and #6 are causing a problem, due to their non-zero readings at rest. Methodology: map both axes to "None" in GZDoom, then restart with mblockcontrollers=false. Result: there is still unwanted menu interaction occurring without my input. Conclusion: it's possible that these axes had been causing a problem but, in that case, they are not exclusively responsible. Why? Because all the remaining axes are now reading 0 at rest, yet there is still unwanted menu interaction.

The second test was to set all mappings to "None" other than for axes #1 and #2, leaving only my L stick having any effect. Methodology: alter mappings accordingly, then restart with mblockcontrollers=false. Result: there is still unwanted menu interaction, with thresholds being triggered along both of the remaining axes. Conclusion: GZDoom's behaviour is starting to look highly questionable. The jstest utility shows perfect zero readings while the stick is at rest, yet GZDoom is still going haywire. Why?

The third test was to increase the deadzone values for axes #1 and #2, with the other axes remaining unmapped. Methodology: increase the deadzone values from the default of 0 incrementally, restarting GZDoom each time with mblockcontrollers=false. Result: Unwanted menu interaction does not cease until the deadzone values are set to 0.150, at the bare minimum. Testing this value during gameplay, the controls remained very sensitive and I did not 'feel' the presence of a deadzone. Conclusion: either jstest is lying about its readings or GZDoom's internal readings are off. Either way, defaulting the deadzone values to 0 seems to be asking for trouble.

@TheEvilPotatoUwU: For now, here is what I suggest you do. Open your ~/.config/gzdoom/gzdoom.ini file in your favourite text editor and search for the mblockcontrollers setting. Change it so that it reads as follows.

Code: Select all • Expand view

mblockcontrollers=true

After saving, load GZDoom. You will be able to control the menu with the keyboard. Use that to edit the controller mappings and, for every axis that is not mapped to "None", set the deadzone value to something other than 0 e.g. the 0.150 value that I mentioned earlier. Next, re-enable "Enable controller support" if it is disabled, then disable "Block controller input in menu", at which point menu control will be re-enabled. Hopefully, the increased deadzone value will be just enough to prevent the spurious menu interaction from occurring. If not, repeat the process, increasing the deadzone values by one step each time.

In summary, I think that there are several issues to consider. Firstly, it's probable that controller support isn't particularly popular and that the Linux builds are less well tested on that front. Secondly, it is questionable that an independent utility in Linux produces zero readings while GZDoom is reading enough to consider acting on the same inputs. I will look further into this, when I find the time. Thirdly, the HID drivers in Linux seem to be highly granular. Whether GZDoom is reading things correctly or incorrectly, it may end up being the case that the decision to default the deadzone values to zero needs to be re-considered. While the PS4 controller and associated driver are of high quality, I wouldn't be surprised to find various controllers out there that are poorly calibrated or are simply of sufficiently low quality that certain axes don't provide perfect zero-readings while at rest. Actually, I have a wide variety of controllers and adapters at my disposal, but haven't tested those yet.

One thing is for certain. To load GZDoom for the first time and be punished by GZDoom being virtually uncontrollable immediately after toggling on controller support makes for a very poor user experience and I think that should be considered as a bug.

[LushKava]

As an aside, these experiments reveal another issue concerning controller support in GZDoom. At least in my case, it only allows for the configuration of six axes. Yet, I have a 7th and 8th axis, which correspond with my D-pad. Basically, it's impossible for me to configure GZDoom to respond to the D-pad in the menu, even though this is the exact thing that I would want to use for this purpose. Navigating a menu with a D-pad feels vastly more natural and, by their very nature, D-pads should be less prone to calibration/deadzone issues. The fact that these axes are marked as hat controls by the driver ("Hat0X" and "Hat0Y") could serve as a hint that they should be able to drive the menu.

EDIT: Also, using the D-pad would be nice for inventory selection or rapid weapon selection.