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
Gamepad is not working on GZDoom
Moderator: GZDoom Developers
Forum rules
Contrary to popular belief, we are not all-knowing-all-seeing magical beings!
If you want help you're going to have to provide lots of info. Like what is your hardware, what is your operating system, what version of GZDoom/LZDoom/whatever you're using, what mods you're loading, how you're loading it, what you've already tried for fixing the problem, and anything else that is even remotely relevant to the problem.
We can't magically figure out what it is if you're going to be vague, and if we feel like you're just wasting our time with guessing games we will act like that's what you're really doing and won't help you.
Contrary to popular belief, we are not all-knowing-all-seeing magical beings!
If you want help you're going to have to provide lots of info. Like what is your hardware, what is your operating system, what version of GZDoom/LZDoom/whatever you're using, what mods you're loading, how you're loading it, what you've already tried for fixing the problem, and anything else that is even remotely relevant to the problem.
We can't magically figure out what it is if you're going to be vague, and if we feel like you're just wasting our time with guessing games we will act like that's what you're really doing and won't help you.
-
- Posts: 1
- Joined: Wed May 19, 2021 10:02 am
- Graphics Processor: Intel with Vulkan/Metal Support
Re: Gamepad is not working on GZDoom
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.TheEvilPotatoUwU wrote: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
Code: Select all
$ 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
Code: Select all
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.
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
mblockcontrollers=true
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.
Re: Gamepad is not working on GZDoom
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.
EDIT: Also, using the D-pad would be nice for inventory selection or rapid weapon selection.