writing modern controller support for pc games is a hell !
a ramble, do not read
on windows, once upon a time directinput (or rarely, but where necessary rawinput) was fairly straightforward solution here – you have n axes, buttons, hats, poll them each, provide a default layout and a gamepad configurator, and call it done
then xinput broke the standard (on windows) for unjustifiable reasons and required a second library to support certain inputs on those devices specifically, hence all those joyful xbla-era titles that just throw out everything else. wow ! it’s terrible. xb360ce works fine, but the idea of the thing, and that it is a necessity at all is terrible.
amusingly xbox one pads behave perfectly fine under directinput, which cements that xinput exclusivity was just a terrible time for all involved !
so now we have xinput and directinput, and also steam input, which is theoretically cool; opting all devices into that system would be a nice catch-all if not for that it’s closed-source, officially supports only 6 device types, requires things run under steam, and also is prone to misbehaving itself. while it can’t entirely be relied upon to abstract gamepad implementation (according to the library’s documentation you should just… support all of the above), it shouldn’t be discounted entirely, because people are going to use it regardless !
so now i have to support… directinput, xinput, steam input, with no idea what a directinput pad actually looks like, scuttling any hope of useful button prompts !
apparently the modern solution to this (via SDL) is just mapping everything to xinput-standard and calling it a day. this doesn’t cut it in tyool 2019 because we want console-style button prompts that match the device in-hand, so ps Square and xbox X and nintendo Y are all left-face-button but i need to identify any given pad to label it correctly. first any given controller is reconfigured into something that looks like an xinput device, and then labels for which xbox input corresponds to which button on your actual device needs be identified. a lot of chicken and egg. a lot of torn out hair.
retroarch sort of has this figured out, but their database outside linux is extremely small, and their format is weird.
combing through the sdl community db and praying things are more-or-less usably mapped for my projects has been a project for a couple months now
as a final bonus round, amazon and ebay are flooded with knockoff devices that in many cases aren’t properly identifiable in software at all !
all that to say, if you sympathize with this
and would aid my quest to make my rpg work with like, configurations as ludicrous as your qanba arcade stick on android via otg cable (forgive me @HEAVYVIPER) i would appreciate it. note that this is gamepad support, so flightsticks, rock band controllers, etc need not apply. adapters and receivers for console pads welcome.
-
if your device is weird, or it isn’t already in here:
https://github.com/gabomdq/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt -
test or create a mapping with this (on as many platforms as you can)
SDL2 Gamepad Tool by General Arcade -
and either pr that repo, or if you rightfully found this particular bullet gibberish, post the resulting map here directly, dm it to me, or communicate it however you see fit
-
bask in my eternal gratitude !
i have a separate tool that might be a necessary second-step on windows, also built for android.
my code preliminarily supports weird shit that doesn’t properly report as a controller (like iCade, X-Arcade), so if you have one of these i could probably use your help too
for fun, a selected list of other developers that have taken to similarly panhandling their audience for these device ids: doublefine, yacht club, zero labs …
whitelisting sucks ! this whole endeavor sucks. a guy drove to my girlfriend’s house earlier today with a huge box full of knock-off ps3 controllers, that’s the state of my life right now.
