Mortal Kombat X - Configure Controls w/ IPAC?

[evh347]

Anyone figure out a good way to get their arcade cabinet's IPAC to work with the new MKX game for PC?

[bulbousbeard]

Works fine here. The game itself blows, though.

[evh347]

Okay...I can edit the keyboard controls in the game and then those controls don't work once in the game. It appears the method of editing the controls is broken. You can't simply clear out the unwanted control key. Every time I go to edit a key it leaves two keys.

You have to hit ENTER to edit the control, pick the key you want to use and hit ENTER again and select a second key you won't use. On the next control, hit ENTER, out in the key you want, and again the key you don't want, but that will cause the previous control you configured to leave only the key you want to use instead of two controls.

However....the up/down works in the game menus but once in the fight they stop working. The only controls that work are the whatever the default controls were originally upon install. Example: W-A-S-D work in the game but they are not mapped to the buttons I mapped them to in the "wireless controller" menu.

Is there a fix for this?

[evh347]

I downloaded today's update for the PC version, but I think they still have a ways to go. With both the IPAC and keyboard plugged in at the same time, it appears the controls do work depending on what you set them to. The problem is they only work when you use the actual keyboard.

In menu selection screens, my IPAC will allow up/down movement and ENTER selections, but that's it. In the character and stage selection screen, the IPAC is completely unregistering as well as once the fight begins.

My IPAC shows up fine (registers keystrokes) outside of MKX, but not within MKX.

I have found only one way to get the IPAC to register correctly. I have to back out of the game, unplug my USB keyboard, and then start the game. The IPAC registers correctly then as I've designated in the "wireless controller" settings. So it seems that MKX is not programmed to see more than one keyboard at a time. The issue with having only the IPAC plugged in (and not your keyboard) is that you can't map an ESC (back out) option. So if your keyboard is unplugged, the only way to back out is to completely quit the game by shutting down processes (CTRL-ALT-DEL).

Equally as unhelpful is the fact that in Practice Mode, the actual moves stream along the side as the key that is registering from the keyboard. So instead of FP, BL, ->, etc...it shows the key that's associated with that move.

[sc23]

I downloaded today's update for the PC version, but I think they still have a ways to go. With both the IPAC and keyboard plugged in at the same time, it appears the controls do work depending on what you set them to. The problem is they only work when you use the actual keyboard.

In menu selection screens, my IPAC will allow up/down movement and ENTER selections, but that's it. In the character and stage selection screen, the IPAC is completely unregistering as well as once the fight begins.

My IPAC shows up fine (registers keystrokes) outside of MKX, but not within MKX.

I have found only one way to get the IPAC to register correctly. I have to back out of the game, unplug my USB keyboard, and then start the game. The IPAC registers correctly then as I've designated in the "wireless controller" settings. So it seems that MKX is not programmed to see more than one keyboard at a time. The issue with having only the IPAC plugged in (and not your keyboard) is that you can't map an ESC (back out) option. So if your keyboard is unplugged, the only way to back out is to completely quit the game by shutting down processes (CTRL-ALT-DEL).

Equally as unhelpful is the fact that in Practice Mode, the actual moves stream along the side as the key that is registering from the keyboard. So instead of FP, BL, ->, etc...it shows the key that's associated with that move.

Hey, I was hoping more people on here would be trying to tackle this. I have the same issues as you. From what I gather the only way to control game and menus is by using VJOY. I can re-map buttons so fighting is all good, but character select and stage screen only accept WASD controls.

[Howard_Casto]

We figured out via battles with both MK9 and Injustice that the "solution" is to switch to gamepads, preferably 360 controllers as your input method if you enjoy NRS fighters... or modern windows games in general.

[twistedsymphony]

I'm having the same problem, up, down, enter and escape work fine in the menu but it wont let me reconfigure.

My solution for MK9 and Injustice was to use Headsoft's VJoy which works fantastic, however MKX flat out wont recognize the VJoy virtual joysticks.

I've tried a half dozen suggestions from others online playing with the controller drivers to no avail. I've read a lot of other people having problems with getting game pads recognized but no real confirmation on a working solution.

I've been debating replacing the iPAC with PS360+ PCBs but I have no idea if that would end up being a lot of work for nothing.

