Console-style gamepad/input library

Founder
Posts: 1,138
Joined: 2002.04
Post: #1
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.

Cheers,

Carlos A. Camacho,
Founder
iDevGames
Moderator
Posts: 335
Joined: 2002.04
Post: #2
My guidelines:

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

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 Smile
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
This is not a simple question.

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.

Combined, these issues have served to doom every such project that's been started. The Amelio Game Input Library, for example, was created by an iDG member, but was never able to gain traction. See this thread: http://www.idevgames.com/forum/archive/i...-1985.html

I don't want to be a naysayer, but people have tried this and failed. Anyone starting again better have a good idea how they're going to solve the inherent problems with it.

In a lot of ways, SDL has the best solution, by providing virtually nothing but raw inputs from the device.

There's also a Java library (part of LWJGL) that does something similar. Worth a look.
Moderator
Posts: 335
Joined: 2002.04
Post: #4
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.

SDL is ok, but I'm still not a fan of using it in a project.
Moderator
Posts: 365
Joined: 2002.04
Post: #5
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.

Neil Carter
Nether - Mac games and comic art
Moderator
Posts: 335
Joined: 2002.04
Post: #6
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.
Moderator
Posts: 365
Joined: 2002.04
Post: #7
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. Wink

Is there a downside to the user-feedback config file idea?

Neil Carter
Nether - Mac games and comic art
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #8
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.
Member
Posts: 446
Joined: 2002.09
Post: #9
A high level input library would be nice, but we've kinda been through this before...
Luminary
Posts: 5,143
Joined: 2002.04
Post: #10
I think that thread has better discussion; I'll lock this one and we can go back over there. Perhaps it'll even summon Ivan if we do Smile
Thread Closed 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Viewing console output while running an app in Instruments TomorrowPlusX 1 4,830 Oct 5, 2011 04:51 AM
Last Post: TomorrowPlusX
  XCode combining debugger and console?? Toontingy 2 5,484 Feb 16, 2010 07:55 PM
Last Post: Toontingy
  HID Input Library - give me your wishlist Fenris 28 12,316 Jan 8, 2007 10:16 PM
Last Post: unknown
  Game Console Programming Nick 11 7,829 Nov 26, 2004 02:33 PM
Last Post: KenD