Ransom has asked for the wisdom of the Perl Monks concerning the following question:

Well monks, here's another round for you.

I'm using SDLx::App and SDL::Events to control a simple test object on screen. I was finally able to handle multiple arrow key events for smooth movements. However, I added another sub to the event handler to create additional objects upon pressing the space key.

The current puzzler I'm experiencing is that when using the arrow keys (creating events), the space key generates events just fine. Likewise, if all keys are up and space is pressed, events are generated fine. The actual problem occurs when releasing all arrow keys with the space bar still pressed. As far as I can tell, the space bar does not continue to repeat events after the arrows are released.

My question regards the SDLx::Controller module. What is the typical way to handle events so that no keys are "blocking" other keys and that repeat events continue to happen in the example above? With the current system, event subs are only processed when events actually happen. This means that once SDL decides that I'm no longer pressing the space bar (even though I am still), it won't even go into the sub to check if the space bar is pressed. It waits until another event happens, then continues to process the space bar events. It would seem that using the arrow keys while the space bar is pressed, blocks the repeating space bar events from making it into the queue.

I'm pretty sure that didn't make a whole lot of sense, but I'm not sure how code could help in this case. I'm fairly certain it is not a programming bug at this point, but more of a lack of understanding on my part about how the SDL event loop is processed within the SDLx::App.

UPDATE: A quick fix for this problem is to add an empty event to the queue during each iteration of the game loop. This effectively makes all event subs get processed each frame. I'm sure this isn't an ideal solution, but it alleviates the need to re-press keys in order to keep the event queue polling. Ideally, I would like to not use this little hack, but I'm not even sure where that code would go, since most of the looping is taken care of in SDLx::App. scrottie: I considered this and changed things around to use different keys, but to no avail. I think it is an internal SDL issue (or my improper use of the interface) rather than hardware at this point. To be more clear, it's not that I'm hitting a zillion keys at once, just hitting them in different combinations.

Replies are listed 'Best First'.
Re: SDLx::App and keyboard events
by scrottie (Scribe) on May 31, 2012 at 16:05 UTC
    I don't know if this is what is biting you (or if this problem still exists), but there has been a long standing problem with keyboards where they don't do well at detecting events involving multiple keys. Traditionally, all of the keys are scanned as being at the intersection of a small number of wires coming from the encoder chip rather than having one wire go to each key from the encoder chip. Shift and control get their own dedicated leads to the controller chip because they're expected to be used in combination with other keys. So, you might try using control instead of the space bar. I have one of these babies: Classic USB NES Controller for PC. That's another way to avoid that problem. Good luck!