• Hey Guest. Check out your NeoGAF Wrapped 2025 results here!

ELI5: Why did Microsoft abandon DirectInput for XInput?

Xinput may be better for devs but I'm still going to be irritated if certain games don't support Dinput. I prefer not needing to set up an xpadder profile to use my Saturn pad in in fighters or 2D games.

Its a shame Xinput didn't have some back compatibility translation of its own so we didn't have to rely on other programs to do it.
 
Xinput may be better for devs but I'm still going to be irritated if certain games don't support Dinput. I prefer not needing to set up an xpadder profile to use my Saturn pad in in fighters or 2D games.

Its a shame Xinput didn't have some back compatibility translation of its own so we didn't have to rely on other programs to do it.

Why would you have to keep setting them up? You set it up once and then it's just ready for use in any Xinput game. This is the opposite of what would happen if you kept having to use Dinput.
 
Press B4 to perform action. What's B4 on my controller? Fucked if I know

I think this post nails it. There have been synergies from both users' and developers' point of view, and it certainly gave controller support focus and far less confusion when it comes to modern PC games.

That being said, the PC platform is all about flexibility, but at the end of the day developers and publishers are the ones calling the shots; most of the time they will be rational ones when it comes to controller support.
 
Why would you have to keep setting them up? You set it up once and then it's just ready for use in any Xinput game. This is the opposite of what would happen if you kept having to use Dinput.
I've never got an xinput translator to work. I just translate from keyboard controls to pad. You'd be surprised how none standard the keys used for navigating menus are particularly if its Japanese games which is what I normally need a 2D pad for. Sometimes I need more keys then I have buttons so I have to allow for that by setting up multi use buttons. If dinput is supported I can just go to the menu and press what I want for low punch high punch etc and menu navigation is usually handled separately so I don't have to worry about it.
 
If XInput is widely supported, why don't peripherals like the DS4 support it out of the box? Windows recognizes the DS4 just fine and it even works fine in some games but most require DS4Windows to make it emulate a 360 controller.

To be honest I think all platforms right now do controllers very poorly. PS4 and Xbox barely support remapping buttons let alone using something that isn't the stock controller. PC on the other hand generally supports Xbox 360 controller and nothing else without jumping thru a few hoops. It's really weird that for example GTA V on PS4 allows you to use motion controls for some things but on the PC the same game does not allow this at all.
 
Why would you have to keep setting them up? You set it up once and then it's just ready for use in any Xinput game. This is the opposite of what would happen if you kept having to use Dinput.

You'll find that for some things like fighting games sticks the buttons actually aren't in the order you'd expect, or in any consistent order for that matter. Even between two Xinput pads from different companies there can be differences, so the problem XInput set out to solve actually isn't solved at all.

DirectInput is a bad (or, being generous, outdated and problematic) control API that supports a wealth of specific options for input devices.

XInput is an elegant, easy-to-use, super-convenient control API that only supports a limited number and narrow style of devices.

"Fixing" DirectInput probably wasn't super viable, especially given the likelihood of BC breaks to make any significant improvements. We could probably benefit from an expanded API that supports many more types of inputs based on the template of the existing XInput API.

I wouldn't say DirectInput is a bad API. Having personally programmed for both XInput and DirectInput, outside of the convenience of supporting xbox pads out of the box without any question and knowing the layout of the controller, I still prefer directInput. Even most of its shortcomings are specifically related to xbox pad support these days (ie no rumble and the trigger thing. And just because MS gimped the DI driver). The 30 or so lines needed to set up sticks in directinput aren't really that hard.

Also don't forget directinput isn't abandoned, it's deprecated, which in MS lingo means it still works fine, just that the API won't evolve anymore. Heck, DirectX was officially deprecated for a while and now we're still getting DX12.

It's unlikely we'll get an expanded API for XInput because that's what DI is for, and alternatively if you want deeper support at the price of code complexity there's Raw Input, which will handle crazy stuff like multiple keyboards.
 
I've recently started playing my PC games on my tv with a xbox one controller, I absolutely love it. It's given alot of my backlog games a second life.

