After spending some time trying to think of a way to map "stick 0 axis 2" to something more human-readable, I took a minute to run a Google search, and found out that SDL has this nice database of controllers. Such a database allows to determine if "stick 0" is a d-pad, thumb-controller, or something else.

SDL's database relies on SDL-style GUIDs for joysticks. With Allegro, presently there is no way to get such a GUID, or data from which it could be constructed (Allegro 5 API only returns human-readable name of joystick).

So, what I'm thinking about, shouldn't Allegro borrow this functionality from SDL? At least as far a GUID generation, but preferably also loading of SDL-style controller database files and classification of buttons/sticks by user's request.

Some thoughts on possible API:

int al_get_joystick_guid( ALLEGRO_JOYSTICK *joystick, char *buffer, int length ); // Allow user access to GUIDs; maybe use something like ALLEGRO_JOYSTICK_GUID instead of buffer and length?

int al_load_joystick_mapping( const char *filename ); // To load controller database
int al_register_joystick_mapping( const char *mapping_string ); // To register a new mapping string, without loading it from file

bool al_has_mapping_for_joystick( ALLEGRO_JOYSTICK *joystick ); // To check if Allegro has a registered mapping for specified joystick (in case user want some special handling for this case)

ALLEGRO_JOYSTICK_BUTTON al_get_joystick_button_mapping( ALLEGRO_JOYSTICK *joystick, int button ); // To convert button index into more descriptive constant

ALLEGRO_JOYSTICK_STICK al_get_joystick_stick_mapping( ALLEGRO_JOYSTICK *joystick, int stick ); // To convert stick index into more descriptive constant

// ALLEGRO_JOYSTICK_BUTTON and ALLEGRO_JOYSTICK_STICK could be pretty much copied from SDL:
// https://wiki.libsdl.org/SDL_GameControllerButton
// https://wiki.libsdl.org/SDL_GameControllerAxis

