Hi everyone,
In reference to bug #2181:
https://bugzilla.libsdl.org/show_bug.cgi?id=2181
Sam’s asked me to put together a proposal for improving the mapping
syntax used for GameControllers to cover a few cases that pop up, but
which we cannot really address at present.
TL;DR: uuid(:platform?),name,a1:a1i,dpleft:a4-,dpright:a4+,?
Problem #1:
Retro controllers tend to pretend their digital DPads are analog
sticks. A modern Windows XInput device that implements retro or
arcade-style controls will not provide an analog stick at all, and
instead provides either a 4 or 8 way hat.
SDL’s GameControler interface is modeled on XInput, for better or
worse. My opinion of this tends to vary widely. But it is what
it is, and so we should map those fake analog sticks back to the
digital buttons that they really are.
I have two examples:
Buffalo Classic USB Gamepad for PC
http://is.gd/pbPPdR (Amazon link)
Axis 0 is left/right and 1 is down/up. An EXCELLENT controller. If
you find yourself wanting a retro controller that actually feels like
the original, I can’t recommend this one enough. It costs a little
more than some, but the build quality makes up for it.
Retrolink USB SNES Classic Controller
http://is.gd/JtYLcs (Another Amazon link)
Axis 4/5. Axes 0-3 do not actually exist. The controller feels
light and cheap compared to the original or the Buffalo. Half the
price, but you may find yourself taking it apart out of the box to
remove flashing from the buttons, etc? (Mine was okay out of box.)
I can see two ways to do this syntactically, but I think the sanest
one is this for the Buffalo:
dpup:a1+,dpdown:a1-,dpleft:a0-,dpright:a0+
It wouldn’t be terribly hard to implement this syntax in SDL at all.
Problem #2:
Inverted axes. At least one example noted in the bug report above
has an inverted Y axis. In the bug, devnewton reports that at least
one gamepad produced by Mega World Holdings (he didn’t specify which
one) has the Y axis inverted. He proposed the syntax of a1:a1i for
this. a1:a1- is already proposed for another use above, and a1:a-1
seems clumsy and confusing anyway. I think a1i works fine.
Problem #3:
We can decide to punt on this one.
Currently, SDL’s internal controller database includes #ifdef’s based
on platform?generally Linux, Windows, and Mac. Many other platforms
don’t actually have real GUIDs and for those that do, shrug
At some point, we’re going to need to keep the platform and the GUID
together. We’ve kind of already talked about this on the list, but
we got bogged down into the implementation details of servers and
Steam and extension libraries and ? everything.
We could include a platform in the mapping string either before the
GUID as either windows:341a3608000000000000504944564944 or possibly
341a3608000000000000504944564944:windows (with the latter being
easier to implement in a backward-compatible way?)
We might want to skip this one because of #4. Or we might want to
expressly deal with it because of #4. I’d suggest the latter, and
with the easier to implement syntax. If SDL encounters a UUID string
with not platform, it would simply assume the platform was the
current one.
I do propose keeping the ifdefs for now nonetheless. No need for SDL
to wade through Windows DB entries on Linux, or Darwin entries on
Windows, but still avoids UUID clash on different platforms.
Problem #4:
Sam said I shouldn’t over-think changes to the syntax here. Steam
DOES parse these strings. Of course that means any changes we make
at all are going to affect Steam, so perhaps the best thing to do is
to make those changes now if we’re going to and give Valve as much
lead-time as possible. (This might qualify as over-thinking it?)
Problem #5:
If you’ve got some other edge-case thing that the mapping string
cannot do at present, but you have a need for it, now’s the time to
speak up.
Joseph