[Feature Request] Having support for Windows Gaming Input API for joypads

[Gagert]

Description

In the Windows PC ecosystem we're pretty used to two different API's when it comes to handling game controllers; DirectInput and Xinput.

Xinput being the successor to dinput and the one that fully utilizes both the Xbox 360- and Xbox One gamepads still has its limits. One of them is that xinput is as far as I know Windows only, and the other one that it supports a maximum of 4 gamepads connected at once (as stated in this Wikipedia article). Thereby if you play games on PC with the Xbox Wireless Adapter on a Windows 10 PC, an adapter that supports 8 players simultaneously through its wireless connection, you have to select dinput in the games that supports more than 4 players if more than 4 people are going to play at the same time.

I don't know much about the Gamepad API as of now, I suppose this article shines some light to its origins. This API has supposedly made it possible to play games through the web-browser with gamepads, and this API supports most modern web-browsers. I hope this API doesn't have the limit of max 4 gamepads connected at once, that it has all the benefits from xinput and dinput combined & more.

Edit: Looks like I have mixed the Windows Gaming Input API with the Gamepad API for web-browsers; with the first one I suppose are meant to be a successor to the xinput API in the long run. Maybe support for the Windows Gamepad Input API could have its benefits?

[andres-asm]

It's browser only indeed, what would be the point? why not just use dinput for everything? it works for any number of pads you may have.

[Gagert]

Aah; if this is browsers only, I guess there's no point in that.

I thought that maybe the Gamepad API was some kind of html5 thing, meaning that it wasn't restricted to just web-browsers and such, but it could be used in any kind of computer application. The benefit of an API such as this could be support for more than 4 gamepads at once, being a modern API (dinput doesn't support all the buttons on the Xbox gamepads) and not being restricted to just Windows only. In my case my setup of RetroArch (running Windows 10) works fine for my use; I use xinput for games that supports up to 4 players and dinput for games exceeding 4 players, but it would be nice if there was an API that made both xinput and dinput obsolete, since they both have their shortcomings.

I thought the Gamepad API was the natural successor to xinpput and dinput, but if this is only restricted to browsers I guess not.

[andres-asm]

You mean the home button? that would be the only one that doesn't

[Gagert]

Wasn't there issues with the right- and left triggers on the Xbox gamepads when dinput is used as well as the home/guide button? To quote the Wikipedia link in the first post when using xinput compared to dinput "When used with an Xbox 360 Controller, the left and right trigger buttons will act independently, instead of as a single button".

[andres-asm]

it just means it's a different mapping, not that it doesn't work

[Gagert]

Looks like I have mixed the Windows Gaming Input API with the Gamepad API for web-browsers; with the first one I suppose are meant to be a successor to the xinput API in the long run.

That may explain why xinput still has that old legacy limit of max 4 gamepads with supposedly no plans of ironing this out with a newer version of the xinput API.

[driver1998]

looks like a WinRT API... sure you can use WinRT in desktop app with C++, but RetroArch is mostly a C project, it will get messy fast... And is it much better than xinput?

[Gagert]

Xinput can't handle more than 4 gamepads connected at once, thereby forcing you to switch to the deprecated dinput API for games that support more players (if you are more than 4 people playing of course). Even though dinput doesn't have the max 4 controllers limit, in my experience dinput seems a bit inconsistent when it comes to which controller is player 1; once a secondary controller is activated that gamepad becomes player 1 and the first powered on controller becomes player 2.

To be frank I don't know much of the technicalities of the newer Windows Gaming Input API, other than I suppose this is Microsoft's real successor to xinput (having support for other devices than just the Xbox 360- and Xbox One gamepads officially). I can assume that for the majority of RetroArch users xinput is more than good enough (I personally have 8 wireless Xbox One gamepads at home for my PC), but in theory it sounds like having this API baked into RetroArch could "future proof" RA to some extent.

[Gagert]

I created a thread similar to this some time ago #8304 in the issue tracker, where I complained about the limitations of the xinput API. In Issue #8304 the user @Nemirtingas talks about him making an open-source Xinput library, with his version of xinput removing the 4 player limitation of the original xinput API.

Maybe this somehow could be baked into RetroArch itself, at least as an option to the original xinput setting (xinput and xinput_open or something like that)?

If that went successfully, I suppose the need for the Windows Gaming API for joypads as of now would not be a requested feature (at least not for me).

[driver1998]

One thing might be useful though, it allows UWP to use generic HID controllers (xinput only supports Xbox controller, and DirectInput does not work on UWP) Wonder if this API is available on Xbox One...

[Nemirtingas]

I created a thread similar to this some time ago #8304 in the issue tracker, where I complained about the limitations of the xinput API. In Issue #8304 the user @Nemirtingas talks about him making an open-source Xinput library, with his version of xinput removing the 4 player limitation of the original xinput API.

Now the code is hosted on github: https://github.com/Nemirtingas/OpenXinput and the project has examples.

[driver1998]

One thing to note is WinRT does have a C-style interface (which is pretty much COM in steroids, and quite verbose). SDL2 supports Windows.Gaming.Input via this interface.