My question would be, is there any way to get the xbox one controller to act as a mouse? This would make it easier to navigate my desktop/steam/origin without having to get up (yes, I'm very lazy)
 
Xinput taking over was a good step forward for standardizing gamepad control on PC. I still keep an older logitech gamepad around for if I want to play a super old game that only uses directinput, and if you only have a directinput device still you can easily spoof it as a 360 pad using various windows programs. I also still use directinput for joystick setup in flight style games.
 
You can still use dinput, can you not?

Fewer and fewer do. The best PC developers do still at least give you options like remapping and etc., but most of them simply assume you're using an Xbox controller and if what you're using (in my case, often a Dualshock 2) doesn't work for whatever reason, you're shit out of luck.

The worst developers strictly enforce Xbox controllers only, and that's been an awful trend to encounter. I first encountered it while trying to play Mafia 2 on PC.

There are ways to help with this, like Xbox 360 Controller Emulator, but in my experience that can be extremely finicky to get working. It has straight up stopped working in some games for no discernible reason.

By standardizing PC controllers, Microsoft has essentially cornered the market simply by capitalizing on lazy developers who implement the bare minimum of gamepad support and call it a day.
 
I think the simple existence of the 360 pad would have standardized joypad usage. I don't think you'd have had to drop support for older pads at the same time. The important thing would have been knowing 360 is the default layout and then its easy for the user to abstract that to other pads if they want. But your not able to without additional software.
 
If XInput is widely supported, why don't peripherals like the DS4 support it out of the box? Windows recognizes the DS4 just fine and it even works fine in some games but most require DS4Windows to make it emulate a 360 controller.

To be honest I think all platforms right now do controllers very poorly. PS4 and Xbox barely support remapping buttons let alone using something that isn't the stock controller. PC on the other hand generally supports Xbox 360 controller and nothing else without jumping thru a few hoops. It's really weird that for example GTA V on PS4 allows you to use motion controls for some things but on the PC the same game does not allow this at all.

Why would xinput automatically make a PS4 be recognized as a 360 controller? It's up to Rockstar to enable motion controls for certain devices just like it's up to Sony to make official drivers for windows.
 
Why would xinput automatically make a PS4 be recognized as a 360 controller? It's up to Rockstar to enable motion controls for certain devices just like it's up to Sony to make official drivers for windows.

It shouldn't, I meant that a DS4 should be XInput compatible from the box instead of needing DS4Windows to make the game think it's a XInput device (which to most games seems to mean 360 controller).
 
If XInput is widely supported, why don't peripherals like the DS4 support it out of the box? Windows recognizes the DS4 just fine and it even works fine in some games but most require DS4Windows to make it emulate a 360 controller.

I'm not exactly sure about Windows, but 360 at least used primitive* cryptography to ensure you use MS-signed controllers. (Source: the guy who published some details about USB protocol of Skylanders, then got C&D.) So making a compatible controller would require some OS-confusion hackery or duplication of the crypto, which would be considered as some sort of digital breach in a US court, probably.

* I.e. guy showed a workaround... but it requires a 360 pad per actual pad.
 
XInput:

Code:
currentContState = XInputGetState( contNumber, contState );

DirectInput

Code:
The following steps represent a simple implementation of DirectInput in which the application takes responsibility for ascertaining what device object (button, axis, and so on) generated each item of data.
1) Create the DirectInput object.
You use methods of this object to enumerate devices and create DirectInput device objects.
2) Enumerate devices.
This is not an essential step if you intend to use only the system mouse or keyboard. To ascertain what other input devices are available on the user's system, have DirectInput enumerate them. Each time DirectInput finds a device that matches the criteria you set, it gives you the opportunity to examine the device's capabilities. It also retrieves a unique identifier that you can use to create a DirectInput device object representing the device.
3) Create a DirectInputDevice object for each device you want to use.
To do this, you need the unique identifier retrieved during enumeration. For the system mouse or keyboard, you can use a standard globally unique identifier (GUID).
4) Set up the device.
For each device, first set the cooperative level, which determines the way the device is shared with other applications or the system. You must also set the data format used for identifying device objects, such as buttons and axes, within data packets. If you intend to retrieve buffered data-that is, events rather than states-you also need to set a buffer size. Optionally, at this stage you can retrieve information about the device and tailor the application's behavior accordingly. You can also set properties such as the range of values returned by joystick axes.
5) Acquire the device.
At this stage you tell DirectInput that you are ready to receive data from the device.
6) Retrieve data.
At regular intervals, typically on each pass through the message loop or rendering loop, get either the current state of each device or a record of events that have taken place since the last retrieval. If you prefer, you can have DirectInput notify you whenever an event occurs.
7) Act on the data.
The application can respond either to the state of buttons and axes or to events such as a key being pressed or released.

