Support us on Patreon
PayPalSDL 2 (Simple DirectMedia Layer) is the go-to solution for many developers doing cross-platform work, providing an API to hook into audio, keyboard, mouse, joystick, and graphics hardware across various platforms and a big new release is out.
Lots more gamepads are now supported including: 8BitDo FC30 Pro, 8BitDo M30 GamePad, BDA PS4 Fightpad, HORI Fighting Commander, Hyperkin Duke, Hyperkin X91, MOGA XP5-A Plus, NACON GC-400ES, NVIDIA Controller v01.04, PDP Versus Fighting Pad, Razer Raion Fightpad for PS4, Razer Serval, Stadia Controller, SteelSeries Stratus Duo, Victrix Pro Fight Stick for PS4 and the Xbox One Elite Series 2. Support for Nintendo's USB GameCube adapter has returned too, from the crowdfunding campaign Ethan Lee did to get it in after being reverted for a previous release.
That is part of why SDL is so awesome, it can make gamepad input so much less of a hassle for developers because it just supports so many of them. If you want a peek into the vast array of input bindings, have a look at this database file.
With this new release there's also the new functions "SDL_GameControllerTypeForIndex" and "SDL_GameControllerGetType" which allow for developers to easily get the type of gamepad being used and you can override it with "SDL_HINT_GAMECONTROLLERTYPE". Lots more gamepad improvements as well, like functions to get the player index for each pad.
Specifically for Linux two new hints were added with SDL_HINT_VIDEO_X11_WINDOW_VISUALID to allow developers to "specify the visual chosen for new X11 windows" and SDL_HINT_VIDEO_X11_FORCE_EGL to "specify whether X11 should use GLX or EGL by default".
There's also numerous platform improvements for Windows, macOS, iOS/ tvOS and Android. You can see the changelog here.
Find out more about SDL 2 on the official site.
Article taken from GamingOnLinux.com.
As it is, I think any proprietary game not compiled with SDL 2.0.12 for example will never allow the player to make use of those new controllers.
I wonder why specific game controller hardware needs to be added to SDL. I wish the hardware could provide a "standard" description to the computer indicating the buttons, axis, etc. that it supports, and the computer can provide the user a way to map that into game inputs. I think this is something like what Steam can do for games.
As it is, I think any proprietary game not compiled with SDL 2.0.12 for example will never allow the player to make use of those new controllers.
A game compiled for any 2.0.x version of SDL should be able to link automatically with the 2.0.12 .so if you have it on your system (unless of course they linked statically or this version of SDL is not ABI backwards compatible).
I wonder why specific game controller hardware needs to be added to SDL. I wish the hardware could provide a "standard" description to the computer indicating the buttons, axis, etc. that it supports, and the computer can provide the user a way to map that into game inputs. I think this is something like what Steam can do for games.
As it is, I think any proprietary game not compiled with SDL 2.0.12 for example will never allow the player to make use of those new controllers.
A game compiled for any 2.0.x version of SDL should be able to link automatically with the 2.0.12 .so if you have it on your system (unless of course they linked statically or this version of SDL is not ABI backwards compatible).
export SDL_DYNAMIC_API=/path/to/libSDL-2.0.so.0
Ryan Gordon thought about the static linkage issue, and internally SDL2 can actually redirect to a dynamic lib, even if statically compiled into the target program.
Ryan is one clever cookie!
See more from me