iDevGames Forums
Input Management - Printable Version

+- iDevGames Forums (
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: Input Management (/thread-2374.html)

Input Management - bmantzey - Sep 23, 2008 06:42 PM

I have a very efficient input management system written for Windows that uses DirectInput and XInput and I'd like to write a similar system for Mac. I'm looking for efficiency. C is fine but I'd prefer C++. I don't care about if the class supports the 360 controller but it would be nice if it did. Joysticks would be nice as well.

I've been looking at IOKit (HID) because it seems to be the lowest level but it's strangely complicated. I found a test app that runs a loop that detects every device on the computer but I don't see any way to determine if it's a keyboard, mouse, or what it is. There's got to be a way to know what's a keyboard and load it as such.

Perhaps IOKit isn't the best way to start. Is there anyone out there with some experience as to what's an efficient way to provide a wrapped up class to support keyboard and mouse? I don't care about level of complexity. I can do the research, I just want to know the best way to go before I begin. Thanks!


Input Management - Skorche - Sep 23, 2008 07:11 PM

Say what you will about SDL, but I really like it's event handling subsystem. It's really the only reason I keep coming back. It's easy to wrap you mind around, is cross platform, and is consistent across different kinds of input devices (including joysticks).

Out of curiosity, what's the big deal about it being very efficient? It's not like event handling code is going to use a lot of CPU even if it's insanely overcomplicated.

Input Management - bmantzey - Sep 23, 2008 07:39 PM

You have a point about efficiency but here's my philosophy: it all adds up. If everything "isn't that bad", it will sum up to be kinda not so much good. At a small scale, you'll never know the difference but if your programming habits are of the utmost efficiency, you expand your scale.

Tell me more about SDL, I am not going to turn my nose up to it. That's not the Carbon event handling system is it? If it is, I've dealt with it a little bit and to me it's the equivalent of GetAsyncKeyState() in Windows, which is fine for testing but for release code, I don't think it's a good idea. I tried to wrap it up and it's really hard to link.

Sadly, I don't know much about the Mac side of programming as my training has been exclusively Windows, with some very limited ARM emulation (GBA) and that's about it. I'm definitely open to discuss this, deeply or not. Thanks a lot!


Input Management - OneSadCookie - Sep 23, 2008 08:24 PM

HID Manager (IOKit) is the only way to talk to gamepads & joysticks on Mac OS X. There are two APIs, the old one, deprecated in 10.5, and the new one, unavailable before 10.5. SDL is a (fairly thin) layer above the old API. There is plenty of Apple sample code available. It's verbose, but I didn't find it particularly complex.

If you only want to read mice, keyboards, and potentially tablets, there's little reason to step outside the standard Cocoa event loop.

Input Management - AnotherJake - Sep 23, 2008 08:36 PM

OneSadCookie Wrote:There are two APIs, the old one, deprecated in 10.5, and the new one, unavailable before 10.5.

The old HID manager was deprecated?! I was so frustrated with HID that I didn't even look (or ignored it completely). I'm shocked. That's *great* news!

I've heard it doesn't suck as bad. Is that true too?

Input Management - bmantzey - Sep 23, 2008 10:17 PM

What, wait, what? I didn't get any deprecation warnings when I compiled the IOKit. I'm running 10.5.5, what's new?

SDL is an event system basically, which might be thin in it's internal programming but the thing about an event system is, even if it is threaded, it puts extra onto the stack. Now, this might not be a big deal to you but there are more efficient ways out there for reasons.

If I could master the IOKit enough to write a wrapper for it that will provide keyboard, mouse, joypad, and joystick support, I think I might have something great as a tool of my trade.

From what I gather, it's like a stare-down with Medusa to try to deal with this HID Manager but I refuse to cower to it. Does anyone have any resources other than the Apple support site that might be useful in figuring out how to pick any of the above devices out of the dictionaries that the HID Device Manager loops through and then dealing with the object that is found, once it's found?

This seems like a challenge, which makes me more interested. Now, what's this great news that Jake was talking about with 10.5 and a deprecated HID Manager? What's replaced it?



Input Management - Cochrane - Sep 23, 2008 11:36 PM

The new API is described in detail at . To find out what type a particular device is, get the UsageKey and UsagePageKey property. All possible values for these are described in IOHIDUsageTables.h. All you're normally interested in is the GenericDesktop page and there Mouse, Joystick and Keyboard (notice that Gamepads get reported as Joystick as well).

Input Management - OneSadCookie - Sep 24, 2008 02:57 AM

You're right, it doesn't seem to be marked deprecated, it's just moved to a header called "IOHIDLibObsolete.h" Smile

The new API's supposed to be better, but I haven't tried it. AFAICT it doesn't solve any of the major issues with HID as a device abstraction (namely, the hardware all sucks and really needs custom drivers or configuration, which only Apple could hope to provide and they don't want to shoulder that burden), it just saves you from the COM-horror of the old API...

and bmantzey: you're nuts worrying about the "efficiency" of your input system. It doesn't matter. It could run 50x slower than it does without affecting you. Two extra stack frames from SDL won't make a difference you can measure... and that assumes they're *not* doing useful work, which they probably are.

Input Management - TomorrowPlusX - Sep 24, 2008 04:41 AM

For what it's worth, there's a great ObjC wrapper around the old HID API, DDHidLib. I'm using it, and it's awesome.

Also, as others have said: Concerning yourself with having the highest performance HID system is really just a way to generate gray hair. It will waste your time, and it will achieve nothing. The input system is using so little of your CPU -- even if you wrote it entirely in python and forced the runtime to run in interpreted mode -- you'd never notice.

As the saying goes, profile before you optimize. I can tell you that DDHidLib doesn't even show up when I profile my code.

Input Management - bmantzey - Sep 24, 2008 06:26 AM

Okay okay okay, but I still like to be as efficient in my habits as possible. Rasp Thanks for all the great references!!