Gamepad usability issues
After hearing several harrowing reports about completely broken joystick/joypad support in Doomsday I decided to pick myself up a wireless XBOX360 controller to try it out for myself (I had been planning on getting one anyway).
On starting Doomsday I expected that I would at least be able to get feedback from my joypad, however this was not the case. The only way I could get the joypad to even function was to change the default value of the variable "joydevice" (used with cvar "input-joy-device") in sys_input.c (Doomsday was defaulting to use device zero (which on this system is the virtual HID for my art tablet)).
Due to the problem with the config files not being read early enough there is no way to change the joystick/joypad device (obviously only affects systems with many HIDs but it is very common these days to have more than one (joypad, remote control, external laptop navpad, game boards...).
Next, I was on to trying the default bindings. Sadly, I was completely unable to start a game without first reconfiguring the controls and even then I ran into the following issues:
- After binding menu open/close to another button on the joypad I was able to open but not close the menu.
- Impossible to bind the POV hat for anything useful (seems that B_BindCommand is deleting all other bindings for the hat when you create a new one (most likely lacking the angle qualifier)).
- Possible to bind the joystick axes for menu navigation but once you do, the menu begins wildly repeating events (seems to be missing a repeat delay).
- Axis position drifting. Regardless of how I configured the deadzone and scale values for a particular axis I could not eliminate the drifting.
- No repeaters for the POV hat.
- Lookspring is broken.
- Most of the ctl-* cvars no longer work.
- Due to the issue with held controls during bind context (de)activation (see here http://sourceforge.net/tracker/?func=detail&aid=2849414&group_id=74815&atid=542099), most of what should be possible with the Doomsday binding system is not.
Joystick/joypad support is not looking good atm.
#1 Updated by danij over 13 years ago
Scratch what I said in my last comment. It would seem that the syntax described in comments within the source does not match up with the actual syntax used.
The POV hat binding issue is caused by B_DeleteMatching not considering the angle when attempting to match existing event bindings. Fixed.
#2 Updated by skyjake over 13 years ago
(originally posted by anonymous SF.net user)
Any progress on this?
#3 Updated by danij over 13 years ago
The various issues with the POV hat seem to be due to the way the angle is interpreted within the engine. The symbolic event constructor appears to be returning textual events with a syntax not understood by the bindings system.
"joy-hat1-angle0" is the resultant string from the symbolic echo'd event.
"joy-hat1+angle0" is the syntax the binding system expects (the angle is a condition, not a key/button name)
#4 Updated by skyjake over 9 years ago
- Subject changed from Joystick/Joypad useability issues to Joystick/Joypad usability issues
#5 Updated by skyjake over 9 years ago
- Tags set to Input, UI, TaskBar, Menu
- Subject changed from Joystick/Joypad usability issues to Joystick/pad usability issues
- Category set to User experience
- Target version changed from 1.9.0-beta6 to 1.14
#6 Updated by skyjake over 9 years ago
- Target version changed from 1.14 to 1.15
#7 Updated by skyjake almost 9 years ago
- Target version changed from 1.15 to 42
#8 Updated by skyjake about 8 years ago
- Related to Feature #1886: Use SDL 2 for window management, display modes, color correction, and keyboard/mouse/gamepad input added
#9 Updated by danij almost 8 years ago
- Assignee set to danij
#10 Updated by skyjake almost 8 years ago
- Target version changed from 42 to 2.0 – Home UI & Packages
#11 Updated by rhargrave almost 8 years ago
I would like to add that I currently have to start doomsday with
-nojoy, as I have a custom keyboard controller that doomsday (SDL?) believes is a joystick. If this is enabled, with the default input settings, my player will do nothing but run in circles.
From looking over the code for the controller (whoever wrote it made a real mess, I need to rewrite it), it does not report itself as being anything other than an HID keyboard, although it can report itself as a mouse (for mousekeys).
#12 Updated by skyjake over 7 years ago
- Subject changed from Joystick/pad usability issues to Gamepad usability issues
#13 Updated by skyjake over 7 years ago
- Related to deleted (Feature #1449: Setup bindings/controls via taskbar UI)
#14 Updated by skyjake over 7 years ago
- Related to Feature #2131: Keyboard navigation added
#15 Updated by skyjake over 7 years ago
- Status changed from New to In Progress
#16 Updated by skyjake about 7 years ago
- Target version changed from 2.0 – Home UI & Packages to Input and game controllers
#17 Updated by skyjake over 6 years ago
- Status changed from In Progress to Progressed
#18 Updated by skyjake over 3 years ago
- Assignee deleted (
#19 Updated by jonesmz almost 3 years ago
I tried my Wireless XBox One controller with the 2.2 release, and everything is working great there except there's no way to use the controller to exit the game, and no way to bring up the Doomsday Engine taskbar.
With Doom 2, if you use the menu button, and select quit, with the controller, you're still required to press Y/N on the keyboard to exit.
#20 Updated by skyjake almost 3 years ago
- % Done changed from 55 to 0
there's no way to use the controller to exit the game, and no way to bring up the Doomsday Engine taskbar.
I added #2424 to address the Y/N response. This is easy to fix by adding a couple of bindings.
You can currently go to the Controls menu and bind game controller keys for these manually (in the end of the list).
I'll add a Show Taskbar control to the menu so it can be bound manually, too.
#21 Updated by skyjake almost 3 years ago
- Related to Feature #2424: Confirm/cancel Y/N questions with game controller added