Should I bother with SDL WaitEvent? When I wrote my first application in SDL, it looked like this while (!quit) SDL PollEvent( amp event) switch (event) ... But then one time I left my app running while I went to do something else, and when I came back my laptop was boiling hot. I checked the system monitor and one of my cores was maxed out by my program! So I did some research, and now my loop looks like this while (!quit) SDL WaitEvent( amp event) switch (event) ... Great, so now my program doesn't max the CPU. But now I need to introduce rendering, and the problem is, currently this loop runs one iteration per event. If input and other events don't occur, my program won't render the next frame, no matter where the rendering code goes in the loop. So that's no good. I could have threads, but that seems like a lot of extra complexity when I could just do while (!quit) SDL PollEvent( amp event) switch (event) ... SDL Delay(10) This won't melt the CPU, and I can render at about 100 frames per second. My questions are Which approach quot should quot I use? I don't see any reason to not just use (3). What's the point of SDL WaitEvent, if you can't use it the moment you want to do anything other than handle events in your game loop? I assume SDL WaitEvent does something like approach (3) under the hood, so even though ostensibly approach (3) should introduce more latency, in practice it won't. Is this correct? How low should the integer passed to SDL Delay be to get a responsive app?