If you lose the device indices, you would lose the enumeration loop
and events will become essentially required. Which IMO is fine, as
all major platforms SDL supports are event-based, most including
events an application MUST respond to or be regarded as fundamentally
I think one of the goals of the ability for events to be optional in
the first place was to allow for extra-lean static builds of SDL on
embedded platforms such as game consoles maybe? In practice, any
such thing SDL still supports has gone to having mandatory event
structures like everything else.
I would not mind seeing a little break with backwards compatibility
even with the event interface in 2.1 a little bit if it meant that
you no longer needed to keep a laundry list of open controllers.
I also wouldn’t mind seeing some API changes in how joysticks and
game controllers rrelate and interoperate a bit to reflect a little
better how these things are used?but that kind of requires that I say
"Arrrgh! Thread hijacked!"
Of course at the time I wanted to discuss that, 2.0 was fresh and
new, the controller DB was only available burned-in and was sparse,
the only real effective configurator tool for end-users to generate
mappings was Steam, and a number of popular retro controllers simply
couldn’t be mapped. Then I got totally distracted by 10^6 different
higher-priority things forcing hobby interests out of the foreground
and other people began dealing with some of the above problems
without me. Haven’t been tracking closely enough to see where things
stand now. So with that in mind, I’ll discus some personal 2.1 goals
for joystick/controller management:----------------
Reflecting the way people actually use these controller devices both
on consoles and on PCs (which aren’t always the same), and giving
devs some hints so that when a controller appears, they have some
idea what to do with it. I imagine mappings would include a major
class (which may affect SDL’s handling) and a delineation hint that
SDL will almost certainly never care about. Might be an unsigned 32
bit value intended to be used as a bit field?
Major classes I envision:
- Basic “modern” controller (non-Nintendo!) Pretty much the status
quo now, though perhaps with the added benefit of knowing that
mappings providing this WILL have certain controls. Two analog
sticks, shoulder buttons, two triggers (may be digital), DPad, four
face buttons, and at least one control button (start/pause/menu).
Hints might include that the triggers are analog and that additional
features beyond the basic definition exist.
Hints for the above: Sony has included accelerometers, now a
touchpad, and on PS2 controllers, analog buttons (though I don’t know
if any PC interface exposes that feature?) Microsoft has chatpads
and sound devices. Apple makes all controls optionally analog,
including the DPad for the greatest WTF in gaming? Easily 99% of
games would never care about the hint, unless there’s something
specific they need.
- Retro controllers and arcade sticks. Why? The modern controllers
do a fine job standing in for the SNES controller unless you have a
Microsoft XBox 360 controller, anyway. The thing is, some of us
like the feel of the older controllers. (FWIW, I recommend Buffalo’s
SNES controller which is on Amazon here: http://goo.gl/K7rJ90 They
also do an original Famicom style controller, but sadly no analogues
to the Genesis/Saturn, N64, or GameCube? The cheap USB copies CAN be
made good enough if you’re willing to mod them?)
Anyway, here the hints become actually more useful. Some useful
hints I see are Arcade/fighter (Genesis/Saturn/SF2 arrangement),
old-school (DPad, only one button), NES, SNES, Genesis 3 button, N64,
GameCube, and some odd birds on a modern system like paddles (two
players, traditionally “one” analog stick and two fire buttons, but
we could use X axis of left and right stick if we decide to?), and
old-school analog (the two paddles as a single analog joystick with
two fire buttons?)
Dance mats(?), perhaps so they can be ignored when looking for
Band instruments. Definitely so they can be ignored when looking
for normal controllers. Notably, there are multiple franchises with
slightly different mappings. We could sort that in mappings I
suppose? Obvious hint is the type of instrument.
Modern Nintendo. May be totally outside of the realm of the game
controller API. I dunno, I don’t own a Wii, shockingly enough. I
figure the Wii U iPad wannabe is off the table for now, but if we can
make the rest work, why not?
That just leaves the stuff that’s not really a gamecontroller model
device in any way (flight control stuff for example) and stuff that
is, but has more than we can express with the current API.
I’d be interested in discussing a way to query features of things
like that and figuring out how to access them. But I don’t have much
to offer about how to go about it now.
Sorry for the novel,
On Tue, Oct 07, 2014 at 11:40:30AM -0400, Ryan C. Gordon wrote:
Is this a bug, or have I misunderstood the ‘event.cdevice.which’ value
We should make this more clear at the API level for SDL 2.1, but
"which" means something different for each of those events:
Sint32 which; /**< The joystick device index for the ADDED
event, instance id for the REMOVED or REMAPPED event */
The idea is when it’s added, you can do
SDL_GameControllerOpen(which)…and several other things that operate
on unopened joystick indexes. This is a number that might get recycled
if we add a stick after one has been removed, to keep
SDL_NumJoysticks()-sized arrays reasonable).
On removal, though, this will be an instance id. This number is unique
and increments on each new joystick the system sees. You can get this
for a controller with:
(maybe for 2.1, we’ll get rid of joystick indexes and use instance ids
SDL mailing list
SDL at lists.libsdl.org