Implement analog joystick support #1076
Conversation
|
Looking forward to trying this! I struggle to play doom with analog sticks (pre this PR, so, with no variable input) but found using them with look up/down turn left/right worked quite well in heretic and hexen, so I'll give it a spin with those. |
|
I tested with a modern FPS config of having the left stick do strafing + forward/back and right stick turning left/right and R2 to shoot, it works fairly well in my opinion. |
|
Testing with an 8bitdo FC30 pro which has two analog sticks. I haven't (yet) ran the sdl2test programs to see what the analog input looks like from a data POV for this controller. Well, it works... but it's mega-sensitive it seems, at least for turning. Whether I put turning on the left stick or right, with analog input turned on I constantly over-turn. I don't seem to over-strafe, it only seems to be an issue for turning. I wonder if we need to implement and expose some kind of sensitive adjustment? Only tested in doom obviously since it's only applied to Doom so far. Deadzone seems to work, although there's only a very subtle difference on my controller between 0 and 99. Agreed setup UI could use some work. I'd experiment with moving the analog radio above the axis definitions, and making the dead zone option only appear if analog is selected, similar to how window size options only appear if fullscreen is deselected. |
|
I thought I'd try a PS3 controller but I can't get any events out of it in Linux (not just to choco, but anything else either) |
|
With the DualShock 4 controller, both sticks have almost linear input ranging from ~300 to 32768 and it requires virtually no dead zone. It may be that your controller is in digital mode with the analog sticks sending low and high values instead of the full analog range. |
|
I've found sdl2-jstest which I used to use to debug this stuff. I'm getting analog readings from the sticks, but they're just really sensitive. I'm going to read over the gamepad's manual and see whether that's configurable in firmware. One bad joystick experience shouldn't nix this PR... but I'd love to see some of the other maintainers give it a go. My PS3 controller finally showed up in Bluetooth this morning so I might have another go with it tonight. |
| @@ -44,6 +39,12 @@ static SDL_Joystick *joystick = NULL; | |||
|
|
|||
| static int usejoystick = 0; | |||
|
|
|||
| // Use analog joystick input | |||
| int joystick_analog = 0; | |||
There was a problem hiding this comment.
These are not static because we need to know in g_game.c if analog input is enabled or not. If there's a better way to expose that I can refactor it.
| @@ -52,6 +52,12 @@ static int joystick_initted = 0; | |||
|
|
|||
| static int usejoystick = 0; | |||
|
|
|||
| // Use analog joystick axis input | |||
| int joystick_analog = 0; | |||
src/setup/joystick.c
Outdated
| @@ -132,6 +138,8 @@ static int all_joysticks_len = 0; | |||
| // Always loaded before others, to get a known starting configuration. | |||
| static const joystick_config_t empty_defaults[] = | |||
| { | |||
| {"joystick_analog", 0}, | |||
There was a problem hiding this comment.
These probably aren't needed - IIRC they're loaded when configuring a new controller to get a known starting position. Since these parameters are universal across all controllers they don't need to be reset.
src/setup/joystick.c
Outdated
| @@ -1028,6 +1037,17 @@ void ConfigJoystick(void) | |||
| TXT_TABLE_OVERFLOW_RIGHT, | |||
| TXT_TABLE_EMPTY, | |||
| TXT_TABLE_EMPTY, | |||
|
|
|||
| TXT_NewLabel("Dead zone size"), | |||
There was a problem hiding this comment.
How about "Dead zone size (%)" so that the units are clearer?
hifi
force-pushed
the
analog-joystick-clean
branch
from
95ae4ea
to
8bda7ab
Compare
|
Cleaned up the menu a bit with the suggestion of having it as a sub-window. Arranging one checkbox and a spin control with label seems hard without a separating header.
|
|
Meanwhile I bought the cheapest Sixaxis clone I could find for testing and I can agree that with bad analog input it's worse than having digital. The analog range is very badly configured in the firmware making both sticks have different sensitivity in every direction and all of them max out way before the stick is at the edge. I tested with |
|
Just dropping a note that I hope that we can look at this again - I'll see what I can add, but hoping another maintainer with a better-behaving joystick can have a go :) (Or I'll attempt to get my ps3 controller to work) |
|
I tried it on Open Suse with xboxdrv. Works great, although is it the normal behavior to have "always-run" activated when using a gamepad? You don't have to push the stick very far and the player is already turning very fast, so it makes it hard to aim. |
|
@AXDOOMER did you find the "always-run" like behaviour only with analog input switched on, or with it off, too? |
|
@jmtd It "always-runs" only when the analog mode is activated. |
This is an attempt to get smooth analog joystick support in. The dead zone is also configurable and is ignored when calculating the intensity of the axes so that you have the possibility to make very precise moves regardless of how large the dead zone needs to be.
It may be desired to implement even more configuration for analog input if the -32767+32767 scale is too wide for some controllers. There's a slight compensation given for rounding errors.
The changes to chocolate-doom-setup menu are horrible, I'm sorry. Please suggest how the new options should be arranged in there.
On lighter side, Doom is still too hard to play with a controller so there's that. I've tested this with a DualShock 4 controller.
Fixes #901 for Doom, after this PR is massaged enough, same changes would be need to be implemented for other games as well.