Xbox controllers require JoyHat events to be tracked on windows

[Daverball]

Edit: I've decided to make this issue about the JoyHat event thing on windows only, if I think of a good way to leverage SDL_GameController without removing features I'll open another issue/pull request.

Controllers are one of the things that are a huge mess, especially across multiple platforms, so using SDL_joystick on its own is often not enough to get consistent behaviour across different gamepads and operating systems.

This is why SDL_GameController is a thing, it works on top of SDL_joystick. It takes community sourced mappings to map all joystick buttons to a generic controller that looks like an xbox gamepad, if an application is launched via Steam, Steam will also automatically pass controller bindings that have been previously setup in big picture mode for the connected gamepads.

I haven't looked into how much code would have to be changed to make this work, but it seems manageable and I will probably get started on a patch to implement this soon, I think the benefits definitely would outweigh the amount of work it is to port it over from pure SDL_joystick to SDL_GameController.

The main motivation for this is, that MKXP already doesn't handle all controller buttons on all operating systems, and there's also differences in the button enumeration across different drivers, Xbox controllers for example will not let you assign the dpad on Windows because it's mapped to a weird thing that's neither a button nor an axis.

[Daverball]

After taking a closer look at it I think I didn't quite grasp the function of SDL_GameController, but I still think there's a lot of benefits to using it.

I guess generally JoyHat (and might as well add JoyBall too) would still have to be added to the event queue, since right now MKXP just assumes everything is either a button or an axis. I guess GameController would kind of conflict with the current way to change, store and load bindings, since that's pretty much what SDL_GameController does.

It still might be worth though, to rip the current way to configure the gamepad out and replace it with SDL_GameController, since that'll work across multiple platforms and already will have many presets that should work out of the box and are more consistent if you ship it with an up to date builtin database.

[Daverball]

Alright I created a patch for JHat support, I decided against JBall after all, it's pretty useless, since nobody ever does anything in rpgmaker that requires mouse input.

SDL_GameController might be leveraged to generate the default bindings instead of entirely replacing the current system for storing the keybinds. What is your opinion on SDL_GameController?

[Ancurio]

What is the point of hats? Aren't they only used in flight simulators?

[Daverball]

The Xbox Dpad counts as a hat on windows, the same goes for any controller using the motionjoy driver which emulates an xbox gamepad.

[Daverball]

Alright I fixed the indentation and the missing pos variable in input.cpp.

[Ancurio]

Oh, I see. The dpad on my controller (a simple playstation like one) reports in as an axis, so I assumed that was the standard.

So, my general thoughts on SDL_GameController.. I don't see the point honestly. The nice thing about SDL_joystick and simple button indices are that they map nicely to the way things work in RMXP, at least it looks to me that way (the settings menu there also only identifies buttons as indices). Secondly, I find the concept of mapping all kinds of controllers to an XBox controller a bit strange. On the surface, you get "consistent" mappings for almost every possible controller, but really, if I'm not using an XBox controller, what are things like "X and Y button" going to tell me? I don't have those letters/symbols on my buttons, and so I'd just have to guess which is which. What if my controller has more buttons than the XBox one? From what it seems they just become useless.

If what you're really looking to fix here is dpad support for XBox controllers and it only involves adding support for hats, then yeah, let's do that.

[Ancurio]

Also, there's no point in replacing the configuration mechanism with SDL_GameController since A) that serves for keyboard bindings as well and B) there is no way to configure the SDL binding database outside of Steam.

[Daverball]

Yeah I can see that replacing the current backend with SDL_GameController might be a bit of a bitch, so I'm fine with just fixing the dpad support.

What might be a good idea though is to use it in an optional way, such that it would try to generate the default bindings through it and fall back to the hard coded one, if it does not have an entry for the controller in its database.

All it does in the end is to allow you to ask what is the jButton, jHat or jAxis with this controller and driver, that has the same position as the X button on an xbox controller. An out of the box experience is really nice for users unfamiliar with the in-engine buttons rpgmaker uses, since it should allow them to generally be able to derive the correct button just from its physical location.

[Daverball]

I've decided to make this issue about the JoyHat event thing on windows only, so it can be merged in sooner rather than later, if I think of a good way to leverage SDL_GameController without removing features I'll open another issue/pull request.

[Ancurio]

Thanks for your contributions.