SDL_GameControllerDB VS InputManager

Already planned to be in next update. As long as your controller is recognized by SDL2 and has controller mappings available (or you make your own), it will work.

Godot uses the SDL2 game controller database

Input fixes GameMaker's bugs. In addition to keyboard and mouse fixes, Input uses the engine-agnostic SDL2 remapping system for gamepads. Because SDL2 integrates community contributions made over many years, it's rare to find a device that Input doesn't cover.

The triggers are detected as buttons by default in some software (using d-input mode). Anything using the SDL2 community database shouldn't have this problem. I don't remember if RetroPie uses SDL2 or not. If not you might just need to edit a config file to rebind them to axes instead of buttons. I had to do this with Moonlight and linux Steam before the SDL database was updated.

# taken from line 1451 of https://github.com/gabomdq/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt

I tried setting the SDL_GAMECONTROLLERCONFIG= from SDL game controller DB. Also tried remapping with jscal. Neither worked... and given that other games are recognizing it properly, I am puzzled.

In my last project we used daemon3000/InputManager for rebinding with the old input system. Worked well, but it's been refactored heavily since the version we shipped with (now supports local multiplayer better I think).

If you're using an engine, you should find a plugin that improves their gamepad support to handle gamepad mapping, switching, active detection. There's often free, open source solutions like InputManager for Unity, baton for love2d, etc.

I don't believe so, but i don't have much experience with this input system because i found it unintuitive. If you happen to give up on in too, I'm currently using this much easier alternative: https://github.com/daemon3000/InputManager/wiki/Getting-Started

For this project I am already making a VirtualJoystick object that will clean up inputs to be read by other parts of the program as well as store previous input states to be looked at later to help determine if the player has done things like double tapped a button or done a particular motion input. I will also be using a custom input manager (possibly this guy) to allow players to reassign keys at run time as well as handle some specific needs of the project.

However, this whole system is annoying to work with, doesn't support multiple controllers well, and doesn't support runtime remapping so people have stuff like InputManager to work around it -- by generating input settings for every possible input (like joystick_1_button_3) and creating an API to map strings against those inputs (which can be changed at runtime).

Yeah, I use this open source one for runtime rebinding in the old input system. Although I'm on an older version that assumed single input and have made a bunch of changes.

See this C# example (uses Unity but you could replace InputManager_Unity.cs with an implementation that queries engine api). Or here's one in lua.