No indication if controller has xbox or playstation layout (important for A vs X main button) about sdl_gamecontrollerdb HOT 17 CLOSED

You can check the GUID to see if it's the right hardware. FNA trims the GUID for each OS and cleans them to be consistent on multiple platforms, for example:

https://github.com/flibitijibibo/FNA/blob/master/src/SDL2/Input/SDL2_GamePad.cs#L177

https://github.com/flibitijibibo/FNA/wiki/5:-FNA-Extensions#getguidext

The SDL calls you care about are SDL_JoystickGetGUID and possibly SDL_JoystickGetGUIDString.

from sdl_gamecontrollerdb.

That allows me to check for the PS4 controller, but not for all playstation-style layout controllers (does it?). Aren't there various of other vendors like logitech making controllers with playstation button labelling? Wouldn't it kinda make sense to have an entry in the db that identifies those?

E.g. check out this one: http://images.discoazul.com/images/Logitech_Cordless_Precision.jpg or that one: http://cnet2.cbsistatic.com/hub/i/r/2007/03/13/51f6f491-bd7a-4804-b250-1376552264a6/thumbnail/770x433/0b1877136459129428e81d03dedb0e5b/logitech-chillstream-game-pad.jpg - found by a quick google

Or is there some sort of unwritten rule that all new controllers except actual playstation controllers have the xbox layout now?

from sdl_gamecontrollerdb.

Well, what about the Wii U layout? Or the GameCube layout? Or the N64 layout? Or the iOS controller layout that also has different button colors despite it having the same letters? What about all the arcade sticks out there?

The point I'm making is that the actual appearance isn't what SDL cares about, just the physical layout (or in the latter case, just what buttons are reported by something like XInput). The API could have picked any layout naming it wanted, but it'd have no bearing on what it actually looks like to the user running the game.

If you want to officially support a given controller, just support that controller and give it the attention it deserves. If you actually have it and know that it actually works then you should have no problem obtaining its GUID.

from sdl_gamecontrollerdb.

Why not add an entry that gives the layout the common name, and include wii or n64 entries? It doesn't seem such a bad idea to me.. why can't the button appearances be part of the db? It's not that the file would be terribly huge right now.

It could be gradually added by interested people to the existing entries. No need to have it on all of them overnight

from sdl_gamecontrollerdb.

Given that this config file is intended to be ingested by SDL2 and SDL2 doesn't expose any API to get this information, how exactly would this be used or useful?

Aside from manually parsing the config file, which kind of defeats the purpose of it...

from sdl_gamecontrollerdb.

I mean, if you want to try and write that enum in the API, go ahead...

https://hg.libsdl.org/SDL/file/137993bad5c7/include/SDL_gamecontroller.h

What you're going to find is that the only way to do this without breaking API/ABI every release is to store them in strings... pretty much exactly like a GUID. Most of which will all be unique to one piece of hardware anyway - the PS4 layout isn't the same as PS3, which isn't the same as PS2! The problem this solves only relates to that of adapters - those for old controllers, basically. And the odds of anyone having the same adapter for those controllers is zero or less.

from sdl_gamecontrollerdb.

Exactly. It's one of those ideas that sounds great, but fundamentally works against both the design of the SDL2 game controller API (which was intended to mimic the Xinput API and Xbox controller layout) and introduces additional fragility.

In the end, if you're serious about supporting this feature the best thing you can do is explicitly checking known GUIDs.

from sdl_gamecontrollerdb.

I don't get what sort of problem you all have. Doesn't SDL just ignore what it doesn't know from a DB line?

All I recommend is potentially adding something like "layout:wii" to each line of the db. How does that make anything fragile?

Why does parsing the file manually defeat its purpose? Whether SDL actually does something with it is actually something I don't care about. (Which is why I filed this bug with the db, not SDL). See, this project is the only comprehensive open-source DB for gamepad info, so I hoped you'd consider looking a bit beyond your own project and consider adding some more interesting information that would be very useful for a game to display to the user - if you consider SDL to brittle to actually parse and offer it to your own users, that's your own choice.

