CONTROLLERDEVICEREMOVED .which increments on each unplug |
Joseph Carter
|
Ryan,
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 broken. 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: ---------------- Controller TYPE! ================ 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 normal controllers? - 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, Joseph On Tue, Oct 07, 2014 at 11:40:30AM -0400, Ryan C. Gordon wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|