Small GameInput joystick backend improvements#15173
Conversation
Nintorch
force-pushed
the
gameinput-improvements
branch
2 times, most recently
from
64d3e4d to
969a2ec
Compare
Nintorch
force-pushed
the
gameinput-improvements
branch
from
969a2ec to
e39c79c
Compare
Nintorch
force-pushed
the
gameinput-improvements
branch
from
e39c79c to
5cf464d
Compare
| CHECK(!SDL_ShouldIgnoreJoystick(vendor, product, version, product_string)); | ||
| CHECK(!SDL_JoystickHandledByAnotherDriver(&SDL_WINDOWS_JoystickDriver, vendor, product, version, product_string)); | ||
|
|
||
| #ifdef SDL_JOYSTICK_GAMEINPUT |
There was a problem hiding this comment.
In theory if GameInput picks up the controller, SDL_JoystickHandledByAnotherDriver() will return true and it won't show up for DirectInput. Is the issue that the DirectInput enumeration happens before the GameInput connection callback?
In general we don't want the logic here, since there are lots of controllers which are supported by DirectInput, but don't show up in GameInput.
There was a problem hiding this comment.
I think so, yes, because after I added this piece of code I couldn't reproduce the issue anymore.
There was a problem hiding this comment.
Okay, well we can't accept this change as-is, because it will break support for lots of other controllers that don't have GameInput support yet.
In the long run I would like to make the drivers dynamically override each other as controllers are detected, but that's a much larger change and some other bandaid would be welcome in the meantime.
My practical solution has been not to use GameInput because it (currently) doesn't provide any advantage over existing backends.
There was a problem hiding this comment.
I removed this change, we can think about the solution for the issue later!
I'm making the PR for Godot to support GameInput to properly support more than 4 XInput controllers, that's more or less the only advantage of GameInput for us, I think.
There was a problem hiding this comment.
Hm, would it be a good idea to ignore all non-gamepad controllers in GameInput backend if DInput/XInput backends are enabled?
There was a problem hiding this comment.
Yep, probably. There is similar logic in the rawinput driver to do this already.
This PR includes small improvements to the GameInput joystick backend: - Device subtypes - Compatibility with DirectInput joystick mappings (if the controller is not a gamepad, i.e. `GAMEINPUT_InternalIsGamepad()` returns `false`) - Fallback to DirectInput/XInput for currently unsupported devices (force feedback ones and the ones that are neither gamepads nor controllers, I'm not sure if that's possible, but maybe racing wheels and other device subtypes would count?)
Nintorch
force-pushed
the
gameinput-improvements
branch
from
5cf464d to
49fe013
Compare
|
Okay, merged for 3.4.4! |
2 participants
Description
While making a PR for Godot to use GameInput ( godotengine/godot#116055 ) I had to make small changes to the SDL GameInput joystick backend for it to not cause regressions in Godot:
GAMEINPUT_InternalIsGamepad()returnsfalseSDL_JOYSTICK_DINPUTandSDL_HAPTIC_DINPUTare defined and enabled via hints)DirectInput controller opening is skipped if it can be handled with GameInput (I observed that sometimes when a DirectInput controller is connected, it first gets recognized by DirectInput, after that it gets recognized by GameInput, and then the DirectInput one is disconnected, resulting in the controller having a player ID of 1 instead of 0)We will need to think of a different solution.SDL_ShouldIgnoreJoystick()just in caseOne more small improvement is the addition of device subtypes, it would be more useful when proper reading of other device subtypes is added, so I can remove this one if it's not desired at the moment.
Please let me know if these changes are good for SDL. :D
Existing Issue(s)
I couldn't find any.