Therefore my proposal still stands to add this additional field to each line, and I cannot really understand why this would be a problem for anyone - while having this info has obvious benefits (displaying the correct buttons ingame at least for the more well-known layouts the game is aware of).

Also additionally, I don't understand either how adding this as an enum to SDL would be any sort of problem. I don't understand how an additional function to the API/ABI which just adds a new symbol to the dll which older applications would just ignore (right?) would break any sort of binary compatibility, or how it would make anything fragile.

And isn't the gamepad api just there to provide inputs and useful info on gamepads? Is it fundamentally designed to do not a single bit more than XInput, and you could never ever decide to go beyond that? Really? It's just an additional info field. Nobody is forced to make use of it.

from sdl_gamecontrollerdb.

All I recommend is potentially adding something like "layout:wii" to each line of the db. How does that make anything fragile?

Because it means that to use it your application needs to 1) be able to correctly parse out a config file, and 2) correctly interpret an arbitrary configuration string.

The concerns re: fragility come down to - when it gets updated 2 years from now to include "layout:ps5" it is going to be a major problem when it winds up breaking a number of applications that don't know what to do with that. Or, alternatively, what happens when SDL2 adopts the "layout" parameter to mean something else entirely - e.g., left or right handed? Changing the format of the config file will render it incompatible with existing use cases of the file, and anything that manually parses for "layout" is going to suddenly get (presumably) invalid data.

This is what I mean by fragility. Fragility in your code, because it means that there is a great chance that your code isn't going to know how to interpret upstream changes in SDL2 or the configuration without source code changes. Because I am thinking about more than one project here. And trying to support an arbitrary number of controllers with an arbitrary number of layouts is exactly what lead to the legacy joystick API being such a freaking mess.

When you get down to brass tacks, it's much easier and much more robust to test the GUID against a known good whitelist for each controller layout inside your project. Why? Because then you're not dealing with non-standard arbitrary metadata that may or may not make any sense to you given the situation. It also means you can skip the entire parsing step, and if the configuration file format changes (again, the main purpose of this repository is to support SDL2) it isn't going to screw up your project.

And since you're looking for and comparing arbitrary strings, you're effectively doing the exact same thing anyways.

And none of that even addresses my initial question: given the purpose of this is to maintain a configuration that SDL2 can parse and use, why should it add non-standard meta data that you have to parse out manually to use?

I'm not saying that being able to detect a PS4 controller and display appropriate UI is a bad idea. Not at all, it's a good one that many smart people have had before. What I'm saying is that hastily trying to repurpose an existing configuration file to do it is not the way to do it. Especially when it's a logically distinct problem that is better served by creating an explicit API (or, a separate configuration file) to solve it.

from sdl_gamecontrollerdb.

I don't see the problem. For an unknown string, I could just use a default
xbox layout assumption or something. Where is the problem?

And I really don't agree that it's distinct. You have existing information about the physical mapping, the labeling of the buttons seems very connected to me. Yes it's more of a visual quality, but it's still related to the way the controller is physically set up and therefore very related to the information you already have gathered.

Yes one could start a separate db with UIDS and simply "label:wii". But we could also start adding this here. Why encourage even more separate dbs and data to be gathered by people to integrate gamepads nicely? It's enough of a mess already.

On Wed, Jul 1, 2015 at 6:06 PM, Luke Groeninger [email protected]
wrote:

All I recommend is potentially adding something like "layout:wii" to each
line of the db. How does that make anything fragile?

Because it means that to use it your application needs to 1) be able to
correctly parse out a config file, and 2) correctly interpret an
arbitrary configuration string.

The concerns re: fragility come down to - when it gets updated 2 years
from now to include "layout:ps5" it is going to be a major problem when it
winds up breaking a number of applications that don't know what to do with
that. Or, alternatively, what happens when SDL2 adopts the "layout"
parameter to mean something else entirely - e.g., left or right handed?
Changing the format of the config file will render it incompatible with
existing use cases of the file, and anything that manually parses for
"layout" is going to suddenly get (presumably) invalid data.