[bulbousbeard]

Don't replace any good components for this crappy game. Any gamepad is going to have more input lag than the I-PAC because you won't be able to run MAME in Raw Input mode with a gamepad. Raw Input or don't even get out of bed.™

If you're going to use a crappy Xbox gamepad to power your cabinet, you might as well completely ---steaming pile of meadow muffin--- up your cabinet, run Linux, and eat the 8 frames of input lag with fervor.

[Malenko]

Don't replace any good components for this crappy game. Any gamepad is going to have more input lag than the I-PAC because you won't be able to run MAME in Raw Input mode with a gamepad. Raw Input or don't even get out of bed.™

If you're going to use a crappy Xbox gamepad to power your cabinet, you might as well completely ---steaming pile of meadow muffin--- up your cabinet, run Linux, and eat the 8 frames of input lag with fervor.

are you always this positive and constructive?

[twistedsymphony]

Don't replace any good components for this crappy game. Any gamepad is going to have more input lag than the I-PAC because you won't be able to run MAME in Raw Input mode with a gamepad. Raw Input or don't even get out of bed.™

If you're going to use a crappy Xbox gamepad to power your cabinet, you might as well completely ---steaming pile of meadow muffin--- up your cabinet, run Linux, and eat the 8 frames of input lag with fervor.

8 frames of input lag? you're telling me there's a 128ms of input lag on USB 360 controllers?

has anyone done any real-world, hard evidence producing, tests on 360 controller input lag?

[Howard_Casto]

The 360 gamepad is the defacto standard for pc games now to the point of where if you plug one in, a game automatically configures itself optimized for the gamepad.  They don't have any more lag than any other device.  For the record keyboard encoders don't use raw input in the lagless sense that he's talking about.  It's a USB device... data is still sent in packets.  Any device in which there are more inputs than pins on the connector have some degree of lag as the data is sent serially.

[Malenko]

The 360 gamepad is the defacto standard for pc games now to the point of where if you plug one in, a game automatically configures itself optimized for the gamepad.  They don't have any more lag than any other device.  For the record keyboard encoders don't use raw input in the lagless sense that he's talking about.  It's a USB device... data is still sent in packets.  Any device in which there are more inputs than pins on the connector have some degree of lag as the data is sent serially.

 

[twistedsymphony]

for anyone interested the closest I could find was this video:


it's comparing the difference in lag between a wired and a wireless 360 controller on a PC. (of which the video concludes there is no discernible difference).

The total time from button push to reaction on the display was around 66ms (about 4 frames), but that also includes whatever display lag was occurring on this setup AND it was done using a 60FPS camera which means that it's only accurate to within 16ms (or 1 frame). Considering the recording mechanism and even the fastest displays have around 10-12ms of lag that means that the controllers have, at worst, between 40 and 55ms of lag. And without a comparison to an iPAC there's no telling if that's actually better or worse.

[TheManuel]

I haven't bought the game yet but to those who own it you should try the usual:

1. x360ce hack that worked for SFIV and MK9 but looking at my topic on it so save you some headaches.

If that fails:

2. The more cumbersome Injustice work-around which is a pain in the ass but doable.  I ended up using devcon in my ahk script to disable the virtual vjoy controllers to avoid it clashing with other PC games, especially those using x360ce.  Another issue was some of the keyboard inputs were hard-coded and clashed with your vjoy assignments.  If anyone is interested I can post the Injustice script tonight when I'm home.

No easy answers, unfortunately, but x360ce is the best answer if it works, short of switching over to xbox 360 gamepads.

[Howard_Casto]

for anyone interested the closest I could find was this video:


it's comparing the difference in lag between a wired and a wireless 360 controller on a PC. (of which the video concludes there is no discernible difference).

The total time from button push to reaction on the display was around 66ms (about 4 frames), but that also includes whatever display lag was occurring on this setup AND it was done using a 60FPS camera which means that it's only accurate to within 16ms (or 1 frame). Considering the recording mechanism and even the fastest displays have around 10-12ms of lag that means that the controllers have, at worst, between 40 and 55ms of lag. And without a comparison to an iPAC there's no telling if that's actually better or worse.

