SDL_PollEvent
SDL_WaitEvent
From the links:
PollEvent checks to see if there is an event waiting in the queue, and pops one event if there is. Otherwise, it does nothing.
WaitEvent will wait (block) until there is an event ready, then will return.
What you are doing here is just... just... wrong. This is not
at all the way it is supposed to be done.
First, in a game you don't want to block. Ever. There is just too much other stuff you have to do (updating animations, etc....) that if you waste a whole bunch of time waiting for an event to happen, that other stuff won't get done. (Unless you do the busy-wait in a separate thread but from what I have seen, in no way are you ready to attempt that. So don't.)
Typically, what you want to use is PollEvent, then. That's it. Check to see if an event is waiting, handle it, then carry on with the loop.
Now, if you do it correctly, then by default you will be able to easily handle your stated test case of , ie handling any and all consecutive button clicks.
When the application is launched, SDL sets up a queue of events that is filled by the operating system infrastructure as operating system events happen. These events can be any number of things: mouse movements, window resizes, keystrokes, etc... The system will generate quite a lot of them. So what kind of events are you going to be looking at, in the case of subsequent button presses?
Well, you'll get MouseButtonDown events when a button is pressed. You'll get MouseButtonUp when it's released. If the mouse moves in between subsequent clicks, you'll also get a whole bunch of MouseMotion events. So in you your example, your first PollEvent call will catch a button click if it occurs before the call. Then WaitEvent will happen, at which point it will either catch the MouseButtonReleased event after the click, or it'll catch one of a long series of MouseMotion events if the mouse is moved. Or it might catch a keystroke, or a system event, or a user event, or any of a long list of events. (See
here). It might even be another MouseButtonDown event, but it won't be one for the same button, since that was the event that was caught by the previous PollEvent call. Then once an event happens (an remember that since we were waiting, nothing else has happened during this time. No drawing, no enemy movement, no logic, just busy-waiting for that damned mouse event) you move on to yet another busy wait. This one might catch another MouseButtonDown event, it might catch another movement, another keystroke, whatever. Maybe it'll be what you want it to be, but probably it won't. After that event is caught, then you carry on with whatever you were doing.
There is just no reason to do it like this, none at all.
while (gameLoopIsRunning == true)
{
SDL_Event event;
if(SDL_PollEvent(&event))
{
// An event happened, do something with it
switch(event.type)
{
case SDL_MOUSEBUTTONDOWN: handleButtonEvent(); break;
// and so on
}
}
doGameLogic();
render();
}
This builds the kernel of your loop. If you find yourself straying from that basic pattern, you might be making an error.
