Added support for SDL_GameController with fallback to default method.

[Daverball]

Alright I've worked a bit on this and rewrote it a couple of times and I think it's in a presentable state now. If it doesn't know the controller it will just fall back to good old SDL_Joystick, and custom bindings in ~/.config/mkxp will always take priority over the SDL_GameController ones.

I've included the gamecontrollerdb.txt sourced from https://github.com/gabomdq/SDL_GameControllerDB/ to be baked into the executable for now but it could be made into a config file that is loaded on startup instead or in addition to the baked in one.

you can pass custom bindings via the SDL_GAMECONTROLLERCONFIG environment variable.

At the moment it won't use the Axis part of SDL_GameController at all, since it really isn't all that helpful.

[Ancurio]

Have you tested this with a controller?

[Daverball]

Yes, I have tested it with my wii u pro controller that isn't part of the database, and then did tests where i put it in the database or where I'd set the environment variable and as far as I can tell it works great.

I also had some people give it a try on windows and it worked for them as well.

[Ancurio]

Huh, that's really curious because they would have to use "start" for confirming actions, something usually the ABXY buttons do.

[Daverball]

Oh the mapping is not set in stone, I just 1:1 the in-engine buttons to controller buttons, so Input::A to the A button and so forth and I bound the two remaining buttons to start and select.

I'm not sure what's a widely accepted use for each in-engine button.

[Ancurio]

The only "standard" buttons in RPG Makers are generally C for confirmation and B for cancellation, everything else is entirely up to the game and could technically be anything.

[Daverball]

I guess most of the bindings are alright then, It's probably less confusing if in-engine buttons mostly correspond to controller buttons.

How about swapping the binds for A and C?

[Ancurio]

I mean, C would have to be the "accept" button, whatever that usually is on XBox. I don't know where A should go because as already pointed out, it could really be anything. The only two buttons that really have a "defined" meaning are C and B, the rest could be anything (ok, L and R should probably be shoulders too, but they are pretty much only used in standard menus and I think 90% of the community doesn't even know they exist).

[Ancurio]

Can you give me an example of a controller that would get a more sane default configuration via the GameController database vs the previous mkxp defaults?

[Daverball]

It's more to me about consistency than just sanity on its own, there's a huge discrepancy between linux and windows already, the face buttons get numbered clockwise by some, anti clockwise by others and then there's the xbox controller on windows numbering which goes A B X Y.

Another big one is that what would be start and select on some controllers is triggers or bumpers on others and vice versa.

The only thing you can kinda depend on is that buttons 0-3 are the face buttons, although you can't depend on any layout and that axis 0 and 1 are the left joystick.

[Ancurio]

Why is windows that important to you btw., since it's an RMVA game it already runs on Windows out of the box doesn't it? Or are you planning on using mkxp for the windows version too?

Another big one is that what would be start and select on some controllers is triggers or bumpers on others and vice versa.

Does your game use Start and Select?

[Daverball]

Yes, the plan is to offer mkxp as an alternative on windows for people that want it, since there have been a lot of complaints about the horrid default bindings and the even more atrocious control bind menu.

It also has the added benefit of a more flexible engine with more configurability for end users. With rmvxa you'd have to add those features with ugly Win32API scripts and you'd still probably have a worse user experience than with mkxp.

The obvious drawback however is the general shakyness of OpenGL on Windows, especially with older drivers, and even moreso with older drivers on intel integrated graphics, which are quite common these days.

The game uses all the engine buttons available for a variety of things, the main issue is, that even if you start on keyboard and then switch to controller the bindings will make no sense to you.

You'd expect whatever space/enter does, to be the A button, and the rest of the keyboard binds are sort of reminiscent of emulator bindings, so the 1:1 from in-engine button to controller button actually makes sense for most buttons, with the exception of A which is bound to shift, and C is actually more of the traditional A button.

I mainly chose start and select as two of the binds because there's quite a few controllers out there without triggers, but most of them have start and select. Also this saves me the complexity of adding the Axis part of SDL_Gamecontroller, since that assumes the trigger to be an axis.

[Daverball]

My main concern is still Linux though, since that's what I'm using myself, and even there there's a lot of benefits to addings this, controller button enumerations aren't exactly unified on linux either.

[hanetzer]

This looks to be interesting... could this be use to get the dpad on my ps4 controller (using ds4drv on Linux) to work? I can bind other buttons/finger triggers/joysticks, however the classic down up left right dpad/pov-hat/whatever-you-call-it seems unbindable as of my last build.

[Ancurio]

@ntzrmtthihu777 what does jstest /dev/input/your_joystick --event report for dpad clicks? Does it still not work with Daverball's recent jhat patch?

[hanetzer]

Not sure off hand, and currently away from my rig, will report in once I'm near it again. Using Github on Android.

[hanetzer]

@Ancurio Ok, back on my rig... trying the above command (should be jstest --event /dev/input/your_joystick btw), and due to the motion sense and accelerometer on the ds4 I can't really see any useful info, scrolls too fast.

[Daverball]

Did you confirm that you still can't assign the dpad with a build off of the latest source? The newest build that Ancurio uploaded should contain the jhat patch as well though.

[hanetzer]

Works out of box as of latest source, and once I switched ds4drv away from hidraw mode. Very nice, and many thanks :)