Supporting more than 4 XInput-capable devices on Windows [RFC]

SDL Development
21

Sorry for getting away from the original topic now but off the top of my head:

  • “Carrotting Brain” supports 4 gamepad players + 2 keyboard players and didn’t go for direct input because of triggers being on the same axis (ref)
  • Swordy: 8 players - Doesn’t work as intented since you can’t extend both arms at the same time. There’s a warning about switching to DirectInput because having triggers on the same axis removes some of the game’s features.(ref: unable to post ref because I’m a new user limited to 2 urls per post)
  • Team Racing League: 6 player racing game didn’t add an option for disabling XInput because of the issue with triggers being on the same axis. (ref)

These are the top of my head ones that didn’t add direct input support because of the same axis issue, or did add support but was negatively impacted because of it. I remember there being several games that had to alter their control scheme for Direct Input becaues of the axis issue as well but that would take some searching for me to dig out. An example of a type of game for more than 4 players that could want to have separate axis trigger control is top down racing games (or 6 player split screen like “The Karters” has) with gas, brake on triggers and combined gas and brake to drift.

22

This looks good, but the patch doesn’t apply cleanly to the code in Mercurial.

Can you create a bug in bugzilla (http://bugzilla.libsdl.org), and attach a tested patch that applies cleanly?

Thanks!

23

Will do! I’ve been working with Electron to resolve some issues with GCC cross-compiling from Mac and other minor quality things, and he’s been testing the patch with his Steam game as well. I will update the bug with a .patch in a couple days. Looks like quite a few changes were made since I pulled from upstream a week ago, so hopefully it should generate a clean patch after I merge those in.

24

Okay, apparently the HIDAPI code underwent a big refactor while I was working on this! I think I’ve got it all merged and settled now, and even found a couple minor bugs while merging. I also updated the hints so “xinput” is split out from “hidapi correlated data from xinput”, so it should be safe for games to set SDL_HINT_XINPUT_ENABLED=0 and they’ll still get great data from (RawInput+XInput) when available, and fall back to DirectInput when not available (because of Valve virtual controllers), while avoiding the XInput-only mode that limits the number of controllers. That’s what I’m doing in Splody now.

New code here patch here. Bug has been updated with the proposed patch.

I’ll strongly consider finishing the Windows.Gaming.Input side of things in a separate patch, once this is merged - sounds like enough games would benefit from that.