Console-style gamepad/input library

I don't own a console, so when my family members visit, our gaming is on a Mac. As would be expected, they find the mouse and keyboard very difficult. Gaming on the Mac would be so much better with gamepad support in ALL games; not just the token few. InputSprocket is RIP and it seems HID isn't happening. Most likely, we won't ever see anything DirectX level on the Mac released by Apple.

In speaking with Aaron, of StrangeFlavour, we both agree that a console-style input library would be super for the Mac. Something small, easy, user-friendly, and that dosn't try to do everything under the sun.

We have a great number of very advanced software engineers here, so I'm wondering if 2 to 3 of you would get together, map out the project and code it. Consider releasing it as open source, or at a very very low shareware fee. We can "brand" (logo, etc) the library and market the technology for all Mac game developers to utilize.

Write the interface C style. C++ users can wrap it with extra junk if they want

To read the sticks, I should be able to use a command like Gamepad = ReadGamepad(n);

and then Gamepad should be a really simple structure with dpad direction, couple of analog stick pairs (x,y for each) and a bunch of buttons.

setup should be a single command. Optionally, some extended setup system that lets the game fill the required values for what button = what button with its own graphical interface would also be a good plan.

anyone using handles or Apple style novela length function names will be shot on sight

For a start, the architecture of the library has to support all sorts of users (this is where InputSprocket fell down; not everybody wants a Mac UI popping up over their game, for example).

For another, HID devices are so horrible on average that most require "tweaking" -- giving the buttons sane names, for example. That means that any such library must come with an extensive database of controllers and their oddities.

I agree on those points OSC, so maybe a more 'tough' solution is in order.

1) Only support HID devices that are within bounds of being practical. ie don't support ones that need too much tweaking (although that probably brings it down to one or two controllers). If there's a rash of decent games that support that subset, then there's more likelyhood that people will just buy those controllers.

2) Only support a specific subset of buttons (ie what you'd get on a current console controller). That makes setting up a Mac UI or game UI settings page a bit more practical.

My experience is that some of the most common controllers are also the most badly set up. The Cyborg3D joystick is a good example of this - I know several people who have one, and I have one myself. For some inexplicable reason, all its axes stretch from 0-200 with 100 being the idle position, instead of using the entire 0-255 range. This means that without some kind of calibration features ingame, it constantly slews to the side in each axis. Auto calibration features provided by games can help to fix this to some extent, but until you've moved every axis to its extents, there's no way for the game (or the player, even) to realise what's wrong with the controller unless it has been specifically told about it in advance.

I also have a Gravis Xterminator joypad, which claims that one of its D-pads is an axis (!) and has pretty odd button mappings, and again, I know a couple of people with this controller. I'd go as far as to say that controllers which work properly are the exception rather than the rule.

One possible solution is to allow savvy users to generate configuration files which fix a particular kind of controller, and get them to send these files in so they can be included in the next release. I believe Amelio (or the other similar thing) was supposed to work like this, and that's more or less how Unity is handling HID support at present.

NCarter Wrote:My experience is that some of the most common controllers are also the most badly set up. The Cyborg3D joystick is a good example of this - I know several people who have one, and I have one myself. For some inexplicable reason, all its axes stretch from 0-200 with 100 being the idle position, instead of using the entire 0-255 range. This means that without some kind of calibration features ingame, it constantly slews to the side in each axis. Auto calibration features provided by games can help to fix this to some extent, but until you've moved every axis to its extents, there's no way for the game (or the player, even) to realise what's wrong with the controller unless it has been specifically told about it in advance.

I also have a Gravis Xterminator joypad, which claims that one of its D-pads is an axis (!) and has pretty odd button mappings, and again, I know a couple of people with this controller. I'd go as far as to say that controllers which work properly are the exception rather than the rule.

One possible solution is to allow savvy users to generate configuration files which fix a particular kind of controller, and get them to send these files in so they can be included in the next release. I believe Amelio (or the other similar thing) was supposed to work like this, and that's more or less how Unity is handling HID support at present.

Yup. This is pretty much the problem OSC mentioned and one that's been a dead end for HID setups that try and cover all bases.

Simplest thing would be to find out if anyone does a decent controller that works properly and just support that. As game controllers aren't huge on the Mac at the moment, it's probably easier to write a decent HID system and get everyone to buy the correct controller when they start playing games that use controllers.

Zwilnik Wrote:Simplest thing would be to find out if anyone does a decent controller that works properly and just support that. As game controllers aren't huge on the Mac at the moment, it's probably easier to write a decent HID system and get everyone to buy the correct controller when they start playing games that use controllers.

I don't think you can ask people to only use a specific selection of controllers. People will only discover they've bought the 'wrong' controller when they try your game. It's not likely to lead to customer satisfaction.

For what its worth, HID provides a pseudo-calibrated floating point value for axes. This works with the Cyborg 3D, and apparently lots of things.

If there is interest, I have some half assed ObjC++ code that does HID input device management, so far in a reliable manner.

For all I know about HID, you just can't expect controls to be named the same on all devices, so the user has to set up an initial config to his liking, though the sticks and gamepads I had feedback for so far worked as expected.