Long-term GameController DB thoughts?

T_Joseph_Carter · October 16, 2013, 4:39pm

Has anyone given thought to a more long-term way to handle the
current GameController DB? The problems with the current setup are
obvious:

Can’t possibly include every controller out there
Waiting for a new SDL release for a DB update is silly
Unclear how to submit updates
Recompiling SDL for each update is not realistic

I think we’re not going to get anywhere with it unless we put a file
somewhere. Actually on modern OSes, that’d be TWO files. One coming
with the library, and the other belonging to the user. Instead of
ifdefs, we could simply include an OS token with the GUID in the
file.

A configuration tool (like the one I intend to write at some point)
would need a means to write a newly configured controller’s data to
the user’s database. I’ve got some other ideas about managing such a
database file without waiting for a new SDL release, but that can
wait.

Speaking of updates, here’s one for Linux I hand-cobbled:

030000006d04000016c2000010010000,Logitech Dual Action,a:b1,b:b2,x:b0,y:b3,leftshoulder:b4,rightshoulder:b5,lefttrigger:b6,righttrigger:b7,back:b8,start:b9,leftstick:b10,rightstick:b11,leftx:a0,lefty:a1,rightx:a2,righty:a3,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2

I’d offer one for Windows if I had a build system. I download did a
couple of “automatic setup of everything” packages for mingw-w64 and
MSYS, but the result was less than automatic and the instructions for
the one make assumptions about the other that aren’t true. If
someone is willing to provide a couple of pointers to setting these
up together, I’d be willing to write a basic how-to guide. (I’m even
willing to throw in setting up Code::Blocks or Eclipse into the
documentation, though I’d probably never use either myself.)

Lemme know and we can take it off list.

Joseph

David_Ludwig · October 16, 2013, 7:43pm

Joseph Carter wrote:

Recompiling SDL for each update is not realistic

Can’t game controller mappings already be added at runtime via the public SDL function, SDL_GameControllerAddMapping? This seems like a means of loading new controllers without having to recompile SDL, although my knowledge of the new Game Controller API is somewhat limited, and I might be missing something key here.

Cheers,
– David L.

Sik_the_hedgehog · October 16, 2013, 8:36pm

Yeah, that if I recall correctly you have to parse the syntax by hand.

Also not sure if two files will be enough. Even better would be to
have an arbitrary number of files and then put together the
controllers from all of them to make a big list.

JonnyD · October 16, 2013, 9:29pm

That sounds like a job for an extension library to do that.

Jonny DOn Wed, Oct 16, 2013 at 4:36 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

Yeah, that if I recall correctly you have to parse the syntax by hand.

Also not sure if two files will be enough. Even better would be to
have an arbitrary number of files and then put together the
controllers from all of them to make a big list.

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

T_Joseph_Carter · October 16, 2013, 9:33pm

Yes, you can, for a single controller at a time, if you know its
mapping. Which means either the user has to somehow pass the mapping
to the game (currently bypasses SDL_GameControllerAddMapping, but
involves setting an obscure environment variable) or game-specific
GameController configs which kind of defeats the whole point of the
"just works" GameController API.

What we have no works for Steam, and that’s about it.

JosephOn Wed, Oct 16, 2013 at 07:43:32PM +0000, DLudwig wrote:

Joseph Carter wrote:

Recompiling SDL for each update is not realistic

Can’t game controller mappings already be added at runtime via the public SDL function, SDL_GameControllerAddMapping? This seems like a means of loading new controllers without having to recompile SDL, although my knowledge of the new Game Controller API is somewhat limited, and I might be missing something key here.

Cheers,
– David L.

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

Jared_Maddox · October 17, 2013, 4:03am

Message-ID:
<CA+DSiHbDQHygPJN+E7NV6tOjb+VMBN5bePKjgz=r=hSiWmrfFQ at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

That sounds like a job for an extension library to do that.

Jonny D

Yeah, that if I recall correctly you have to parse the syntax by hand.

Also not sure if two files will be enough. Even better would be to
have an arbitrary number of files and then put together the
controllers from all of them to make a big list.

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

Yeah, an extension library sounds about right. If SDL was to provide
it directly then it would require a choice between writing a database
engine of some sort into SDL, or grabbing an already made database
engine (e.g. SQLite), NEITHER of which strikes me as desirable for SDL
itself, but for an extension library who cares? If you don’t like it,
then just don’t add it to your program, much less contentious then
trying to shovel in a full-blown database library.