This is what I mean by fragility. Fragility in your code, because it
means that there is a great chance that your code isn't going to know
how to interpret upstream changes in SDL2 or the configuration without
source code changes. Because I am thinking about more than one project
here. And trying to support an arbitrary number of controllers with an
arbitrary number of layouts is exactly what lead to the legacy joystick API
being such a freaking mess.

When you get down to brass tacks, it's much easier and much more
robust to test the GUID against a known good whitelist for each controller
layout inside your project. Why? Because then you're not dealing with
non-standard arbitrary metadata that may or may not make any sense to you
given the situation. It also means you can skip the entire parsing step,
and if the configuration file format changes (again, the main purpose of
this repository is to support SDL2) it isn't going to screw up your project.

And since you're looking for and comparing arbitrary strings, you're
effectively doing the exact same thing anyways.

And none of that even addresses my initial question: given the purpose of
this is to maintain a configuration that SDL2 can parse and use, why should
it add non-standard meta data that you have to parse out manually to use?

I'm not saying that being able to detect a PS4 controller and display
appropriate UI is a bad idea. Not at all, it's a good one that many smart
people have had before. What I'm saying is that hastily trying to repurpose
an existing configuration file to do it is not the way to do it.
Especially when it's a logically distinct problem that is better served by
creating an explicit API (or, a separate configuration file) to solve it.

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

from sdl_gamecontrollerdb.

You mean like an unknown GUID...?

from sdl_gamecontrollerdb.

I mean like an unknown layout:someunknownnamelikewii9000future which is a new layout the application isn't aware of (yet) because it was introduced to the db later. It was claimed this makes applications fragile, but I'm arguing knowing the layout properly at least SOMETIMES is vastly better than never. (similar to the mapping really) Also it's vastly more useful to have this for controllers in the db than just hardcoding a few PS4 controllers' GUIDs. Isn't that the mess people were doing before the db was started?

from sdl_gamecontrollerdb.

We're going in circles, so I'm just going to say patch it in or don't. Your choice, man.

It's worth noting that this is all completely avoidable in any case if you expose this option to your customers in-game. They could even mod in new layouts if they wanted to! A few bitmaps here and there, maybe the config value is a string pointing to a folder... you get the idea.

from sdl_gamecontrollerdb.

It's worth noting that this is all completely avoidable in any case if you expose this option to your customers in-game. They could even mod in new layouts if they wanted to! A few bitmaps here and there, maybe the config value is a string pointing to a folder... you get the idea.

And then just my game knows it for all the tested controllers, and any other game dev needs to duplicate the work again and we're having the exact same pre-db mess. Sounds great..

from sdl_gamecontrollerdb.

Or you could create an SDL_ library that automates that...

But then again, that would imply taking responsibility for the mappings and defining an explicit API instead of just suggesting that other people redefine their project and add this data to it so you can use it.

Either way, it's up to the maintainer to decide what to do about this.

As for this:

Where is the problem?

The problem is that someone is going to be an idiot and write something like:

// handle all possible configurations
if (!strcmp("xbox",str)) {
// do stuff
} else if (!strcmp("ps4", str)) {
// do other stuff
} else if (!strcmp("ps3", str)) {
// do yet other stuff
}

And it's going to break on an update. You're the one insisting that other people look outside of their own project - how about you stop thinking about your project and start thinking about all the ways that what you're suggesting can be misused or break.

Like I said, they are two distinct things going on here: The SDL mappings, which take an arbitrary axis/button arrangement and map it onto an Xbox controller, and what you're proposing, which at best is mapping an Xbox controller onto another arbitrary controller layout. Just adding an arbitrary string into a config file isn't going to solve that issue, especially since it still leaves you in the exact same place you were when parsing GUIDs: having to whitelist known good identifiers that your code knows how to deal with.

Like I said, i agree with the end goal, just not how you're proposing it gets solved.

Isn't that the mess people were doing before the db was started?

And no, no it was not. It was infinitely worse.

from sdl_gamecontrollerdb.

You should file this in SDL's Bugzilla (bugzilla.libsdl.org)

from sdl_gamecontrollerdb.

BTW, I think adding layout information is a good idea, but the change needs to come from SDL itself.

from sdl_gamecontrollerdb.