And since I'm so fond of pummeling horse corpses....

Keyboard input on modern pc games is typically handled through directinput.  DirectInput is event driven, meaning if an event occurs, it fires a generic function in which the device and type of event has to be parsed, filtered, and then handled.  This means lag.  Mind you it isn't a huge amount of lag in terms of human reflexes, but keep in mind that Xinput was introduced to streamline this.

Xinput devices show up as device 1-4 and they are pre configured as they are plugged in.  In addition xinput requires active parsing.... meaning it has to ask the state of the devices in the game loop.... which is exactly how old consoles and arcade machines did it.  The report data is like 16 bytes sent at once (if I'm remembering correctly... it's around there) through the function... no usb handling nonsense and no need to parse... you can dump it directly into a xinput_state structure and it's ready for use in the game code. 

So while I think that in any instance the amount of lag we are talking about is inconsequential, if anything, 360 gamepads should be faster. 

[bulbousbeard]

Actually, you're wrong. Direct Input is almost completely dead (Microsoft has deprecated it).

https://msdn.microsoft.com/en-us/library/windows/desktop/ee417014%28v=vs.85%29.aspx

As far as input latency goes: Raw Input > XInput > Direct Input.

MAME uses Raw Input, and Raw Input has significantly less input lag than Direct Input or XInput. Direct Input processes input data before the application gets it, and that's why it's so much more laggy than the other APIs. It blows.

Even though XInput is better than Direct Input, remember that MAME does not support XInput natively. If you don't use Raw Input, you're stuck with Direct Input, which is almost as bad as SDL in terms of input latency.

No USB gamepad can take advantage of Raw Input natively--only mice and keyboards can. Finally, you can use a PS/2 keyboard encoder with Raw Input in MAME. It's about as responsive as you can get.

So yeah, let's stop spreading ---saint's minion-poo--- misinformation, please.

https://www.youtube.com/watch?v=zbkizy-Y3qw#t=2m23s

Geezus

[bulbousbeard]

The 360 gamepad is the defacto standard for pc games now to the point of where if you plug one in, a game automatically configures itself optimized for the gamepad.  They don't have any more lag than any other device.  For the record keyboard encoders don't use raw input in the lagless sense that he's talking about.  It's a USB device... data is still sent in packets.  Any device in which there are more inputs than pins on the connector have some degree of lag as the data is sent serially.

 

Good job on applauding factually incorrect information. 

[bulbousbeard]

Don't replace any good components for this crappy game. Any gamepad is going to have more input lag than the I-PAC because you won't be able to run MAME in Raw Input mode with a gamepad. Raw Input or don't even get out of bed.™

If you're going to use a crappy Xbox gamepad to power your cabinet, you might as well completely ---steaming pile of meadow muffin--- up your cabinet, run Linux, and eat the 8 frames of input lag with fervor.

8 frames of input lag? you're telling me there's a 128ms of input lag on USB 360 controllers?

has anyone done any real-world, hard evidence producing, tests on 360 controller input lag?

No, I'm saying there's 8 frames of input lag with a Linux setup with a USB gamepad with SDL.

[bulbousbeard]

for anyone interested the closest I could find was this video:


it's comparing the difference in lag between a wired and a wireless 360 controller on a PC. (of which the video concludes there is no discernible difference).

The total time from button push to reaction on the display was around 66ms (about 4 frames), but that also includes whatever display lag was occurring on this setup AND it was done using a 60FPS camera which means that it's only accurate to within 16ms (or 1 frame). Considering the recording mechanism and even the fastest displays have around 10-12ms of lag that means that the controllers have, at worst, between 40 and 55ms of lag. And without a comparison to an iPAC there's no telling if that's actually better or worse.

So we've confirmed that wired 360 pads are so laggy that they don't even seem to perform better than wireless devices. Yeah, that's a nice gamepad you've got there (geezus).

[yotsuya]

The 360 gamepad is the defacto standard for pc games now to the point of where if you plug one in, a game automatically configures itself optimized for the gamepad.  They don't have any more lag than any other device.  For the record keyboard encoders don't use raw input in the lagless sense that he's talking about.  It's a USB device... data is still sent in packets.  Any device in which there are more inputs than pins on the connector have some degree of lag as the data is sent serially.

 

