Test xinput controller code#

Test xinput controller code#

This eliminates the need for extra input code that deals with change in focus (for example, calling XInputEnable). Otherwise, the state returned contains neutral or 'rest' values, as if the user isn't touching the device at all. On console, GameInput provides input to an application only when it is in focus. This is an example of when you'll call functions on the device interface, rather than it solely being a device identifier. The usage is similar between these two methods. In GameInput, games need to acquire the IGameInputDevice instance for the device, then call its SetRumbleState method. In XInput, games simply call XInputSetState to send rumble (vibration) commands to a device. With the GameInput API, these analog values are returned as float values from 0 to 1 (triggers) or -1 to 1 (thumbsticks). It is also worth noting that XInput returns analog values from triggers as type BYTE, and analog values from thumbsticks as type SHORT. As you become more familiar with the GameInput API, you'll see how this model provides powerful options to handle input that do not exist in XInput. The code isn't quite as simple as XInput, but it's very similar.

method to receive input only from that gamepad. pass that into future calls to the GetCurrentReading get the device that generated this input, and then For example, the following code is typical for a game prompting the user to 'press A' on their controller: // This function looks for a gamepad that currently has the 'A' button pressed.įor (DWORD index = 0 index GetCurrentReading(GameInputKindGamepad, nullptr, &reading))) Games will often remember the user index so they don't have to loop the next time. In XInput, most games loop through the user indices until one is found with a connected device, then state is read from that device. For more information, see the Interfaces section of the GameInput fundamentals topic. Only a basic understanding of reference counting is required to use these interfaces. It's important to understand that although these interfaces may look like COM, they aren't. In practice, this doesn't complicate code that uses the GameInput API, doesn't impact performance, and has some advantages that become apparent once you become more familiar with how GameInput works. GameInput, on the other hand, is C++ and uses interfaces (just like the graphics and audio APIs). The XInput API is a collection of flat C functions. The key differences between XInput and GameInput are discussed in the following sections.

This is because GameInput was heavily influenced by XInput's simple (and easy to use) programming model, and therefore, many XInput APIs map 1:1 with equivalent functions in GameInput. Porting from XInput to GameInput is the least complicated of any of the legacy APIs.