Porting from Windows.Xbox.Input to GameInput
Windows.Xbox.Input is the input API for pre-GDK Xbox One Software Development Kit development. Conceptually, GameInput sees devices and input readings in a different way. This topic describes some key differences between Windows.Xbox.Input and GameInput.
Input-centric vs. device-centric
The key difference between Windows.Xbox.Input and GameInput is that the former requires you to start by gathering devices and input state as a property of a device. In contrast, GameInput starts with a filterable stream of input readings that have associated devices.
Looking for the A button press
When a game first launches, often a user must press A to signify that they're ready to continue. Here, an example compares doing this in Windows.Xbox.Input and GameInput. This example looks only for a gamepad. Note that the examples are simplified for demonstration.
Windows.Xbox.Input
The following code example begins by enumerating all the gamepads that are connected to the system and storing them in the gamepads vector. It then iterates through gamepads in a loop, looks at each of their current input readings, and checks each reading for A.
Note
This code refers to a previous API. These calls are nonexistent in GameInput.
void PollGamepadInput()
{
// Find all gamepads.
IVectorView<IGamepad^>^ gamepads = Gamepad::GetGamepads();
// Cycle through each gamepad.
for ( unsigned int i = 0; i < gamepads->Size; ++i )
{
// Get the gamepad's current reading.
IGamepadReading^ reading = gamepads->GetAt(i)->GetCurrentReading();
if ( reading->IsAPressed )
{
// Logic for the A button being pressed.
}
}
}
This model could be improved. The game must store copies of the different devices that are connected to the system. You must understand the specifics of each device. Also, by storing a local copy of all the gamepads, the code captures a state in time rather than getting the most up-to-date readings.
GameInput
In the following code example, the code looks for the most recent gamepad reading from any device. By calling GetCurrentReading with a GameInputKind filter set to GamePad, the code asks m_gameInput to only return gamepad readings. Next, the code queries the state of the reading and checks for an A press.
You might want to keep track of which gamepad you're talking to. For a more complete example, see GameInput readings.
IGameInput* g_gameInput = nullptr;
HRESULT InitializeInput()
{
return GameInputCreate(&g_gameInput);
}
void PollGamepadInput()
{
ComPtr<IGameInputReading> reading;
// Get the most current gamepad reading, not filtering by a specific device.
// An error from the GetReading method indicates that no gamepad readings
// were found.
if (SUCCEEDED(g_gameInput->GetCurrentReading(GameInputKindGamepad, nullptr, &reading)))
{
// Read the gamepad state.
GameInputGamepadState state;
reading->GetGamepadState(&state);
if (state.buttons & GameInputGamepadA)
{
// Logic for the A button being pressed.
}
}
}
Note
GameInput doesn't require that you iterate through devices and check each reading. Instead, you can check with one method call for the latest state of input. You can choose how much or how little you want to know about each physical device.