Switch to SDL as the main gamepad input driver

[EIREXE]

Describe the project you are working on

Project Heartbeat, a rhythm game

Describe the problem or limitation you are having in your project

The current input system isn't in the best condition, it fails to account for many exceptions and quirks that other engines have no problems handling (UE for example uses SDL for input).

Some examples include filtering out steam virtual gamepads even when ran from outside steam and better guessing of button bindings for unknown controllers.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Adding support for SDL will not only make Godot work more consistently, but will also decrease the workload on contributors, as SDL already handles those quirks and edge cases and is constantly being updated.

As we would use a very small fraction of the API, any potential breaking changes from upstream can be quickly dealt with.

(before you ask, the SDL controller db we already use isn't enough to overcome these issues).

While it might be tempting to keep godot's NIH solution, years of experience making Project Heartbeat has shown me that this isn't quite as simple as simple as one might think. SDL is supported by Valve and other industry players, so it's a stable and very well behaved system.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

SDL can be initialized with all subsystems but input being disabled.

I have plans to replace Godot's input system to SDL for use in Project Heartbeat soon, so I could take care of the work.

SDL already works on switch, but for platforms where SDL is not available yet we could just continue to use the current input drivers.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No

Is there a reason why this should be core and not an add-on in the asset library?

It's a change to the fundamental input system of the engine

[Calinou]

• Related to Add support for controller-based motion controls (gyroscope, accelerometer, …) #2829.

If we only use SDL for input (as opposed to using it for windowing as well), what does the code size/binary size difference look like?

[EIREXE]

• Related to Add support for controller-based motion controls (gyroscope, accelerometer, …) #2829.

If we only use SDL for input (as opposed to using it for windowing as well), what does the code size/binary size difference look like?

I will have to take a look, my original plan was to simply build SDL into godot, but that's not a good idea, we should preferably use the system's SDL if we can, since that will include all the quirk workarounds and old versions won't need to be recompiled when inevitably the theoretcally shipped version of SDL stops handling future controllers well.

I think my final approach will be to dload it on demand (on linux at least). That way we can also fall back to the old input driver if SDL is not available.

[Calinou]

we should preferably use the system's SDL if we can,

Windows and macOS don't come with SDL, and on Linux, it's not guaranteed to be installed (e.g. on a fresh install without Steam). However, people still want to be able to run Godot from a single binary with no dependencies 🙂

[EIREXE]

we should preferably use the system's SDL if we can,

Windows and macOS don't come with SDL, and on Linux, it's not guaranteed to be installed (e.g. on a fresh install without Steam). However, people still want to be able to run Godot from a single binary with no dependencies 🙂

Of course, hence why I'm saying to at least do this on Linux, Godot already depends on system libraries that it loads on demand for things like audio, so having sdl+a fallback to the old system is the way to go I think

[SysError99]

If anything matters, the library should be integrated into the engine itself because there are more platforms that don't have the library. The size of the engine also comes into play.

If this is only proved to be viable on Linux, then it should instead be a first-party GDExtension.

[EIREXE]

If anything matters, the library should be integrated into the engine itself because there are more platforms that don't have the library. The size of the engine also comes into play.

If this is only proved to be viable on Linux, then it should instead be a first-party GDExtension.

I mean, it's basically a must for godot to behave well on Linux, so I think it should be core. I also am pretty sure GDExtension does not support defining input drivers yet.

[JibbSmart]

• Related to Add support for controller-based motion controls (gyroscope, accelerometer, …) #2829.

If we only use SDL for input (as opposed to using it for windowing as well), what does the code size/binary size difference look like?

Last I checked I think it's about 1.3 MB.

It's very, very good for input for a bunch of reasons already mentioned (industry standard, used by Steam, very wide controller compatibility), but also as the linked issue highlights, it has nice, unified motion sensor support. More and more games are agreeing on some common standards for gyro aiming that are frankly looking much more unified than stick aiming. And its benefits for both the top and bottom end of the experience spectrum and benefits for accessibility are a big deal.

As more devs care about dev for consoles, it'd be great to offer them better support for PlayStation and Switch controllers than they're currently getting while they prototype and pitch their games to platform holders.

[Faless]

Does that means that if SDL is not installed gamepads will not work at all? If so, this seems like a downgrade.

[EIREXE]

Does that means that if SDL is not installed gamepads will not work at all? If so, this seems like a downgrade.

No, gamepads will continue to work, it falls back to the non-SDL input driver if SDL is not available.

[santagada]

I would say using SDL for controllers is a must and the hit from the library size is not that relevant. Video, Audio and Controller are the 3 main things a game engine does, and having limited controller support on a game engine is a big big detractor to its usage, specially now that games even on phones and pc all have good controller support. Also having 2 controller libraries seems bad as SDL is just a superset of things that godot could do.

About the size I think there isn't much dependency on the rest of SDL to the gamecontroller/joysticks part of SDL so it should be somewhat doable to do a static link library with just gamecontroller/joystick that is less than 1.3mb.

I'm hopping this works because I also have some dualsense ideas for games and its pretty sad to have to use Unreal for those were godot would fit much better if it had support.

[offalynne]

As the active maintainer of the Community SDL Gamepad DB, the way Godot is naively reimplementing SDL's gamepad mapping subsystem despite not operating per SDL is a maintainability nightmare.

SDL related projects should not be fielding requests for Godot-specific problems (issues, PRs). This would be solved if Godot correctly leveraged SDL as a dependency.

UE, Unity, GameMaker, etc. etc. have moved to implement SDL for this purpose. If the Godot project wants to go it's own way for gamepad IO, maintainers should commit to that decision and should not, in repurposing SDL's data, be pointing Godot contributors to an SDL community project in a way that degrades it solely for Godot's benefit.

[mubinulhaque]

Plus, Godot relying on SDL means that's one less part of the engine to maintain. I understand that third-party libraries can be tenuous (e.g. Bullet), but SDL is currently being maintained by Valve engineers, who have no interest in steering SDL's development to anything but games.

[Hectate]

I'm going to comment here in Proposals instead of the main engine repo to avoid cluttering up the PR with extra, unrelated commentary. That said, I'm looking forward to having SDL added to Godot, because when we (eventually) get SDL3 available as a stable, official release we can add in support for multiple mice/keyboard detection. For example, https://wiki.libsdl.org/SDL3/SDL_KeyboardEvent shows that we can get an instance id of the keyboard triggering the event.
Given how many proposals there are for detecting stuff like this to enable different local multiplayer setups, it'd be a welcome addition. For posterity, one of the oldest is #19 and many of the others reference it.