I wonder why developers like Xinput?
 
XInput:

Code:
currentContState = XInputGetState( contNumber, contState );

DirectInput

Code:
The following steps represent a simple implementation of DirectInput in which the application takes responsibility for ascertaining what device object (button, axis, and so on) generated each item of data.
1) Create the DirectInput object.
You use methods of this object to enumerate devices and create DirectInput device objects.
2) Enumerate devices.
This is not an essential step if you intend to use only the system mouse or keyboard. To ascertain what other input devices are available on the user's system, have DirectInput enumerate them. Each time DirectInput finds a device that matches the criteria you set, it gives you the opportunity to examine the device's capabilities. It also retrieves a unique identifier that you can use to create a DirectInput device object representing the device.
3) Create a DirectInputDevice object for each device you want to use.
To do this, you need the unique identifier retrieved during enumeration. For the system mouse or keyboard, you can use a standard globally unique identifier (GUID).
4) Set up the device.
For each device, first set the cooperative level, which determines the way the device is shared with other applications or the system. You must also set the data format used for identifying device objects, such as buttons and axes, within data packets. If you intend to retrieve buffered data-that is, events rather than states-you also need to set a buffer size. Optionally, at this stage you can retrieve information about the device and tailor the application's behavior accordingly. You can also set properties such as the range of values returned by joystick axes.
5) Acquire the device.
At this stage you tell DirectInput that you are ready to receive data from the device.
6) Retrieve data.
At regular intervals, typically on each pass through the message loop or rendering loop, get either the current state of each device or a record of events that have taken place since the last retrieval. If you prefer, you can have DirectInput notify you whenever an event occurs.
7) Act on the data.
The application can respond either to the state of buttons and axes or to events such as a key being pressed or released.

I wonder why developers like Xinput?

I don't necessarily know how this is really that big of a deal. I mean, I'd think a coder would write a system to interface with directinput one time in their entire lives and then they'd re-use that code for every project going forward.

And compared to some of the coding that goes in to game engines, setting up directinput isn't even close to the most complex thing that will ever exist in a game
 
I wouldn't say DirectInput is a bad API. Having personally programmed for both XInput and DirectInput, outside of the convenience of supporting xbox pads out of the box without any question and knowing the layout of the controller, I still prefer directInput. Even most of its shortcomings are specifically related to xbox pad support these days (ie no rumble and the trigger thing. And just because MS gimped the DI driver). The 30 or so lines needed to set up sticks in directinput aren't really that hard.

It creates busywork for developers and makes things dramatically less convenient for gamers. Maybe it's not a bad API per se, but supporting it just to make sure the people who want to use their 27-button arcade stick slash trackball are all set isn't really the sign of an effective platform-holder. Standardizing the PC controller (and thereby drastically improving the state of controller support) was far more valuable than trying to stick it out with DirectInput, warts and all.
 
DirectInput was not killed in favour of XInput.

It was killed in favour of Raw Input. Raw Input is the Windows API for USB input devices, including gamepads. It is based on USB HID reports and also supports keyboards, mice and other devices.

Yep, XInput is basically a wrapper around raw USB input that handles certain things automatically (Like button mapping, dead zone, etc.)

Use Raw USB input to work with any random controller (Including mice and keyboard), XInput to provide a standard experience with 360/One controllers.
 
Top Bottom