[SDL] Improvements to the GameController API

Discussion:

RodrigoCard

2016-12-01 21:17:02 UTC

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.
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.
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.
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 ?
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.
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.
Thoughts on those ?
Regards.

pretty sure SDL_GameController syntax needs some additions,
flipping the axes is the most important of them.

Steelseries MFI controllers seems to have an inverted Y axis on Mac. Fully Mapping to the GameController API is not possible with these controller because of this.

Also the Button Names seems to be a neat idea, anyone working on this?

------------------------
Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com

Ed Phillips

2016-12-19 16:45:36 UTC

Permalink

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

Ed Phillips

2016-12-27 13:52:46 UTC

Permalink

Thanks, Sam!

-- Ed

https://hg.libsdl.org/SDL/rev/5ea5f198879f
-leftx
+leftx
+a0
-a0
a0~
The controllermap test program has been updated to generate the new syntax controller config if it detects the appropriate binding types, and allows you to map a D-Pad as a thumbstick and vice versa.
Please let me know if there are any problems with this!

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org