When you need to support all gamepads.

edited in General
It's a royal pain in the asshat to find mapping info for ALL gamepads on ALL platforms, especially when button IDS and axis indexes change for the same controller on each platform (Note: Every button binding changes on OSX for XB360 controller)). However, I did find something: https://github.com/gabomdq/SDL_GameControllerDB

More specifically: this: https://raw.githubusercontent.com/gabomdq/SDL_GameControllerDB/master/gamecontrollerdb.txt

You can just write a parser for load up on process the axis's to create some kind of working unity implementation... but this is the only actual database which seems to have some reasonable collection of the common controllers in addition to a Platform Specific field. For my own project ill be creating a JSON converted form of the data so It can become easier to use.

Edit: When are we ever going t get an RFC/ISO standard to standardize button mappings for all controllers and devices, something like a "Gamepad Mapping Standard", "Wheel Mapping Standard", etc.... :(
Thanked by 1pieter


  • edited
    If you have some money and are using unity, I can recommend getting rewired from the asset store: https://assetstore.unity.com/packages/tools/utilities/rewired-21676

    It's one of a few purchases I don't regret and probably won't any time soon.
    Thanked by 1Elyaradine
  • For VALA we used InControl, and it worked great. I believe we started on the open source version and later moved to the asset store paid version to get the latest mappings and support.

    Unity should have these directly in the engine IMO, or at least have a package that does it.
    Thanked by 2Denzil SUGBOERIE
  • Denzil said:
    If you have some money and are using unity, I can recommend getting rewired from the asset store.
    I'm struggling to find a new job, so I don't have money for such things. However, I am wary of script based addons from the asset store because alot of developers work with unity's Drop-In script approach ONLY (and code in the asset's folder cannot be referenced by assembly plugins).

    I always put my own code in DLLs, So things like Photon, Postprocessing Stack, (and stupid UNET...grr) and such, force you to switch to a drop-in scripts).

    If Incontrol is available in DLL form, then I would probably try to get it later, but I can just write my own solution and have it integrate into my own framework and not worry about 3rd party stuff cluttering up the assets folder.

    Though the way things are going now I am worried I am never going to get that far...

  • edited
    I always put my own code in DLLs
    Can you explain why? :/ I struggle to see the benefit in general.
  • So I can build exactly when I want to, not every-time a file is saved. Maintaining Reusable Libraries. Less Asset folder clutter... more complicated but cleaner, more tidy project folders.
  • Thanks. That personally seems like not a lot of benefit for the hassle to me, but to each their own I guess! :P
  • +1 InControl. It's made by a South African Expat.
  • I would advocate for rewired - complicated API but does the job very well based on experience porting a large game across several platforms. Unity has made sounds that they will overhaul their input manager based on leanings from asset store input managers, but that will be on "Unity" timescales :D

    I also won't prescribe what any one should do, you need to make your own decisions. If you don't have money you don't have money! But what @roguecode said about open source version of InControl sounds to me like a good tree to bark up.

    Also, these days unity also has the ability to define your dll layouts for drop in scripts. Again, sounds to me like a good compromise if you're blocked from using 3rd party solutions to solved problems ;)
Sign In or Register to comment.