I’m having problems with SDL’s handling of keyboard events. Under X at
least SDL_WaitEvent returns multiple times when I hold down a single
key, which mean the same “Key Pressed” event is being put on the stack
multiple times (I think), Is this intentional? It creates a problem for
me because in one of my testing loops I say SDL_PollEvent, then alter
the map viewing offset change per second depending on keys pressed (or
depressed), then redraw. Now, the stack builds up faster than my
redraw, so I end up pusing and holding an arrow key, then releasing and
having to wait a few seconds before the map stops scrolling. Is there
some other way to read events I don’t know about, or should I implement
somthing like an array of all current keystates, and then compare that
to input recieved?
I’m having problems with SDL’s handling of keyboard events. Under X at
least SDL_WaitEvent returns multiple times when I hold down a single
key, which mean the same “Key Pressed” event is being put on the stack
multiple times (I think), Is this intentional? It creates a problem for
me because in one of my testing loops I say SDL_PollEvent, then alter
the map viewing offset change per second depending on keys pressed (or
depressed), then redraw. Now, the stack builds up faster than my
redraw, so I end up pusing and holding an arrow key, then releasing and
having to wait a few seconds before the map stops scrolling. Is there
some other way to read events I don’t know about, or should I implement
somthing like an array of all current keystates, and then compare that
to input recieved?
it may perhaps be better to flush the input cue if you find it is
over-running your ability to draw. this is of course if i am
interpreting your problem correctly
Even better, before each repaint, call SDL_PollEvent until no more event
come, process all keys (fast) and then redraw everything (slow).
You can also empty te event queue with SDL_PollEvent() and then examine
the (now up to date) keystates. Also, didn’t the Great Sam introduce a
way to turn off X key repeat in a recent release?
Even better, before each repaint, call SDL_PollEvent until no more event
come, process all keys (fast) and then redraw everything (slow).
You can also empty te event queue with SDL_PollEvent() and then examine
the (now up to date) keystates. Also, didn’t the Great Sam introduce a
way to turn off X key repeat in a recent release?
Yep. I believe it’s enabled. What version of SDL are you having problems
with? If it’s not 0.8, go get it.
It creates a problem for
me because in one of my testing loops I say SDL_PollEvent, then alter
the map viewing offset change per second depending on keys pressed (or
depressed), then redraw. Now, the stack builds up faster than my
redraw, so I end up pusing and holding an arrow key, then releasing and
having to wait a few seconds before the map stops scrolling. Is there
some other way to read events I don’t know about, or should I implement
somthing like an array of all current keystates, and then compare that
to input recieved?
it may perhaps be better to flush the input cue if you find it is
over-running your ability to draw. this is of course if i am
interpreting your problem correctly
j
Even better, before each repaint, call SDL_PollEvent until no more event
come, process all keys (fast) and then redraw everything (slow).
It creates a problem for
me because in one of my testing loops I say SDL_PollEvent, then alter
the map viewing offset change per second depending on keys pressed (or
depressed), then redraw. Now, the stack builds up faster than my
redraw, so I end up pusing and holding an arrow key, then releasing and
having to wait a few seconds before the map stops scrolling. Is there
some other way to read events I don’t know about, or should I implement
somthing like an array of all current keystates, and then compare that
to input recieved?
it may perhaps be better to flush the input cue if you find it is
over-running your ability to draw. this is of course if i am
interpreting your problem correctly
j
Even better, before each repaint, call SDL_PollEvent until no more event
come, process all keys (fast) and then redraw everything (slow).
not better, if they are holding down a key, they may input events
faster than they could be polled (unlikely but possible) so it would
never draw. having pollevent block until no more events come through
is silly because the more likely event of an inconsistent frame rate
would arise
not better, if they are holding down a key, they may input events
faster than they could be polled (unlikely but possible) so it would
never draw. having pollevent block until no more events come through
is silly because the more likely event of an inconsistent frame rate
would arise
A good compromise is to have code that looks like this:
#define MAXEVENTS Some number like 10-30
for ( i=MAXEVENTS; i && SDL_PollEvent(&event); --i ) {
process event (event)
}
