The XInput API is almost trivial to use at first glance which is basically two simple C APIs with very simple parameters. There are, however, a number of subtleties that have crept in over the years, including the split between Windows 8 and previous releases. There is also a potential performance problem if you naively try to search for multiple gamepads that are not currently connected every frame due to the underlying overhead of device enumeration to look for newly connected gamepads. Also, while XInput was available on Xbox 360, the Xbox One makes use of a WinRT IGamePad API instead.
At this point, it would be useful to have a nice abstraction to handle all this that you could code against while keeping your application’s code elegant and simple to use. As usual, when looking for a design to start with, it turns out this problem was already nicely solved for C# developers with the XNA Game Studio GamePad class.
The September 2014 release of DirectX Tool Kit includes a C++ version of the GamePad class. To make it broadly applicable, it makes use of XInput 9.1.0 on Windows Vista or Windows 7, XInput 1.4 on Windows 8.x, and IGamePad on Xbox One. It’s a simple class to use, and it takes care of the nuanced issues above. It implements the same thumb stick deadzone handling system as XNA, which is covered in detail by Shawn Hargreaves in his blog entry “Gamepads suck”. The usage issue that continues to be the responsibility of the application is ensuring that you poll it fast enough to not miss user input, which mostly means ensuring your game has a good frame rate.
The headset audio features of XInput are not supported by the GamePad class. Headset audio is not supported by XInput 9.1.0, has some known issues in XInput 1.3 on Windows 7 and below, works a bit differently in XInput 1.4 on Windows 8, and is completely different again on the Xbox One platform.
The GamePad class is supported on all the DirectX Tool Kit platforms: Win32 desktop applications for Windows Vista or later, Windows Store apps for Windows 8.x, and Xbox One. You can create and poll the GamePad class on Windows Phone 8.x as well, but since there’s no support for gamepads on that platform it always returns ‘no gamepad connected’.
Xbox One Controller
Support for the Xbox One Controller on Windows was announced by Major Nelson in June and drivers are now hosted on Windows Update, so using it is a simple as plugging it into a Windows PC via a USB cable (see the Xbox One support website). The controller is supported through the XInput API as if it were an Xbox 360 Common Controller with the View button being reported as
XINPUT_GAMEPAD_BACK, and the Menu button being reported as
XINPUT_GAMEPAD_START. All the other controls map directly, as do the left and right vibration motors. The left and right trigger impulse motors cannot be set via XInput, so they are not currently accessible on Windows.
The Xbox One Wireless controller is not compatible with the Xbox 360 Wireless Receiver for Windows, so you have to use a USB cable to use it with Windows. Note also that it will unbind your controller from any Xbox One it is currently setup for, so you’ll need to rebind it when you want to use it again with your console.
Update: DirectX Tool Kit is also hosted on GitHub.
Windows 10: There is a new Windows Runtime API in the Windows.Gaming.Input namespace for universal Windows apps. This API supports both the Xbox 360 Common Controller and the Xbox One controller, including access to the left/right trigger motors. The latest version of GamePad is implemented using this new API when built for Windows 10. Note that existing XInput-based Windows Store applications can link against
xinputuap.lib which is an adapter for the new API for universal Windows apps–this adapter does not expose headset audio either.
Microsoft GDK: For Gaming.Xbox.*.x64 platforms, GamePad is implemented using the GameInput API. This API will be supported on PC as well at a later date.