Such API would allow Allegro users to:
a) Define default control schemes for games more intelligently (i.e. "'A' button is Fire vs. '0th' button is Fire). This applies more to sticks/axis than to buttons, since they vary wildly (my Logitech F310 uses 2nd stick for D-pad, for heavens sake!).

b) Display control scheme for user more intelligently in tutorial or control definition menu (i.e. draw a picture of D-pad instead of writing godawful things like "Stick 2 Axis 2 Positive"

The second problem could be solved by displaying results from al_get_joystick_button_name and al_get_joystick_stick/axis_name to user, but this is not a very good solution, since these results are platform-dependent and localized by system, and therefore could require font with Unicode characters support when the game itself does not require one.

The first problem, presently, could not be solved at all, unless you want to create a mapping database that depends on reported controller name (you don't).

If developers think this is a good idea, I guess I can work on borrowing SDL implementation of joystick GUID generation and the rest of functionality. It shouldn't be too hard, and shouldn't touch the rest of library too much.

Or maybe I'm missing some alternative solution? If so, please tell me Mapping problem currently stops me from completing nearly-ready game, and I'm itching to do something about it!

This looks like a very good idea.

[edit]

I've mentioned in passing that I want to do an Allegro controller addon that rigidly separates controllers from their actions. Programs expose actions, controllers expose controls, and the addon takes care of linking them based on relationships on a configuration file. So basically, you can load (or create) a map for any controller to control anything (users can at their own on any date when new controllers show up!), and the addon is aware of whatever state you're in. This means that controls can map differently when in a menu system, verses in a round/map/etc, or even different states (driving/walking/flying) in a game. Controls are labelled, and you can have "translators" which sit in-between and convert input data (ala keyboard buttons becomes joystick positions or vice-versa. Multiple letters of text from keyboard can become buttons/axis, and more.).

I don't want to de-rail your thread, but I felt it was pretty related.

Someones finishing an A5 game, for the love of God, people, help this man!

Hm, there is almost always a system such as you describe in any large game. But it might be a bit too high level for Allegro. Then again, if this is an optional addon, why not?

It's been in development for more than 3 years already (and could be done in, like, 3 months if I worked full time, probably), and I really wish I could push it out and start working on something else!

The GUID idea seems reasonable, but the rest not as much (which isn't a problem, since everything builds on the GUID thing). Perhaps the first can go into the core and the rest be an addon?

Yes, addon sounds fine.

Now I thought DirectX stripped out all ID information, hence requiring RawInput for using things like multiple mice and keyboards.

According to this post (regarding Linux):

So my point being, is there an ID we can use to begin with?

[edit]

This post (scroll down) seems to indicate that GUID is "made up" on Linux, but from DirectX on Windows. So if Allegro is going to be cross-platform, these will be things that have to be looked into.

How is input handled in Linux? Is it all from an X server?

I worked on joysticks before and the trouble is that we'd need databases with thousands of devices. Some kind of unique id per joystick type is possible (though not on all platforms), and could be a nice addition to the core, but I'm not sure that I like SDL's ideas about the mappings. So I sorta agree with Siegelord here...

Thousands being the XBox 360 controller and...

I mean does anybody even use other controllers anymore? They're just so... damn perfect. I don't even use my 360, just the controllers! Many Steam/PC games support them, especially games ported from consoles.

As long as users can roll their own, or download maps, that won't be a problem at all (can even have a form of package manager). But this all seems better suited to my controller addon.

Then again, we're adding VOC support which applies to old games using a very specific technology. So I have no idea what criteria fits anymore.

My damn Logitech doesn't have the same mapping as a generice XBox-compatible controller I learned that the hard way today.

Yes, but what's the alternative? Device itself, unfortunately, does not tell us any information about itself. I mean, OK, such database support might not be a good fit for core Allegro, but as an addon, it looks fine, doesn't it?

I remember old EA games were always lugging around a HUGE file with mappings for different devices. Not sure where they hide it now... Maybe MOST devices only use one mapping (XBox360 or DualShock-compatible)? I got that impression from SDL's database where they have a generic mapping for "XInput gamepad".

Interesting info.

The first thing I noticed: There aren't as many items in the database as I expected. As a component of SDL, contributions are more or less limited to SDL users. It would make sense to have a separate repository, upon which SDL, Allegro, and any other library could depend.

If this is going to be an add-on, I hope that's the direction it takes. I would have a few contributions from Japan that aren't in the database, as well. Either way, good luck if you're going to do this. It would be a worthwhile addition (particularly the GUIDs).

const char * al_get_joystick_guid( ALLEGRO_JOYSTICK *joystick ); // <-- Why not this?  Dealing with char buffers is annoying.

Well I think I am in favor of the al_get_joystick_guid function in core, but keep in mind that on some platforms this will be wholly synthetic.

A database to look up those guids in is definitely for an add-on IMO.

I don't mind that the GUID is arbitrary, the point is that it's a GUID. That said, it might be a good idea to future-proof the API by passing a version to the al_get_joystick_guid function, in case we move away from SDL's algorithm (or some cross-framework solution pops up).

Or we just specify that GUIDs aren't really stable, so don't expect them to stay the same permanently?

I think we use Xinput or Xinput2 (for the newer code that supports haptics). I briefly looked at the Xinput2/XI2 protocol spec and I don't see a uuid or a stable id of any kind in it, so I assume it doesn't exist there.

Evdev provides the following info apis on the joystick api:

        /* function      3rd arg  */
  #define JSIOCGAXES  /* get number of axes    char   */
  #define JSIOCGBUTTONS  /* get number of buttons  char   */
  #define JSIOCGVERSION  /* get driver version    int   */
  #define JSIOCGNAME(len) /* get identifier string  char   */
  #define JSIOCSCORR  /* set correction values  &js_corr */
  #define JSIOCGCORR  /* get correction values  &js_corr */

So all you can get there is the axes, buttons, the string identifier (I assume comes directly from the joystick, or if the hw doesn't provide one, the hardware driver provides one...)

So yeah, it doesn't look like theres a uuid at all on linux for input devices. Best you can get it seems is the bus, vendor and device ids.

Vendor and Device IDs seems to be plenty of info for a GUID database, or am I missing something obvious?

It occurs to me that if we could just consider it a part of the API, we could just change it alongside with the minor version... i.e. people will need to check ALLEGRO_VERSION to see what thing to decode.

In general one doesn't decode GUIDs. They are just unique IDs, sometimes specified to not change.

Perhaps decode is the wrong word... I meant map the GUID to the key mappings mentioned in the first post.

Maybe its better to just export the vendor and device ids? those wont change.

That would be great except that IIRC on Android (or other platforms) you can't even get those reliably... :p

Do those platforms have stable ids?

Because guid is a binary buffer. If function is defined that way, outside users won't be able to know its length. We might use a special structure, ALLEGRO_JOYSTICK_GUID or something, to avoid forcing user to deal with buffer allocation, or we may change signature to accept ( ALLEGRO_JOYSTICK *joystick, char **buffer, int *length ), so we could return a pointer to cached guid value and its length.

About guids for various platforms:

On most platforms, SDL uses first 16 bytes of controller's name as a guid. Unless we really want to compile our own incompatible controller database, we are forced to follow their lead.

Actually, I'm not sure if using device name for configuration identifier is a bad idea anywhere besides Windows. Sure, Windows likes to return localized strings instead of useful unique names, but does any other platform do that?

Of course, it would be better to use a hash of controller name instead of first 16 bytes, so things like "GameCompany Pad1" and "GameCompany Pad100500" would have different ids! This seems to be a (potentialy, very bad) flaw in SDL implementation, but again - if we want to use their database, we'll have to go with it Maybe it would be better to submit a patch to SDL correcting this.

I've searched for other open-source controller databases, but it seems nobody compiled a more comprehensive one than SDL.

I completely misinterpreted that. Yes, ID's would be binary.

It definitely would be... though what's the first column?

6d0419c2000000000000504944564944,Logitech F710 Gamepad
88880803000000000000504944564944,PS3 Controller
4c056802000000000000504944564944,PS3 Controller
25090500000000000000504944564944,PS3 DualShock

I came across a thread you might be interested in.

Yeah, I also contributed to that thread there. I proposed a controller "database" in XML (or JSON) format. Actualy this would be quite useful but I guess no one has the time/money to go out there and actually compile such a database. The database could have different fields for SDL and Allegro UUID's too, so no need for compatibility...

Something more rudimentary can be found here:

http://devnewton.bci.im/en/gamepad_db

Ah, a longer list is here, stil quite limited:

https://github.com/gabomdq/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt

I think a tool that would allow users to create/report configurations would populate such database quite quickly if included with large number of games, or with few moderately popular ones. But first, someone need to create such tool, set up things server-side to accept submissions and allow someone to check and moderate them.

This examples are all from Windows portion of file, and under Windows SDL uses a part of DirectX device GUID. Actually, all OSes for which SDL database has entries (Linux, Windows, OS X) have "good" guids.

Thank you, I have already encountered it when searching for controller databases.

That wouldn't be that hard at all. Just a decent amount of work (a weekend, maybe two). Make a client app that validates the users submissions before allowing them to be sent. They go into an "inbox" SQL table. The server has basic duplication detection, and refuses large volumes of spamming. Moderators can sift through them and the ones they approve get moved over into main SQL table.

The biggest issue I see is the moderator not being able to truly validate the input unless he or she has the device. If we get 5, 10, 15 people sending the same values, that's much more reliable though.

The other issue I see is someone actually setting up a server.

Instead of re-inventing the wheel, it might be easier to ask SDL for permission to use their list and re-implement their hash algorithm. We'll also be contributing back to them by populating their list as we see new ones.

Instead of having an automated solution, we could just ship the gamepad config text file (parsed at run-time) with our games, and tell the user they can download updated versions at the Allegro/SDL mirror and replace the file manually.

Well, it's open source, so we don't even need a permission. Allegro borrows a some code from SDL already, from what I see

That does not exclude a special app for extending SDL database, though. It would be useful anyway. But it would have to be cross-platform, preferably for all supported platforms, which makes it somewhat harder.

Also: on platforms where vendor/device ID is unavailable, SDLs way of using first letters of device name is still a bad idea and should probably be fixed.

EDIT: I've looked at things a bit close and noticed a very bad thing. My gamepad is in XInput mode, and is reported as XInput device. All XInput devices should have the same controller configuration ("xinput" entry in SDL's db). However, I'm pretty certain my gamepad does not match this configuration at all! For example, according to SDL's db, A button should have index 10, but in my experience, it have index 0. Also D-Pad is 4 buttons for purposes of SDL's db, but Allegro sees my D-pad as a stick! So maybe my Logitech is a bad XInput device, or Allegro and SDL handle joysticks too differently. In any case, more investigation is needed before any commitment to be made on this plan.

EDIT2: Ah, so Allegro already does some reverse mapping for XInput devices in joyxi_convert_state (wjoyxi.c). So that's why I'm seeing differences in Allegro buttons/sticks indexes and mappings from SDL's db file. That's going to make things harder unless we can change it to coincide with the "xinput" string from SDL, and we probably wouldn't want to, since some older code may already depend on it. One solution would be to create a different default "xinput_allegro" string.

EDIT3: I ported SDL code for generating joystick GUID to Allegro, but encountered another problem: SDL treats "hats" (including D-pads) as buttons, but Allegro treats them as digital sticks. I'm presently somewhat stumped about what to do here.

I'm confused how those things matter for the GUID side of things... wouldn't they be only of issue for decoding the mappings?

@Max, Yes, Allegro maps joysticks differently then SDL does it. That is because in many cases, IMHO, SDL's mapping is wrong. Especially for XInput, I think Allero's maping is better, since I wrote that driver. This means that we'll need our own mapping database. It could be just an .ini file as Alero laready has an excellent .ini parser.

@SiegeLord: you are right. The only thing we need to add in Allegro's core is a al_get_joystick_guid() API. What Max proposes should go into an official or unofficial add-on library.

Oh, I just got a little ahead and started writing an addon too (since I really need it for my purposes right now, and just GUIDs without it would be useless to me).

For now, I'm still considering using SDL database, but do some tricks to make it compatible with Allegro, for the simple reason that building and maintaining another database is beyond scope of my interests. Anyway, when we have GUIDs, everyone could make their own database

We could as a compromise, support both.

Have two lists. The SDL list*, and the Allegro list. The Joystick handler searches for Allegro entries, and failing that, uses an SDL-friendly parser on the SDL list.

That way, we only use their data as a fallback, and things like his controller saying "Xinput" when it should be PS3/4/whatever will would work. But we still have their database for legacy controllers.

*(letter-for-letter, or, write a small tool that converts it, so we won't have to do it by hand every time they update.)

I was going to suggest a tool to convert their mapping to our mapping, but since we build data differently, it likely wouldn't work.

[edited, sorry bro]

It could be handy to have a script that converts the sdl mapping to allegro compatible mapping. That way we can have the best of both worlds

I'm still stuck with hats. They pose a problem. We can only convert them to Allegro terms in runtime, or not at all. For Allegro, "hX" should mean "Xth digital stick" and "aY" "Yth analog stick". Since Allegro keeps all the sticks in the same array, it's not possible to map SDL values to Allegro stick indices until we have ALLEGRO_JOYSTICK (i.e. not during loading of database file), and even then it's not straightforward.

Can we put all digital sticks first followed by the digital ones? So hX would be the X's stick, and aY would by the max(X) + Y's stick?

Well, yes, but we'll have to change the way Allegro fills sticks arrays for all platforms and, preferable, store max(X) for quick reference somewhere. Might as well have a different arrays for digital and analog sticks, then.

I guess I still don't understand the issue. If you map the Allegro axis indicies to descriptive names, it doesn't matter what order they are. Conversely, mapping descriptive names (enum constants in this case) to axis indices is also possible regardless of order. All we have to rely on is that SDL's way of filling out the b's and a's is consistent, so we can interpret the database correctly.

Maybe I'm just slow, but let's talk pseudocode here.

So, we have a structure where mapping information is stored, like this:

struct Mapping
{
   ALLEGRO_CONTROLLER_BUTTON buttons[ MAX_BUTTONS ]; // simple index -> name map
   ALLEGRO_CONTROLLER_AXIS axes[ MAX_AXES ]; // here, troubles begin
};

Then, we read configuration from file:

Then, when user asks us to map index to meaningful name, we do this:

ALLEGRO_CONTROLLER_BUTTON al_get_controller_button( ALLEGRO_JOYSTICK *joy, int button )
{
   Mapping *mapping = _al_find_mapping_for_joystick( joy );
   return mapping->buttons[ button ];
}

ALLEGRO_CONTROLLER_STICK al_get_controller_stick( ALLEGRO_JOYSTICK *joy, int stick )
{
   Mapping *mapping = _al_find_mapping_for_joystick( joy );
   // What do we do here?
}

The best I can come up with, is to store mapping for analogue and digital sticks separately, and do this:

I don't like this, because of linear search for each call to al_get_controller_stick. On the other hand, the cycle is actually pretty small, and this function should not be called too often anyway (ah, this is a dangerous supposition...).

If you see a better way, I'd be glad to see it.

I was thinking just reverse engineering Allegro's and SDL's joystick codes and creating the mapping that way.

But anyway, if your only issues are the ones you mention, then you could just cache the mapping when you invoke one of those functions. I.e.

By the way, what happens to al_get_controller_stick when the joystick doesn't have a mapping?

Also, have you considered having an ALLEGRO_JOYSTICK_MAPPING as a public type? I'm not necessarily saying it's better, but it does fit more nicely into some of these issues.

I didn't thought of caching sticks on the first access, thanks.

ALLEGRO_CONTROLLER_STICK_INVALID is returned. But there is al_has_controller_mapping( ALLEGRO_JOYSTICK *joy ), so you can check if mapping is present for this controller.

Well, it's actually quite a big structure, with both forward and reverse mappings, and now, with cached values for digital/analog sticks... I don't know about exposing it, it seems a bit too complicated for user-accessible type.

EDIT: Surprise! Why does Allegro always think the first stick on DirectInput device always has 3 axes? This leads to a rather funny effect on my Logitech gamepad in ex_joystick_events, and also completely throws off mapping for sticks+axes.

EDIT2: You know what? I'll just make a patch that adds GUIDs for joysticks, and create exactly two mappings for my game, in my own code: one for generic XInput gamepad, and one for generic DirectInput. Everyone else will have to suffer. I don't want to waste any more time on gamepad support right now

Hah, that's a shame... do publish the incomplete addon code though, in case somebody wants to continue your work. It occurs to me that we can add an allegro5.cfg flag for perhaps changing the weird inconsistencies like that.

I've attached the code for it, and also a patch for al_get_joystick_guid (because addon won't work without it). Both addon and patch are not in good shape, i.e. they don't conform to Allegro code standard (because I was writing them with the default Visual Studio settings, with a plan to indent them correctly later) and may contain bad and/or temporary code.

Also of note: one of the worst problems is D-Pad. On some gamepads, it's a stick, and on others it's a set of four buttons, so it's hard to map it consistently (the same goes for triggers). Also, Logitech gamepads has "Mode" button, which helpfully swaps D-Pad and the first analogue stick without telling your program anything (so the D-pad becomes analogue, and the first stick becomes digital). Have fun.

Seriously, though. I never thought that gamepads are so badly messed up. And don't forget flight controllers! Actually, DO forget them, because there is no way to distinguish them from gamepads (lacking a guid database), but you'd need a completely separate set of graphic icons and button/stick names if you want to show them to user. So unless you're writing a flight simulator, I think it's safe to leave them unsupported (I still remember playing Batty (an advanced Arcanoid clone on ZX Spectrum) with a joystick; it was an awful experience, but I was too young to know better and use keyboard).

Oh yes, implementing joystick and haptics (force feedback) drivers for Allegro taught me a thing or two. Game controllers are seriously messed up.

Not only do the different operating systems each map axes and buttons differently, Windows and OSX have several incompatible API's to deal with them (DirectInput, XInput, etc) . And the hardware is all over the place, especially if you take the bewildering variety of joypads, joysticks, steering wheels, flight controllers, train controllers, etc. into consideration.

That's why what SDL is doing is verly simplistic, really. A true game input device database should take all of these details into consideration. Which would be an epic effort, no doubt. We will always have to program a "configure joystick" screen to let the user map their own device as they like it. Just providing an UUID for every joystick and giving some additional support for the "most popular" ones is probably the best you can do.

I looked into FIFA 14 resources and discovered that EA still maintains their huge database of gamepads. Of course, being a soccer sim, they do not offer support for anything BUT gamepads, which simplifies things a little.

I wish I could just grab EA's database and plug it into my game (or SDL, or Allegro), but it would violate copyright law, no doubt Also, it would only be usable on Windows. Also, they use device names for mapping instead of any kind of other IDs.

Are phone number listings copyrighted? I don't know. I mean, if I post a bunch of phone numbers on my page for other people I'm not affiliated with, and you repost them, are you infringing? Now, instead of phone numbers, we're listing numbers of buttons.

But side stepping that, are there any other public domain games/projects that have joystick data? Certainly some other GPL (is Allegro 5 GPL?) projects should exist somewhere.

Actually, a simple search for "Logitech Wingman" (or other gamepad name) in open-source code search engines brings some results, though nothing really comprehensive. Most such databases are hidden inside game codebase, or in game resources, so I don't quite know how to search for them. Maybe if we knew one game or library that have a REALLY good support for various gamepads? Nothing comes to mind right now...

I looked for such a thing too but there doesn't seem to be an in-depth open source database of game controllers out there. A well-structured ini file and some image files with schematics of the device would probably be enough to store the data. But we'd need a lot of people to supply information for their hardware/OS/API combination... Not an easy task, I'd say, but I'd applaud anyone who'd give it a go.

If you made a cross-platform app (binary!) that sucked all the information from people's computers as long as they had the joysticks plugged in, I'm sure many people wouldn't mind running it.

Also, REMEMBER, Gameports are depreciated on many systems (Windows since what... Vista?). So that knocks out the majority of the hardcore gaming market boom.

I've got 360 controllers with the wireless receiver (they can also be USB, supposedily). I've got tons of old gameport joysticks, pedals, and steering wheels I've picked up second-hand but who knows if that matters. Just make sure you can specify a custom entry and I'll be happy, because I plan on doing custom HID work.

Alright, this now lives in a branch in my Allegro5 fork on github: https://github.com/SiegeLord/allegro5/tree/controller_database . This is sort of low priority for me to get around to (compared to other things, not because I don't think this would be a great addition), but eventually I'll try to take another look.