Input Management

Member
Posts: 241
Joined: 2008.07
Post: #1
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!

Brandon
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #2
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.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #3
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!

Brandon
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
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.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #5
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?
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #6
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?

Thanks!!!

Brandon
Quote this message in a reply
Member
Posts: 114
Joined: 2005.03
Post: #7
The new API is described in detail at http://developer.apple.com/technotes/tn2007/tn2187.html . 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).
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #8
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.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #9
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.

http://code.google.com/p/ddribin/

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.
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #10
Okay okay okay, but I still like to be as efficient in my habits as possible. Rasp Thanks for all the great references!!
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Process/ Memopry Management in Cocos2D GameGeeeky 0 1,441 Nov 8, 2014 01:49 AM
Last Post: GameGeeeky
  Importance of memory management johncmurphy 11 6,640 Aug 27, 2009 02:54 PM
Last Post: AnotherJake
  Objective C memory management Madrayken 3 2,947 Jul 10, 2009 10:13 AM
Last Post: DoG
  GUI Management Design Nick 14 5,307 Nov 24, 2006 06:07 AM
Last Post: memon
  Input Management chainsawmcgraw 4 3,623 Nov 5, 2003 09:00 AM
Last Post: DoG