Here’s the question though: are all of the functions available? We can
get at the device ids that we need, right (I sort-of remember being
able to get at some, but I haven’t looked at that API for a while
now)?> Date: Wed, 16 Oct 2013 17:29:06 -0400

From: Jonathan Dearborn
To: SDL Development List
Subject: Re: [SDL] Long-term GameController DB thoughts?
On Wed, Oct 16, 2013 at 4:36 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

T_Joseph_Carter · October 17, 2013, 4:44am

I don’t see why it needs an engine. The current way it’s done is a
flat list of strings, and I cannot imagine that becoming unreasonable
to manage in any reasonable near term.

An extension library is pretty much guaranteed to ensure that the
"just works" aspect never does. What’s the point of the "just works"
API if it doesn’t unless you go import some extra library and
database? The entire GameController interface could have been an
extension library. Should have been, by this logic. But it’s not,
and for good reason: Because something you can use that just works is
worth adding code to SDL.

I could implement a working solution that does what I suggest in
about three functions.

JosephOn Wed, Oct 16, 2013 at 11:03:32PM -0500, Jared Maddox wrote:

Yeah, an extension library sounds about right. If SDL was to provide
it directly then it would require a choice between writing a database
engine of some sort into SDL, or grabbing an already made database
engine (e.g. SQLite), NEITHER of which strikes me as desirable for SDL
itself, but for an extension library who cares? If you don’t like it,
then just don’t add it to your program, much less contentious then
trying to shovel in a full-blown database library.

Here’s the question though: are all of the functions available? We can
get at the device ids that we need, right (I sort-of remember being
able to get at some, but I haven’t looked at that API for a while
now)?

Edward_Rudd · October 17, 2013, 12:49pm

For all of the Doublefine linux+mac ports I created a simple file loader method that reads all lines of a file and stuffs them in the SDL_GameControllerAddMapping method (It’s the reason I wrote and added the method to SDL2).

And, as for Steam… the steam client is supposed to be exporting the users BigPictureMode controller config in the “obscure env var” so SDL2 games will pick it up…

And I’ve thought about figuring a way to create some system / user DB/flat text file system and build it in. And even had a partial GUI I started working on to manage it… However there are issues that start to arise with that… Such as Sandboxing on OS X, where the application will now no longer have access to that global space for the users configurations.

Probably the “cleanest” approach would be a simple add-on library that fetches from some trusted well-known site the controller entries for the plugged controllers, but not without other drawbacks… And fetching the GUIDs is quite easy via the SDL_Joystick API (no need to even open the controller).On Oct 16, 2013, at 17:33 , T. Joseph Carter wrote:

Yes, you can, for a single controller at a time, if you know its mapping. Which means either the user has to somehow pass the mapping to the game (currently bypasses SDL_GameControllerAddMapping, but involves setting an obscure environment variable) or game-specific GameController configs which kind of defeats the whole point of the “just works” GameController API.

What we have no works for Steam, and that’s about it.

Joseph

On Wed, Oct 16, 2013 at 07:43:32PM +0000, DLudwig wrote:

Joseph Carter wrote:

Recompiling SDL for each update is not realistic

Can’t game controller mappings already be added at runtime via the public SDL function, SDL_GameControllerAddMapping? This seems like a means of loading new controllers without having to recompile SDL, although my knowledge of the new Game Controller API is somewhat limited, and I might be missing something key here.

Cheers,
– David L.

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

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

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

icculus · October 17, 2013, 2:24pm

A configuration tool (like the one I intend to write at some point)
would need a means to write a newly configured controller’s data to the
user’s database. I’ve got some other ideas about managing such a
database file without waiting for a new SDL release, but that can wait.

I intended to focus on this very thing at one point, before I discovered
that Steam Big Picture Mode is already doing this work: it has a UI for
mapping your controller, and that information is getting crowd-sourced.
It would be hard to build a better database outside of that.

Popular sticks are getting added to SDL’s hardcoded list from there. I’m
not against having a simple database (or even just a text file) for
this, but I suspect the list of XInput-like devices is pretty darned
small at the moment.

–ryan.

icculus · October 17, 2013, 2:27pm

