I?m ? hopelessly stuck in the mindset of PlayStation controller mapping
no matter how many months I?ve been trying to understand what is now
commonly an ABXY Xbox thing. SDL has been crowd-sourcing controller
mappings, and even if not directly used now, I wonder if there?s value in:
having controller mappings declare which button faces it adheres to
(xbox, dualshock, ouya etc). It would be the addition of ,face:dualshock
into a mapping line.
exposing that in the API through something like
SDL_GameControllerGetFascia() that just returns it as a string and they
can happily cache that until some hotplugging occurs. For a missing
face: entry, it will assume xbox because Microsoft.
and probably for a future project
3) shipping reusable button images for these faces.
Yes, I know many other controllers exist and had ABXY before Xbox. But
there?s the layout, colour coding and behaviours that it brings. Unsure
if this should mean each platform gets a name (say, gamecube) but that?s
up for discussion.
Posting now because it was mentioned on twitter as a future feature for
FNA [1] and there may be some use in collecting the data(1) here even if
(2) or (3) don?t get met.
Considering a GamePad extension in FNA to get the device name. Would
be useful if a game wanted to use DualShock icons for those controllers–
John ?[Beta]? Drinkwater | @John_Drinkwater
I don’t think so! In fact, I suggested pretty much the same thing on
this mailinglist last year =). Noone seemed to notice though, so
hopefully it’ll get more attention this time
(I’d say “labels” instead of “face”/“fascia”, because it’d label
shoulders etc too, but that’s just a detail. Also, returning an enum
value might be nicer than a string, since the string values must be
standard to be of any use anyway*)
As for point 3, I think standard button images is maybe a bit outside
the scope of SDL. Most games would use custom images to fit their
respective size and style requirements anyway.
-g
Strings would let you use a db w/support for more controller kinds
than what’s provided by an older SDL, but more kinds in the db wouldn’t
be of any use if the game itself didn’t support it… so why not just
link to the newer SDL in that case?
Out of curiosity, what is the benefit of rolling this into SDL?>From the perspective of someone implementing support for this already, it doesn?t seem like it would make it any easier vs. just explicitly comparing device strings.
Out of curiosity, what is the benefit of rolling this into SDL?
Having it in the mappings would let this other project more-correctly
map to all known devices with those labels rather than as suggested below?
Some games using SDL2 ship with dualshock assets already and use config
edits (
) or in?game prompts (like The Swapper) and the purpose would be to
streamline that?
Both of those methods break around controller hotplugging anyway as a
newly attached controller might not be using the same labels.
From the perspective of someone implementing support for this already,
it doesn?t seem like it would make it any easier vs. just explicitly
comparing device strings.
That wouldn?t scale around the 3rd party devices which aren?t in the
database and that don?t share a common device string.
If someone has an unknown device, and they set their own env var to push
support into games they play, it would not get their preferred/device
button labels.
Having some metadata would better support this behaviour.