Good job on applauding factually incorrect information. 

I think he's applauding the fact Howard knows how to express an opinion without sounding like a dick. Take notes.

[headkaze]

MAME uses Raw Input, and Raw Input has significantly less input lag than Direct Input or XInput. Direct Input processes input data before the application gets it, and that's why it's so much more laggy than the other APIs. It blows.

MAME uses RawInput for keyboard and mice input. It uses DirectInput for joystick. There are currently no other options for MAME at this time.

No USB gamepad can take advantage of Raw Input natively--only mice and keyboards can. Finally, you can use a PS/2 keyboard encoder with Raw Input in MAME. It's about as responsive as you can get.

You can use RawInput to read joystick data as with any other HID device. Call RegisterRawInputDevices with HID_USAGE_GENERIC_JOYSTICK and HID_USAGE_GENERIC_GAMEPAD then read the data in WM_INPUT. RawInput is a layer above the HID user library. You can in fact use it to read the raw joystick data and bypass RawInput altogether if you wanted to.

We're talking about HID devices communicating through USB. I have my doubts about the performance difference you claim between using DirectInput and RawInput for reading joystick data. If you want to prove me wrong by all means provide some profiling data to back up what you're saying. I'd also challenge you to compare the performance between windows messaging for reading a keyboard (WM_KEYDOWN / WM_KEYUP) and RawInput. I doubt you will find anything significant.

Clearly using RawInput is the recommended way for reading mice and keyboard and allows MAME to support multiple devices as well as higher DPI mice. I just don't believe there is any significant benefit to using RawInput when it comes to reading joystick input. The MAME developers could easily implement it for joysticks and remove all signs of DirectInput if they wanted to. If it makes such a big difference, as you suggest, you have to ask yourself why they haven't already. Finally DirectInput supports calibrated joysticks while RawInput does not.

As for USB vs PS/2 keyboard encoders. I am no expert in this area but then again I don't claim to be. But how about reading what Andy (the manufacturer of the Ultimarc I-PAC) has to say about it.

[headkaze]

My solution for MK9 and Injustice was to use Headsoft's VJoy which works fantastic, however MKX flat out wont recognize the VJoy virtual joysticks.

Perhaps MKX only supports XInput? For the next update to VJoy I think I'll copy the HID descriptor of an XBox 360 controller so XInput will recognise them.

[Malenko]

I think he's applauding the fact Howard knows how to express an opinion without sounding like a dick. Take notes.

That's certainly part of it. HC and I aren't exactly best friends, but he brings facts to the table fairly eloquently and BB brings opinions dressed as facts all while being coarse and vulgar. Its perfectly fine to think RAW input is the best but its not ok to belittle others because they believe there are other serviceable substitutes.

The applaud was mostly directed at me agreeing with HC that 360 controllers have become the defacto standard for PC gaming. I 'd venture a guess that 80% of my steam library supports a 360 controller natively; makes gaming much more enjoyable on a PC when you can just plug a controller in and everything works.

[bulbousbeard]

MAME uses Raw Input, and Raw Input has significantly less input lag than Direct Input or XInput. Direct Input processes input data before the application gets it, and that's why it's so much more laggy than the other APIs. It blows.

MAME uses RawInput for keyboard and mice input. It uses DirectInput for joystick. There are currently no other options for MAME at this time.

No USB gamepad can take advantage of Raw Input natively--only mice and keyboards can. Finally, you can use a PS/2 keyboard encoder with Raw Input in MAME. It's about as responsive as you can get.

You can use RawInput to read joystick data as with any other HID device. Call RegisterRawInputDevices with HID_USAGE_GENERIC_JOYSTICK and HID_USAGE_GENERIC_GAMEPAD then read the data in WM_INPUT. RawInput is a layer above the HID user library. You can in fact use it to read the raw joystick data and bypass RawInput altogether if you wanted to.

Clearly using RawInput is the recommended way for reading mice and keyboard and allows MAME to support multiple devices as well as higher DPI mice. I just don't believe there is any significant benefit to using RawInput when it comes to reading joystick input. The MAME developers could easily implement it for joysticks and remove all signs of DirectInput if they wanted to. If it makes such a big difference, as you suggest, you have to ask yourself why they haven't already. Finally DirectInput supports calibrated joysticks while RawInput does not.

