[SDL] joystick identification

RodrigoCard cuecax at gmail.com
Tue Feb 14 14:33:48 PST 2012

Yes, there is so much to take in consideration in this mess...
And I really, REALLY hate that different conventions for different countries.
CIRCLE means OK, and X... CANCEL... Why the hell sony swapped the convention outside of their isle? =|
And the Xbox is the opposite, "A" is Green, so it is a OK, and "B" is RED, so... You got it.
The only of the big three doing it right is nintendo.

Anyway, leaving all this into consideration, could be possible to assign multiple names for the same button (but I really wish to not support and spread that "different conventions for the same controller" crap =/... but surely it would be useful for different controllers anyway).

And, If the different conventions for the same controller is really important we could just create another profile for the same gamepad, but I think it will be horrible...

My idea:

Conventions apart,
For example, in the XBOX gamepad, we could assign the A B X Y buttons as BottomFaceButton, RightFaceButton, LeftFaceButton and TopFaceButton, respectively, and also A B buttons as ConfirmButton and CancelButton, respectively.
In the PS3 gamepad we could assign X O [] ^ the same way above and X O as CancelButton and ConfirmButton.

Then the game asking for the ConfirmButton and BottomFaceButton in this example will get different values.

This would be useful when the position matters (say, you, the gamedev, want that the bottom buttons jumps, and the left ones shoots) but still addering to conventions when the position of the button does not really matter (as I said, the confirm/cancel buttons).

What you all think?

Driedfruit wrote:
> This topic had my interest for some time now too, and I was pondering a
> possibility of making a similar library myself. Great discussion so far!
> My 2 cents: 
> - Some conventions are different across countries. For example,
> consider a standard Xbox/PS3 controller with
> Y
> X   B
> A 
> face buttons. As far as I know, "B" would be the default "action"
> button and "Y" would be a default "cancel" button in Japan, unlike,
> say, Europe, where "A" is the default "action" and "B" is the default
> "cancel" button.
> I'm mentioning this, because we should be very careful with labels
> such as "BottomActionButton".
> - Please do not discard non-Xbox/PS3 shaped controllers. There are
> plenty of them, and they all have their good uses. For example, one
> of the gamepads I use is shaped like a Sega Genesis controller, i.e.
> it has 6 "face" buttons in this configuration:
> 3 4 5
> 0 1 2 
> - What are we supposed to do with actual joysticks and *gasp* wheels?
> I guess "guitar" and similar novelty controllers fall into same
> category.
> - The state of gamepad/joysticks support in current games is absolutely
> atrocious, more so in closed-source games. I believe such a library
> would be a great thing, and suggest BSD or zlib license.
> On Tue, 14 Feb 2012 21:10:16 +0100
> Gerry Jo Jellestad <trick at icculus.org> wrote:
> > Den 13. feb. 2012 08:32, skrev Nathan Coulson:
> > 
> > > http://nathancoulson.com/proj_conndb.php has a very quickly thrown
> > > together document on my ideas, and a very basic specification for
> > > this. (Looks like I'll be starting this project a bit earlier then
> > > I was expecting to.  Was planning on getting the game I was going
> > > to use this in working first).  Still, it will be a couple weeks
> > > before I can sit down and start coding this out.
> > > 
> > 
> > I'm not sure about this. Most games don't have SVG rendering 
> > capabilities, and it's not exactly lightweight to add either. Also, 
> > there's simply no way a single SVG image will be able to fit the UI 
> > style of, well, every game. Having an SVG image of controllers would
> > be nice for reference, but I don't think this is something that games 
> > should be expected to use. Also, the exact position of every button 
> > doesn't really matter that much, it's more important with relative 
> > positions than absolutes.
> > 
> > I've actually been thinking about this problem for a while though,
> > and there's one system I think might work: Most gamepads seem to have 
> > somewhat similar layouts. Kind of a W-shape (view with fixed width
> > font):
> > 
> > 	F       G
> > 	|       |
> > 	A   C   E
> > 	 \ / \ /
> > 	  B   D
> > 
> > If each of the letters in that graph could be configured as either an 
> > analog stick, a dpad, a button group, or absent, you'd already be
> > able to cover the vast majority of gamepads out there (A-E on front,
> > F-G on shoulder). Button groups would be shapes, like e.g. a strip of
> > 2 or 3 buttons, two lines of 3 buttons, a diamond shape of 4 buttons,
> > etc. Each shape would have to also define button order, and
> > preferably also short names/symbols and colors for each button for
> > display in in-game config.
> > 
> > With this system, an Xbox360 controller would have analog sticks at A 
> > and D, d-pad at B, a horizontal strip of three buttons at C, a
> > diamond shape of buttons at E, and one digital and one analog trigger
> > at each of F and G (maybe add H and I groups to separate these?). A
> > Playstation style controller would be similar, but with A and B
> > swapped, different button names, and probably different button
> > ordering. A classic NES controller would have a d-pad at A, two
> > buttons at C (select/start), two buttons at E (A/B), and everything
> > else absent. etc.
> > 
> > There could also be a simple library that games can ask for specific, 
> > standard layouts. A game could for example ask for a dpad and two 
> > buttons, or something as close to a SNES style pad as possible,
> > whatever the game needs. If all the game wants is two analog sticks
> > and a button, it could ask for that, too, not caring whether the left
> > analog stick is at position A or B or where the button is. Input
> > could be fed to the library for remapping to the requested layout,
> > and the game could simply work with standard button names, like
> > BUTTON_NES_A or something, with the layout and position then being
> > implicit.
> > 
> > Not really sure about all the details here, but it's an idea.
> > Thoughts?
> > 
> > -g
> > _______________________________________________
> > 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120214/0ba7bfac/attachment-0008.htm>

More information about the SDL mailing list