Key blocking - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: Key blocking (/thread-8088.html)
Key blocking - Miglu - Sep 8, 2010 02:39 PM
When I loop through key input characters using the method that is shown in http://www.idevgames.com/forum/showpost.php?p=138018&postcount=5 and have NSLog(@"%X", c) in the NSKeyDown section, I get this kind of console output when I press the right arrow key and then the left, keeping them down:
Quote:2010-09-08 22:30:25.047 CocoaGL[5907:a0f] F703
charactersIgnoringModifiers returns an NSString according to the Event Handling Guide. It should have two characters when both keys are pressed so when it is looped through, it should produce this kind of console output:
Quote:2010-09-08 22:30:25.047 CocoaGL[5907:a0f] F703Why does one key block the other?
RE: Key blocking - AnotherJake - Sep 8, 2010 03:01 PM
(Sep 8, 2010 02:39 PM)Miglu Wrote: It should have two characters when both keys are pressed so when it is looped through
No it shouldn't. The message is for "key down" not that "keys are down". That means it only reports when a key is initially pressed. A key will be reported as being pressed again repeatedly automatically at the system key repeat rate. This is exactly why I use that technique in that link; it filters the information from the system so it makes sense for gaming input. If you want to read that the arrows are being held down at the same time, use key[LEFT_ARROW] and key[RIGHT_ARROW].
The reason you might have a string of more than one character in the keyDown method is if there was more than one key down event since the last time the method was called. That might only happen if someone is typing ridiculously fast. Again, it does not contain the keys that are being held down.
RE: Key blocking - Miglu - Sep 8, 2010 03:19 PM
Thanks. However, if I hold down the left and right or the up and down arrow keys at the same time, and then press the arrow keys that are perpendicular to them, the perpendicular ones are not outputed to the console. When I let go of the parallel pair, they are outputed. Something is blocking them. When I press only one key and not its parallel pair, pressing a perpendicular one works fine. What is the problem?
RE: Key blocking - AnotherJake - Sep 8, 2010 03:44 PM
Oh, I see what you're saying. Yeah, I don't know WTF is up with that. I've never noticed that. Other keys on the keyboard apparently do that too. Weird. Like I can do "a" and "d" and either "w" or "s", but if I do "w" and "s" and then either "a" or "d" it doesn't pick those up for some reason. It's like holding down two keys on separate rows stops any further key downs until one of them is let up.
... hmph... in all these years I've never noticed that.
RE: Key blocking - OneSadCookie - Sep 8, 2010 03:50 PM
This is well-known, certain key combinations on every keyboard cannot be simultaneously detected by the hardware. Nothing you can do (and the combinations vary by keyboard model).
RE: Key blocking - AnotherJake - Sep 8, 2010 03:53 PM
Well whudayaknow ... learn something new every day. I knew older keyboards had issues with certain key combinations, but I thought all those problems went away in the USB age.
I guess it's not much of a problem, at least not for me, since I never noticed it.
RE: Key blocking - AndyKorth - Sep 9, 2010 08:23 AM
We've run into this problem many times in games we've done. In many popular windows keyboards, there's some sort of interaction between the arrow keys, the space bar, and the left shift key. Obviously these are all pretty important in a game. The client's solution was to use the entire bottom row (Z,X,C,V,B,N,M) to shoot.
I found this interesting article about how keyboards work and the source of some of these issues: http://www.dribin.org/dave/keyboard/one_html/
RE: Key blocking - Miglu - Sep 9, 2010 08:45 AM
It is strange that every new version of Mac has improved graphics, processor and memory, but this problem is never solved.
RE: Key blocking - OneSadCookie - Sep 9, 2010 10:52 AM
Because it's only ever a problem for games, and then rarely.
RE: Key blocking - Miglu - Sep 10, 2010 09:22 AM
Thanks. How to do a test to find out if a character is space, which does not have a constant like NSRightArrowFunctionKey? I tried if(c == U+0020), but it did not work.
RE: Key blocking - AnotherJake - Sep 10, 2010 09:25 AM
Just like regular alpha numerics:
if (key[' '])
if (keyDown[' '])
RE: Key blocking - Miglu - Sep 10, 2010 09:30 AM
Thanks. I will now ask a question that is offtopic but not significant enough to deserve its own thread: I have cpSpaceAddCollisionHandler(space, 1, 2, begin, NULL, NULL, NULL, NULL) in my initialization method and get the error "Invalid use of void expression" for it. I have put the two shape types on some shapes, so that is not the problem. What is the problem?
RE: Key blocking - Miglu - Sep 10, 2010 10:40 AM
Is it that I do not have any arbiter method call? (Are arbiters compulsory?) It is difficult to understand from the documentation why arbiters are needed, as a collision handler already exists in Chipmunk.
RE: Key blocking - OneSadCookie - Sep 10, 2010 10:47 AM
It means you have something which has type void (likely a call to a void function) somewhere where another type is needed.
RE: Key blocking - Miglu - Sep 10, 2010 11:21 AM
cpCollisionBeginFunc's type is int, so I changed begin's type to int, which solved the problem. However, if I put a cpCollisionSeparateFunc callback into the collision handler's method call, the same problem occurs. cpCollisionSeparateFunc's type is void, so why is the compiler still whining?