No, really. What is the proper way to handle keyboard input in a game using Cocoa?

17
votes

Let's say you're creating a game for Mac OS X. In fact, let's say you're creating Quake, only it's 2011 and you'd prefer to only use modern, non-deprecated frameworks.

You want your game to be notified when the user presses (or releases) a key, any key, on the keyboard. This includes modifer keys, like shift and control. Edited to add: Also, you want to know if the left or right version of a modifier key was pressed.

You also want your game to have a config screen, where the user can inspect and modify the keyboard config. It should contain things like:

  • Move forward: W
  • Jump: SPACE
  • Fire: LCTRL

What do you do? I've been trying to find a good answer to this for a day or so now, but haven't succeeded.

This is what I've came up with:

  • Subclass NSResponder, implement keyUp: and keyDown:, like in this answer. A problem with this approach, is that keyUp: and keyDown: won't get called when the user presses only a modifier key. To work around that, you can implement flagsChanged:, but that feels like a hack.
  • Use a Quartz Event Tap. This only works if the app runs as root, or the user has enabled access for assistive devices. Also, modifier key events still do not count as regular key events.
  • Use the HIToolbox. There is virtually no mention at all of it in the 10.6 developer docs. It appears to be very, very deprecated.

So, what's the proper way to do this? This really feels like a problem that should have a well-known, well-documented solution. It's not like games are incredibly niche.

2
cocoamacos
FWIW, I don’t think -flagsChanged: or NSFlagsChangedMask is a hack. It is the documented way of being notified of changes in modifier keys like Control. – user557219
I didn't mean to say that flagsChanged: is a hack, but rather that using it for this purpose feels like a hack. If you're writing, say, a text editor, treating modifier key events differently is a great idea! However, if you want to know which key was just pressed, no matter what kind of key that may be, flagsChanged: does not seem like a good fit to me. Sure, you could store the value of [event modifierFlags] and diff against that -- it could be done -- but it's enough of a kludge that I feel there should a better, more straightforward way. Is there? – sarnesjo
I don’t think there is another way. As far as I can tell, Cocoa follows the reasoning you’ve described: in most cases, modifier keys aren’t relevant by themselves alone. That said, you could abstract -keyDown:, -keyUp:, -flagsChanged: into one or two methods that effectively do the actions in your application — those three methods would simply filter events and call your custom method(s). – user557219
Gah, weird behaviour. I’ve solved it by having a static counter: in your if part, I increment the counter and consider it a key down if the counter is less than 2; otherwise, I decrement the counter and consider it a key up. In the else part, I decrement the counter and consider it a key up. I’ve only done this for a single key; you’d have to have a counter for each modifier key. – user557219
I’m not sure that’s a good solution because that 2 is constant and I guess it’s theoretically possible that the user has more than one keyboard and that 2 should be 4. I can’t test this, though. – user557219

2 Answers

7
votes

As others have said, there’s nothing wrong with using -flagsChanged:. There is another option: use the IOKit HID API. You should be using this anyway for joystick/gamepad input, and arguably mouse input; it may or may not be convenient for keyboard input too, depending on what you’re doing.

1
votes

This looks promising:

+[ NSEvent addLocalMonitorForEventsMatchingMask:handler: ]

Seems to be new in 10.6 and sounds just like what you're looking for. More here:

http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSEvent_Class/Reference/Reference.html%23//apple_ref/occ/clm/NSEvent/addLocalMonitorForEventsMatchingMask:handler: