asdzxc, every game has a baseline set of requirements and things it doesn't support.

ApochPiQ, can you elaborate on why XInput is crap? I've used it a bit, but it seems really nice to me. I'm very interested in your insight. You point out all these quirks with other controllers, and how they all behave differently. Isn't that exactly what XInput does away with?

Quote: Original post by ApochPiQ
It's much the same as supporting both OpenGL and DirectX from the same graphics engine: while it is technically possible and even somewhat feasible, it takes a monumental amount of effort to actually pull it off.

Again, i'm sure you know much more about the issues than me, but isn't comparing the controller interface to the graphics interface a little far out? And is this not a job only done once for the engine in use, as there aren't fancy new features added every few months?

I'm not talking about having nice mappings for every controller out there, if necessary everyone should define them on his own in the menu.

Call me lazy all you want, but I'd rather have my teeth drilled than go back to supporting DirectInput and the 8 million variations of gamepads/joysticks/buttons/axes/throttles/pedals/whatever. At least with XInput you have a standard set of buttons and features you can target.

Quote: Original post by Daaark
ApochPiQ, can you elaborate on why XInput is crap? I've used it a bit, but it seems really nice to me. I'm very interested in your insight. You point out all these quirks with other controllers, and how they all behave differently. Isn't that exactly what XInput does away with?

XInput kills off some of the nicer axes and input types that used to exist in DirectInput (or at least maps them in stupid ways). It's also a righteous pain to get smooth keyboard support working. Basically, XInput was designed to make the 360 controller easy to code for on Windows; but there's a lot of minutia that makes supporting other "classic" controllers virtually impossible. Some of the cooler joysticks from Saitek simply lose half their capabilities, for instance.

For the average game, sure, this isn't a big deal; but when you're writing a high-end flight-based game that really shines with joystick support, it's highly frustrating. We actually have to support two entire input paths now, so that people with the older controllers can actually use them. Oh, and have fun figuring out what to do when you get contradictory input from both paths.

Quote: Original post by maximAL
Again, i'm sure you know much more about the issues than me, but isn't comparing the controller interface to the graphics interface a little far out? And is this not a job only done once for the engine in use, as there aren't fancy new features added every few months?

I'm not talking about having nice mappings for every controller out there, if necessary everyone should define them on his own in the menu.

No, it's not "a little far out." I'll concede that the majority of games have pretty trivial input requirements, but there are exceptions (like X).

Setting up controller mappings isn't just a simple matter of "axis X goes to this, button Y goes to that." Different controllers report different features in different ways. For instance, what might be considered an input axis on one joystick will be a slider axis on another; what might be a multi-way switch could be reported as a series of individual buttons.

The trick is that you have to try and predict every different way a controller might report its capabilities, so that you can set up remappings in a sane way.

I'm not trying to say that it's nearly as involved as building a graphics engine. What I'm saying is that the concept of supporting two different input APIs isn't as simple as you think. It costs more than just (X+Y), as I said earlier.

Quote: Original post by ApochPiQ
Setting up controller mappings isn't just a simple matter of "axis X goes to this, button Y goes to that." Different controllers report different features in different ways. For instance, what might be considered an input axis on one joystick will be a slider axis on another; what might be a multi-way switch could be reported as a series of individual buttons.

Yeah, but this problem can easily be avoided by creating a simple GUI that allows the user to select a function, then press a button or move an axis on his controller to map the appropriate input, without the programmer needing to hardcode anything.

Quote: Original post by asdzxc
Yeah, but this problem can easily be avoided by creating a simple GUI that allows the user to select a function, then press a button or move an axis on his controller to map the appropriate input, without the programmer needing to hardcode anything.

"Easy" and "simple" are words that do not even remotely begin to apply to this.

Besides, what do you do if you have a joystick that constantly sends a "button down" signal when a specific switch is in a specific position? (Yes, there are lots of sticks that do this.) You'll get false positives every time, and I guarantee that'll be more annoying to the player than you think. What do you think would work out best, a player plugging in his controller and having it work, or spending 20 minutes yelling at the monitor because it's doing something technically correct that makes no sense to him?