Even though it should work in theory, they haven't done it (and nobody will do it) because, unlike mice and keyboards, there are no standards for joystick data, and you don't really want to treat every gamepad generically, anyway, because they almost all have unique features. I've seen many different attempts at generic gamepad support using Raw Input, and they all seem to fail on one gamepad or another, because there's always some weird gamepad that doesn't behave the way you'd anticipate. An Xbox 360 pad is going to give you bytes in one format, and a Logitech gamepad is going to give you bytes in a different format. If you wanted to support USB gamepads with Raw Input properly, you'd have to write a byte parser that could handle basically every gamepad. At that point, you're almost writing gamepad drivers.

One gamepad's shoulder buttons might be analog whereas another gamepad's buttons might be digital. One gamepad's face buttons might be pressure sensitive whereas another gamepad's face buttons are digital. One gamepad might have force feedback and another might not. The Playstation 4 pad has a touch screen, and the 360 pad doesn't. What makes a gamepad? Which structure are you going to impose on all devices? So, like I said in the first place, there is no native way to take advantage of Raw Input with USB gamepads because there is no standard data structure for joysticks, and you'd effectively be writing per-gamepad support for each device.



There are no standards there intentionally, because unlike mice and keyboards, there are all kinds of different HIDs that manufacturers might want to make, so it doesn't make sense to impose something on them. The reason Direct Input is still being used by some software is because it gives you a standardized way to access controls across a wide variety of devices (not just XInput devices). You're basically offloading the work onto the gamepad's driver at that point (although it should be noted that not all gamepad drivers implement Direct Input the same way).

If you think you can come up with a good, generic Raw Input solution that'll work on a wide variety of gamepads, please do us all a favor and submit the implementation to MAMEdev. Personally, I don't see it happening.

Microsoft has basically left people with no choices for gamepads in a pathetic attempt to force their Xbox gamepads on everyone, and given that there are stooges in this forum (one of the places where consumers should know better) that are happy about it, apparently, Microsoft's succeeded. It's even worse if you don't have a Microsoft gamepad, because then you have to run an XInput emulator on top of everything else. So bad. Some anti-trust action needs to be taken against Microsoft again. How is it not a conflict of interest for Microsoft to effectively screw over every 3rd party gamepad manufacturer to push their own gamepads?

[bulbousbeard]

The 360 gamepad is the defacto standard for pc games now to the point of where if you plug one in, a game automatically configures itself optimized for the gamepad.  They don't have any more lag than any other device.  For the record keyboard encoders don't use raw input in the lagless sense that he's talking about.  It's a USB device... data is still sent in packets.  Any device in which there are more inputs than pins on the connector have some degree of lag as the data is sent serially.

 

Good job on applauding factually incorrect information. 

I think he's applauding the fact Howard knows how to express an opinion without sounding like a dick. Take notes.

Calling someone else a dick is worse than anything I wrote. Take notes.

[twistedsymphony]

My solution for MK9 and Injustice was to use Headsoft's VJoy which works fantastic, however MKX flat out wont recognize the VJoy virtual joysticks.

Perhaps MKX only supports XInput? For the next update to VJoy I think I'll copy the HID descriptor of an XBox 360 controller so XInput will recognise them.

