XInput support

[Elias Daler]

Supporting XInput on Windows will allow use to have the following:
* Have triggers be independent axes instead of one
* Support vibration (not sure if SFML needs to have API for that or it users would be able to get some state out of SFML to handle that using XInput directly)

Xbox 360 and Xbox One amount to ~64% of gamepads used on Steam, so I think that this feature is necessary to have to be able to handle Xbox 360/Xbox One gamepads correctly.

Also, some gamepads (e.g. Logitech ones) also have a switch from DInput to XInput, so Xbox gamepads are not the ones who rely on XInput to work.

[Nexus]

What would it means in terms of code/dependencies? Could the API remain uniform with Mac and Linux?

I guess you played around with XInput? There's also this guy which has come up with a proof-of-concept, not sure sure how much work would be needed on top.

[Jonny]

It would mean on windows we'd need to link xinput, which I don't see being a problem except perhaps if using minGW, in which case we can just add a macro to disable it.

In terms of the API, I don't think there should be any changes. The implementation would be mostly the same (update the state every frame). Down the line we may want to consider a way for the user to check if a device is using xinput or not, but that would probably be part of a wider gamepad recognition feature

[eXpl0it3r]

Relevant documentation links:

• MSDN
• Wikipedia

I think the main issue here is that most (if not all) controllers that support XInput also support DInput, but with the above mentioned limitations, however many older controllers will not support XInput, so without DInput one would not be able to use them.
As such we need to find a solution to either support both at runtime or pick one at compile time.

[Elias Daler]

Of course, it's possible to switch DInput/XInput at runtime, and by default DInput should be used.