Re: Improvements to the GameController API

On Thu, 1 Dec 2016, RodrigoCard wrote:

>
>                                           Sentmoraap wrote:
> 
> 
> 
> 
>
>                                                Hello,
> 
> the gamepad API is far better than a "i have X buttons and Y axes" API and a gamepad-specific API for
>  having good default mappings and consistent mappings from one gamepad to another and from one OS to
>                                               another.
>
>                                Some issues has already been addressed:
>          http://sdl.5483.n7.nabble.com/Extending-GameController-mapping-syntax-td38149.html
>                           https://bugzilla.libsdl.org/show_bug.cgi?id=2181
>                           https://github.com/cxong/SDL_JoystickButtonNames
>
>    There is already someone assigned to this bugzilla, but I am willing to contribute if there are
>                                improvements which everyone agrees to.
>                 I also would like to have more informations on some design decisions.
> 
> 
> The current syntax does not allow mapping half an axis. On some controller the D-Pad is exposed as 2
>                          axes, and the triggers are halves of the same axis.
>                              Sometimes you also need to invert an axis.
>      There is a proposal to have a0+, a0- for halves and a0i (or !a0, ~a0) for an inverted axis.
>                            This issue is addressed in the first two links.
>           There is someone assigned, but I have not seen anything new since november 2013.

The half-axis thing does matter to me.  So far I've handled that with my 
mapping GUI, and it figures out things like the MOMO Racing Wheel pedals 
in split-mode vs. combined mode.

Also, it's important (for a racing game, at least) to know whether the 
steering axis is a racing wheel or equivalent with high-precision (i.e. 
you can use 1-to-1 input values for in-game steering) or an analog 
thumbstick or such (i.e. you need to use a response curve for input to 
compensate for lack of near-centered accuracy).

> They also discuss about dead zones. I am not sure if handling deadzones fits with the purpose of SDL2
>                              GameController. The game could handle this.

This is a similar issue to the "precision" of the input axis.

I think the Steam controller configuration mentality will push all of this 
to their config GUI - it will likely allow you to set dead zone, response, 
damping, adjust the centering if needed, etc.  They can get away with this 
because the Steam API will intercept input and then translate that int 
"actions" and "readings" for the game code.  This has the potential to 
greatly simplify programming input stuff on the game side, at the expense 
of an extra configuration file ("actions") and maybe some default configs 
based on button layout for popular devices.

> We have some mappings defined in SDL_gamecontrollerdb.h, and the project SDL2 game controller. Do we
>   need SDL_gamecontrollerdb.h, can't we just use a text file, provided with the game, which will be
>                                    easily updatable by the user ?

Yeah, I was wondering why there are configs in a header.  I'm okay with 
that for things like the variants of the Xpads.

>    For now the controllers are identified by GUID, which is an OS-dependent number. So we have to
> provide mappings for every supported platform. The GUID contains the vendor id and the device id. We
>    could provide mappings with the vendor id and the device id instead, assuming the OSes sees the
>  buttons and the axes in the same order. We just have to take into account OS differences (d-pad as
>       axes on Linux etc...). We could provide platform-specific mappings only when it's needed.

The Xpad GUID - that gives us know way to tell what ACTUAL controller is 
being used, and therefore, no way to differentiate between controllers 
except via the "... #1", "... #2" in the contrived device names returned 
by SDL.  That might be a bit backwards, and confusing to the user.  Some 
Xpad devices don't have the 4-segment LED so you can't tell by looking 
which one is "... #2".

>              Linux has an API which provides mappings in a way similar to SDL2 Gamepad.
>                      https://www.kernel.org/doc/Documentation/input/gamepad.txt
>    We could use it to provide default mappings when it's not provided by the database. We have to
>   recognize if the mappings complies with the new API. If all buttons and axes used are contiguous,
>            it's likely that the driver did not map events according to the gamepad layout.
>
>   About the labels. For now we can show the Xbox equivalent, show generic button names, or both. We
>  could add a field "labels:something", which could be generic, xbox, playstation, etc.... This field
>    will just be ignored by the current version. We could just have a fixed set or another database
>                               containing the name and color of buttons.

I would vote to have an additional set of mappings that map the 
button/axis/hat/etc. inputs to the real names for non-Xpad devices, maybe 
even with simple glyphs.

The existing "Xpad mappings for every device" are already useful for the 
"make this controller work like an Xpad" purpose.

Side note: There was talk in the article I linked in my previous message 
about how there is a possibility that the Steam client mapping feature 
might be separated out from the Steam client so it would be generally 
useful for any client, or potentially for games to use directly without 
the client.  That is an interesting prospect... not sure it will ever 
happen tho'.  It would be interesting for SDL to provide a similar 
action-mapping system with a GUI so the devs could set up a default config 
and users would have a standard way to alter configs for their own 
devices.

 	Ed