I could implement a working solution that does what I suggest in about
three functions.

If you wanted to get hardcore, you keep the list of controller mappings
on a webserver and have it download it occasionally to get new mappings
(but this definitely puts it into the “extension library” area and not
core SDL).

–ryan.

Stefanos_A · October 17, 2013, 2:40pm

Yes, but how would you update that list of mappings in the first place? Is
it somehow possible to retrieve the list from Steam, even if your app is
not distributed there?

As long as there is a documented process on how to get an up-to-date list
of mappings, there is no real point in adding any extra code inside SDL
itself. We already have all necessary components to load this list, we just
need a way to get the list in the first place!

icculus · October 17, 2013, 2:43pm

Yes, but how would you update that list of mappings in the first place?
Is it somehow possible to retrieve the list from Steam, even if your app
is not distributed there?

We happen to know some people at Valve, I think we could arrange
something here.

–ryan.

Stefanos_A · October 17, 2013, 2:45pm

Sounds like a plan

2013/10/17 Ryan C. Gordon >

Yes, but how would you update that list of mappings in the first place?

Is it somehow possible to retrieve the list from Steam, even if your app
is not distributed there?

We happen to know some people at Valve, I think we could arrange something
here.

–ryan.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sik_the_hedgehog · October 17, 2013, 3:07pm

It would really help if controller themselves came with the mappings,
but we all know that isn’t going to happen (pretty much all cheap
controllers are guaranteed to not come with them, and those are the
ones that tend to vary the most).

T_Joseph_Carter · October 17, 2013, 3:28pm

Funny you should mention that, Ryan.

I am currently rewriting testgamecontroller. The current code is a
simple mod of testjoystick, which mostly just puts SOMETHING on
screen when you manipulate the controls and spews information about
what exactly to stdout.

The new program gives you a decent visualization of the controller
and an on-screen display of the enums, and it will manage device
insertion/removal and will not require command line fiddling to do
most of its functions. Visualization inspired by the tattiebogle
driver for OS X:

http://www.tattiebogle.net/index.php/ProjectRoot/Xbox360Controller/OsxDriver

Had to alter it because Sam points out MS claims to own the RGBY
colors mapped to ABXY. Y’know because they invented that whole
different colored button thing. facepalm

But that’s project #1.

Project #2 is a GameController config tool, so that you don’t need to
fire up Steam (which Valve hasn’t released for Raspberry Pi, etc.) or
cobbling a mapping together by hand like I did the other day. If SDL
loads its GameController DB from an external file instead of a
compiled-in string, project #2 could write to at least the user’s
mapping. That’d put us closer to “just works”.

Of course the implementation of this thing is as an extension library
along with a reference implementation.

Project #3 is planned to be a web script. It’ll probably use a DB
engine for the sake of concurrency. The script will let the config
extension library query the server for a GUID. Depending on what we
want to do, it could also submit a configured controller (with the
user’s permission) once they’re done.

Duplicate GUIDs on the same platform:

if submitted GUID is not found in DB:
add the submitted mapping string to the DB
return success (entry added)
else:
if submitted control mappings match DB entry for submitted GUID:
# Name may differ as Logitech Dual Action and F-310 on Mac
# which share GUID and mapping, but not name
return success (entry already in DB)
else:
# Mappings differ for single GUID
return failure (entry already in DB)

If this returns failure, the config tool can still add it to the
controller DB file on your system, or it could perhaps send feedback
(along with the mapping) to someone. That way if someone maps an
actual SNES controller with A/B/X/Y in SNES order and someone else
maps it with A/B/X/Y in XBox order, both users get what they want.
The person maintaining the DB gets to decide which rendition is
"correct" (I’d argue the XBox mapping, even if it reverses the
layout.)

?at some point beyond project #1, I want to get a few other people
involved, mainly so I’ll have time to go and write more docs.

JosephOn Thu, Oct 17, 2013 at 10:27:59AM -0400, Ryan C. Gordon wrote:

I could implement a working solution that does what I suggest in about
three functions.

If you wanted to get hardcore, you keep the list of controller
mappings on a webserver and have it download it occasionally to get
new mappings (but this definitely puts it into the “extension
library” area and not core SDL).

T_Joseph_Carter · October 17, 2013, 3:31pm