Seriously, I'd suggest you actually go implement a real-world game input system before you sit around presuming to tell the rest of us what we're doing wrong.

Also, go actually ship some real software under real budget and schedule constraints. When it comes time to prioritize bugs, "game crashes every time you kill the big bad boss" is slightly more important than "rare controller model Foo occasionally hiccups for a bit."

Quote: Original post by ApochPiQSetting up controller mappings isn't just a simple matter of "axis X goes to this, button Y goes to that." Different controllers report different features in different ways. For instance, what might be considered an input axis on one joystick will be a slider axis on another; what might be a multi-way switch could be reported as a series of individual buttons.

And thats not possible to edit in a config menu by the user as a last resort?

Quote: Original post by asdzxc
In any case, I cannot see how anyone could defend the use of an input API which supports only a single device, especially when it replaces what was already a perfectly functional system. Input handling is game programming 101, and were talking about teams of professionals with multi-million dollar budgets who can't even get a simple thing like this right - it just boggles my mind.

And you've shipped how many games, exactly?!? [rolleyes]

I started out on the wrong foot here, I shouldn't have leveled the charge of "sheer laziness" against the development community and for that I apologize.

I truly hope we can reach some common ground here regarding what can be considered an acceptable level of controller support - both from the consumers perspective of usability, and the developers perspective of difficulty and required development time.

I prefer to discuss things by way of example, so please excuse the following rather large post. Also, instead of having to prefix every sentence with "I believe" or "in my opinion", please consider all of the following to be IMHO. My first post was far from humble I'll admit.

What follows is a list of examples of different real-world implementations, ordered from what I (a very long-time gamer who dabbles in a bit of programming) would consider easiest for the developer, and perhaps not so nice for the consumer.

1.) X-Input support only - Game Example: Operation Flashpoint: Dragon Rising. One only needs to search their forums for a few seconds to discover examples of the frustration and consumer backlash such a seemingly little thing like this can cause. However, even in this dire case there is a workaround. By way of an X-Input emulator/wrapper one can fool his machine into believing an X-360 controller is connected, but having to use an emulator (and custom map inputs for it) is kinda off-loading a lot of work onto the consumer who just wants to plug & play.

2.) X-Input support with a single set of hardcoded DirectInput mappings - Game Example: Batman Arkham Asylum. This level of support is actually not that bad, provided the specific hardcoded axis and button configuration chosen by the developers is provided to the consumer! With this information, the user can then re-map his own controller to match, such as what can be done in the manufacturer provided utilities of many popular controllers. Perhaps the mappings read by the program could be stored in a user editable text file under such an implementation, however this really is verging into the territory of the next method in my list.

3.) An in-game re-mapping GUI which accepts any and all DirectInput information coming from the controller and maps it to an action selected by the user within said GUI - Game Example: Battlefield 2. In my opinion, this is the "sweet spot" of compromise between consumer ease of use, and developer effort. Under such a system, the need to hardcode support for speciffic controllers is minimised and at best, eliminated. Note: If necessary, support for regular XInput could be included as an option for those users who actually posses an X360 controller - assuming the functions of an X360 controller cannot be accessed for whatever reason with normal DirectInput.

4.) Supporting "8 million variations of gamepads/joysticks/buttons/axes/throttles/pedals/whatever" as MJP put it by detecting the unique identifier of the controller and having the developer define mappings for every single one of them in existance. I'm sure we can all agree this would require the most developer effort and really is basically impossible in this day and age.

Can we find some common ground here guys, pretty please?

[Edited by - asdzxc on November 17, 2009 5:51:20 AM]

Quote: Original post by asdzxc4.) Supporting "8 million variations of gamepads/joysticks/buttons/axes/throttles/pedals/whatever" as MJP put it by detecting the unique identifier of the controller and having the developer define mappings for every single one of them in existance. I'm sure we can all agree this would require the most developer effort and really is basically impossible in this day and age.

BTW, this calls for a lib, doesn't is? No one done it yet?