I don' t know what the issue is exactly. I've seen some reports of people getting their joysticks recognized by unplugging their keyboard and mouse when launching the game such that the joystick is the only device attached... (I'm not exactly sure how they're launching the game without a keyboard or mouse or maybe they're just pulling them immediately after launching),  not really an option with a virtual joystick though.

I misspoke when I said they were completely unrecognized at least the up and down left and right are recognized in the main menu and character selection screen on both sticks. but none of the buttons are. while in the controller configuration menu or during gameplay the direction buttons are no longer recognized.

for anyone interested the closest I could find was this video:


it's comparing the difference in lag between a wired and a wireless 360 controller on a PC. (of which the video concludes there is no discernible difference).

The total time from button push to reaction on the display was around 66ms (about 4 frames), but that also includes whatever display lag was occurring on this setup AND it was done using a 60FPS camera which means that it's only accurate to within 16ms (or 1 frame). Considering the recording mechanism and even the fastest displays have around 10-12ms of lag that means that the controllers have, at worst, between 40 and 55ms of lag. And without a comparison to an iPAC there's no telling if that's actually better or worse.

So we've confirmed that wired 360 pads are so laggy that they don't even seem to perform better than wireless devices. Yeah, that's a nice gamepad you've got there (geezus).

Wow that is a gross misconsturing of the evidence presented. the pads being "so laggy" wasn't at all confirmed. we have 0 basis for the level of lag present in the controllers because we don't have a baseline display lag measurement without the controllers to compare to. All we've confirmed is that there is no difference between the wired and wireless xbox 360 controllers.

I don't have any personal opinions on what the best control setup is, I just want something that 1. actually works and 2. will be as lag free as possible. This includes working not just in MAME but in PC games as well. The reason for considering an Xbox 360 based solution is because most PC games don't seem to properly support keyboards, or if they do they don't fully support them for 2 players and customizable menu navigation... so it completely fails requirement #1.

honestly arguing about the best input method is completely worthless conjecture without any actual evidence to back it up. You say that no one's going to waste their time with it, but then you go off ranting about how much better one option is over another. I don't know how you can make that claim without any actual evidence to back it up.

[bulbousbeard]

most PC games don't seem to properly support keyboards

That's a joke, right? Most PC games support keyboards better than they support gamepads. The outlier here is Warner Bros/Netherrealm/Midway/whateverthehelltheywanttobecallednow, which is apparently a terrible company who doesn't know how to make a PC game. Ultra Street Fighter IV works perfectly with keyboards. Virtually every emulator works great with keyboards.

Raw Input is trivial to support with keyboards, and we have keyboard encoders for arcade controls. The problem's already solved. Instead of bending over for crappy games, you should be yelling at Midway/High Voltage to fix their broken products. There is NO excuse for PC games using the Unreal Engine to not support remappable keyboard controls properly.

[yotsuya]

The 360 gamepad is the defacto standard for pc games now to the point of where if you plug one in, a game automatically configures itself optimized for the gamepad.  They don't have any more lag than any other device.  For the record keyboard encoders don't use raw input in the lagless sense that he's talking about.  It's a USB device... data is still sent in packets.  Any device in which there are more inputs than pins on the connector have some degree of lag as the data is sent serially.

 

Good job on applauding factually incorrect information. 

I think he's applauding the fact Howard knows how to express an opinion without sounding like a dick. Take notes.

Calling someone else a dick is worse than anything I wrote. Take notes.

I didn't call you a dick. I said Howard knows how to communicate without sounding like one. But if the condom fits....

[bulbousbeard]

http://forum.arcadecontrols.com/index.php/topic,145174.0.html

We'll settle this once and for all. 

[twistedsymphony]

most PC games don't seem to properly support keyboards

That's a joke, right? Most PC games support keyboards better than they support gamepads. The outlier here is Warner Bros/Netherrealm/Midway/whateverthehelltheywanttobecallednow, which is apparently a terrible company who doesn't know how to make a PC game. Ultra Street Fighter IV works perfectly with keyboards. Virtually every emulator works great with keyboards.

it's not a joke I'm sure there are a lot of PC games that work great with a keyboard but when it comes to arcade-style games, in my experience the vast majority of the games I've tried to setup has either not supported 2 players on 1 keyboard, or had some keys that could not be remapped, requiring me to find some kind of hack in order to make it work.

I haven't setup USFIV but SSFIV definitely needed a work around to get 2 player keyboard support, as did Street Fighter X Tekken, as did Double Dragon Neon, all of the Melty Blood Games (which don't support remapping), all of the Touhou games (which don't support remapping).

Then there are all of the TTX games where are a whole other pain in the ass, especially games like Contra and Samurai Shodown but would be much easier to setup with a joystick and xpadder.

http://forum.arcadecontrols.com/index.php/topic,145174.0.html

We'll settle this once and for all. 

Excellent, thanks for doing that, I'm curious to see what the outcome is. This is the best thing to come out of this thread so far.

[Malenko]

Some anti-trust action needs to be taken against Microsoft again. How is it not a conflict of interest for Microsoft to effectively screw over every 3rd party gamepad manufacturer to push their own gamepads?

Here is where you lose me. How has Microsoft done this?

[bulbousbeard]

Some anti-trust action needs to be taken against Microsoft again. How is it not a conflict of interest for Microsoft to effectively screw over every 3rd party gamepad manufacturer to push their own gamepads?

Here is where you lose me. How has Microsoft done this?

Instead of creating a flexible API for 3rd parties to make all kinds of different joysticks, they deprecated Direct Input and forced XInput on everyone, which is an API tailored to one specific type of gamepad: the Xbox gamepad. When your API supports basically one piece of hardware, what's the point? You might as well just hardcode everything anyway. They then leveraged their sway over console third parties to get them to stop supporting Direct Input, so your only option is either running a crappy XInput emulator or not being able to use your 3rd party joystick. Due to attrition (who really wants to run some stupid gamepad emulator for EVERY game?), people just give up and buy Microsoft's hardware. They're using their console and operating system to force hardware on people. It's absolutely a conflict of interest. It would be like Microsoft coming out with a graphics card and then making Direct3D 13 only work properly on it, using their Xbox influence to get developers to only make games for Direct3D 13, and Nvidia and AMD would have to write Direct3D 13 emulators just for their graphics cards to be able to play games.

Also, let's keep in mind that, due to the stupidity of XInput's implementation, it will eventually die off down the road when Microsoft finally loses its monopoly, and we'll be stuck running XInput emulators on future hardware probably just to be able to play this generation of games with a gamepad.

It's ---smurfing--- stupid.

[Malenko]

Instead of creating a flexible API for 3rd parties to make all kinds of different joysticks, they deprecated Direct Input and forced XInput on everyone, which is an API tailored to one specific type of gamepad: the Xbox gamepad. They then leveraged their sway over console third parties to get them to stop supporting Direct Input, so your only option is either running a crappy XInput emulator or not being able to use your 3rd party joystick. Due to attrition (who really wants to run some stupid gamepad emulator for EVERY game?), people just give up and buy Microsoft's hardware. They're using their console and operating system to force hardware on people. It's absolutely a conflict of interest. It would be like Microsoft coming out with a graphics card and then making Direct3D 13 only work properly on it, using their Xbox influence to get developers to only make games for Direct3D 13, and Nvidia and AMD would have to write Direct3D 13 emulators just for their graphics cards to be able to play games. It's ---smurfing--- stupid.

So no one else can write an API  for Windows, only Microsoft can? seriously asking.

Your GPU "example" isnt accurate either. From what I gather you are implying that only microsoft can make controllers that conform to "360 standards" when in fact I know that both Razer , Saitek, and MadCatz make controllers that work on 360 and by extension, the PC. As for encoders , the PS360+ encoder can function as  USB input for PC, PS3  and for 360 , and my Fanatec wheel works on PS3, 360 and PC. All 3rd party devices that work on PC and 360 with no Xinput emulators.

[headkaze]

unlike mice and keyboards, there are no standards for joystick data

There is a standard for joystick data; it's called a joystick/gamepad HID collection descriptor. How else would DirectInput interpret the data if there wasn't? You have to parse the HID report descriptor and take note of the input types and data ranges. By the time you wrap all that data you may as well be using DirectInput. It's really not that difficult using RawInput though, as you can see from this C++ source code.

A typical joystick will have x, y, z, rx, ry, rz, hatswitch and ~10 buttons. Reading this data is standardised by following the report descriptor. Once you know how to interpret the data and normalise the value ranges to whatever you need, the only thing left is to assign the inputs to the actions in the game. These should all be customisable by the user so the fact the layout may be different from manufacturer to manufacturer is irrelevant.

I'm guessing the XBox 360 controller is Microsoft's attempt at standardising the layout of inputs. Isn't that what you want; a standard? Any other manufacturer can use the same report descriptor if they so chose. They can even copy the same stick and button layout. As far as XInput is concerned if it's hard coded to only support Microsoft gamepads then I will admit that that is a pretty ---smurfy--- move on their behalf. XInput should really be available to use by any manufacturer even if the only restriction was to follow the standards set by Microsoft's own gamepad design.

[Howard_Casto]

It's not hardcoded to only support microsoft gamepads, I'm using a madcatz gamepad right now, it's just hardcoded to have inputs in a set order regardless of control type and even if an input isn't used, an "empty" slot is there so that there isn't any need to enumerate axis and what not.  There are different classes, like racing wheels and ect, BUT they use the same resolution of analog data, so the point is while that info is available to the developer, they can ignore it and still get good results.

So you'll always have x,y,z and rx,ry,rz even on devices that don't have those inputs like a fight pad.  There will always be a hat (dpad) and more importantly, button 1 is ALWAYS A, button 2 B, ect....  This is how modern games can just assign a layout automatically... a standardization of the button order makes things easier.  This is why it may appear that it's Microsoft only pads, because obviously a sony or Nintendo gamepad won't conform to this standard and thus won't get xinput approval.  Then again, I very much doubt those companies want to be xinput compliant. 

Sadly xinput might not be a thing long-term.... xb1 gamepads don't use xinput, but pc game developers like the standard so much that they are still using it for their games even though the 360 is last gen tech.

[Howard_Casto]

But just to put a pin in this argument once and for all, competitive fighting game players often use ps3 or 360 compatible fight sticks for practice, even if they practice on the pc... so if it's good enough for them.....

[twistedsymphony]

But just to put a pin in this argument once and for all, competitive fighting game players often use ps3 or 360 compatible fight sticks for practice, even if they practice on the pc... so if it's good enough for them.....

That was my original thought on the matter too. The PS360+ seems to be the gold standard for custom flight-sticks within the FGC so I was planning on swapping from the i-pac to a pair of those. If anyone is obsessive about lag it's competitive gamers. I'd suspect if there were any real problems they'd be people within that community making a stink about it.

In any case, I'm anxious to see what kind of results Calamity comes up with in his test between a keyboard input and an X360 pad, hopefully it can put this debate to rest.

[Howard_Casto]

I honestly don't think there was ever a debate though.  If we were in said FGC it might be different, but for our purposes... "hmm, this works" is about all we need. 

You'll notice even Andy and Randy have kind of shifted their products towards showing up as a joystick, because in this day and age keyboard encoders, sadly, are quickly becoming outdated tech. 

[bulbousbeard]

unlike mice and keyboards, there are no standards for joystick data

There is a standard for joystick data; it's called a joystick/gamepad HID collection descriptor. How else would DirectInput interpret the data if there wasn't? You have to parse the HID report descriptor and take note of the input types and data ranges. By the time you wrap all that data you may as well be using DirectInput. It's really not that difficult using RawInput though, as you can see from this C++ source code.

A typical joystick will have x, y, z, rx, ry, rz, hatswitch and ~10 buttons. Reading this data is standardised by following the report descriptor. Once you know how to interpret the data and normalise the value ranges to whatever you need, the only thing left is to assign the inputs to the actions in the game. These should all be customisable by the user so the fact the layout may be different from manufacturer to manufacturer is irrelevant.

I'm guessing the XBox 360 controller is Microsoft's attempt at standardising the layout of inputs. Isn't that what you want; a standard? Any other manufacturer can use the same report descriptor if they so chose. They can even copy the same stick and button layout. As far as XInput is concerned if it's hard coded to only support Microsoft gamepads then I will admit that that is a pretty ---smurfy--- move on their behalf. XInput should really be available to use by any manufacturer even if the only restriction was to follow the standards set by Microsoft's own gamepad design.

I had to smile when you linked that code example, because it doesn't work with Xbox 360 gamepads. 

It is not as easy as you think it is. Like you said, if it was, gamepads would use Raw Input in MAME today.

[bulbousbeard]

I honestly don't think there was ever a debate though.  If we were in said FGC it might be different, but for our purposes... "hmm, this works" is about all we need. 

You'll notice even Andy and Randy have kind of shifted their products towards showing up as a joystick, because in this day and age keyboard encoders, sadly, are quickly becoming outdated tech.

The real problem is with emulation, you're guaranteed at least 1 frame of extra input lag over the real hardware _to begin with_. You have to eliminate lag anywhere you can to make emulation good.