That’s kind of going to be a moot point on Windows because every
modern controller going forward is going to provide XInput support.
SDL uses one mapping for XInput: The one provided by the controller
that emulates the XBox 360.

I doubt the hardware makers care much about anything but Windows,
sadly. Otherwise, I’d say you were right.

JosephOn Thu, Oct 17, 2013 at 12:07:53PM -0300, Sik the hedgehog wrote:

It would really help if controller themselves came with the mappings,
but we all know that isn’t going to happen (pretty much all cheap
controllers are guaranteed to not come with them, and those are the
ones that tend to vary the most).

mogumbo · October 17, 2013, 9:07pm

A couple thoughts here:

Would it be unreasonable to have a fallback so that
SDL_gamecontroller can open a stick even if no mapping is present. You
could look at a flag to see if a mapping had been loaded. If yes, you
can use the mapping. If no, you can just look at the button and axis
number like you would with SDL_joystick. The main advantage here would
be to only have to use one of SDL_gamecontroller or SDL_joystick but
not both. There are probably hangups with this idea I’m not thinking
of, but it’s worth suggesting.
Hadn’t even thought about the SNES mapping until now. Would it make
more sense to label button inputs with something like top, bottom,
left, and right instead of ABXY? This would be a little more future
proof in case MS decides to change their labels. Also, I keep hoping
against hope the Xbox controllers will go out of fashion since their
thumb sticks are relatively low quality.–
Terry Welsh
www.reallyslick.com

Message: 4
Date: Thu, 17 Oct 2013 08:28:51 -0700
From: “T. Joseph Carter”
To: SDL Development List
Subject: Re: [SDL] Long-term GameController DB thoughts?
Message-ID: <20131017152851.GB5437 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On Thu, Oct 17, 2013 at 10:27:59AM -0400, Ryan C. Gordon wrote:

I could implement a working solution that does what I suggest in about
three functions.

If you wanted to get hardcore, you keep the list of controller
mappings on a webserver and have it download it occasionally to get
new mappings (but this definitely puts it into the “extension
library” area and not core SDL).

Funny you should mention that, Ryan.

I am currently rewriting testgamecontroller. The current code is a
simple mod of testjoystick, which mostly just puts SOMETHING on
screen when you manipulate the controls and spews information about
what exactly to stdout.

The new program gives you a decent visualization of the controller
and an on-screen display of the enums, and it will manage device
insertion/removal and will not require command line fiddling to do
most of its functions. Visualization inspired by the tattiebogle
driver for OS X:

http://www.tattiebogle.net/index.php/ProjectRoot/Xbox360Controller/OsxDriver

Had to alter it because Sam points out MS claims to own the RGBY
colors mapped to ABXY. Y’know because they invented that whole
different colored button thing. facepalm

But that’s project #1.

Project #2 is a GameController config tool, so that you don’t need to
fire up Steam (which Valve hasn’t released for Raspberry Pi, etc.) or
cobbling a mapping together by hand like I did the other day. If SDL
loads its GameController DB from an external file instead of a
compiled-in string, project #2 could write to at least the user’s
mapping. That’d put us closer to “just works”.

Of course the implementation of this thing is as an extension library
along with a reference implementation.

Project #3 is planned to be a web script. It’ll probably use a DB
engine for the sake of concurrency. The script will let the config
extension library query the server for a GUID. Depending on what we
want to do, it could also submit a configured controller (with the
user’s permission) once they’re done.

Duplicate GUIDs on the same platform:

if submitted GUID is not found in DB:
add the submitted mapping string to the DB
return success (entry added)
else:
if submitted control mappings match DB entry for submitted GUID:
# Name may differ as Logitech Dual Action and F-310 on Mac
# which share GUID and mapping, but not name
return success (entry already in DB)
else:
# Mappings differ for single GUID
return failure (entry already in DB)

If this returns failure, the config tool can still add it to the
controller DB file on your system, or it could perhaps send feedback
(along with the mapping) to someone. That way if someone maps an
actual SNES controller with A/B/X/Y in SNES order and someone else
maps it with A/B/X/Y in XBox order, both users get what they want.
The person maintaining the DB gets to decide which rendition is
"correct" (I’d argue the XBox mapping, even if it reverses the
layout.)

?at some point beyond project #1, I want to get a few other people
involved, mainly so I’ll have time to go and write more docs.

Joseph