This should generally be transparent to most legacy XInput code. The value of XUSER_MAX_COUNT has been increased from 4 to 8. This is done regardless of any calls to XInputEnable (or lack thereof). When the game is not in focus, any gamepad state returned is set to neutral or "rest" values, as if the user isn't touching the gamepad. The wrapper will return gamepad input only when the game is in focus. If you need to support other devices, such as racing wheels or arcade sticks, use GameInput directly or add support for those devices in the XInputOnGameInput code. However, there are a few minor differences:įor simplicity, only gamepad device support has been coded into the wrapper. Generally, the XInputOnGameInput wrapper is a direct drop-in replacement for the legacy XInput API. The implementation of the XInput wrapper code is entirely in the header file, so it can also be examined as an example of using the GameInput API, and/or modified as needed.ĭifferences between XInput and XInputOnGameInput To use the XInputOnGameInput wrapper, simply replace this code: #include However, the XInputOnGameInput wrapper can be used to help bootstrap an initial porting effort without requiring any changes to existing XInput code. We recommend porting directly to GameInput especially if you want keyboard and mouse or other input devices. The Microsoft Game Development Kit (GDK) ships with a header file called XInputOnGameInput.h that contains an implementation of the XInput API on top of GameInput. In the future, this behavior will be changeable by using the SetFocusPolicy method. On PC, input goes to all processes by default. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |