   Speeding up SDL
  I've been experimenting with timers in order to find out a way to make the game after fps instead of the speed of the processor (in my own way). I always thought that using a while loop and ticks were a really good idea.Something I always thought could work was SDL_Delay(), but never really tried it because I thought it would only make everything slow. Now when I used SDL_Delay instead of the while loop, it is working atleast as good as using ticks if not even better. I became happy that there is such an easy way to do this and checked how much processor capacity that the game took when using sdl_delay. It took about 09-11 percent in average, the highest number I got up to was 33 but that was very unusual. In my games before, when I used a while loop, the processor usage of the game was about 98 and 99 constantly and that's an improvement in my option.Is there any reason why nobody uses SDL_Delay when working with games? The only disadvantage I can think of is that it's hard to get a hold of the fps.   
  SDL_Delay and the while-loop do totally different thing I think.SDL_Delay focusses the processors attention on something other than your program, giving it time to (for example) run minesweeper.the while-loop keeps the attention on your program but makes it "slower", depending on what framerate you want.SDL_Delay is still processor dependent.But please ask someone else too because I'm not absolutely sure about this.   ;  While capping your FPS will keep the game speed roughly constant, it's a much better approach to use the time that's passed in the prior frame as a factor for movement.  For instance, instead of this:Player->X += Player->XSpeed;Do this:Player->X += Player->XSpeed * LastFrameTime;This will allow the frame rate to go outrageously high or fairly low while still having the game progress at a normal speed.  To find the last frame's time accurately, Google up QueryPerformanceCounter and QueryPerformanceTicks.   ;  The QueryPerformanceCounter seems interesting with its ultra accurate fps reading combining with the Sleep function. Isn't there any SDL equivalent function for this?While I was looking for this, it seems that timing is quite a problem to get 100% accurate, but shouldn't SDL_Delay be enough for this? is it really processor dependent even if it takes milliseconds as parameter?I've seen quite recently that delay functions are useful for saving processor usage by using it at the end of the program, but i've never seen anyone use it for making the gamespeed processor independent like they do with timers and ticks. That's why I thought it could be a good idea to use the delay function alone and solve the two problems at one time, less processor usage + normal gamespeed, correct me if i'm wrong..   ;  You can use SDL_Delay with a value of 0 and update the rendering and logic at an interval of your choice. This way your app still (usually) gives processing time away to the operating system (nice for laptops too) while having a good control over timing. Timing is a bit tricky, I recently had a bug that surprisingly was not my fault so I looked up all about it on the net.There are 4 ways of timing on windows that I am aware of:- GetTickCount: this is what SDL uses, it's fast and reliable but has a low resolution, meaning the value you get can be off by as much as 55 ms if my info is correct.- timeGetTime: On newer windows (I believe NT systems) this has a lower resolution than on olders, but still better than GetTickCount, i think it has 5 or 10 ms. However, using timeBeginPeriod and timeEndPeriod  you can set the resolution to 1 ms. This will also affect Sleep, and probably thus SDL_Delay (as I guess this uses Sleep) if SDL doesn't already do this under the hood. This means that when you call SDL_Delay with some value, it really does delay with that value (more or less, can be 1 ms off). Normally, Sleep(1) could cause your app to sleep for 10 ms. - RDTSC instruction: this measure the clock ticks of the CPU, it's an asm instruction. Fast and high resolution (microsecond level), but causes problems with power management features like cool 'n quiet and intel speed stepping, because then CPU clock varies. Also causes problems with dualcore systems.- QueryPerformanceCounter: is supposed to resolve the issues with RDTSC, but on some systems it does have bugs. (I had one on my system). QueryPerformanceCounter can use the cpu clock or some other hardware. Some Blog that talks about the issues.I mentioned this so you could also be aware of the issues involved, it's not fun to have such a wacky bug when it's not your fault.I think a good solution is to just put SDL_Delay(0) in your loop and use the SDL_GetTime or whatever it's called. Update the game in a fixed timestep and render as fast as you can, or calculate time-since-last-frame and update the game with that value. For better resolution maybe use timeGetTime or QueryPerformanceCounter. Of course it also depends on the game, a card game or turn-based strategy will demand less of the timing than FPS.I collected some links so here you go:Article about fixed timesteptimeGetTime (MSDN)timing faqTiming and multicore processors (MSDN)hotfix for WinXP timing on multicore processors and power management features. I came across posts that say this does not completely work. It also isn't standard on windows update, it will be fixed in Vista and WinXP SP3.   ;  Thank you for posting all this and for the links. It was more to this than I thought. I will experiment with it now when I know more about it :)   ;Quote:Original post by BeanDogWhile capping your FPS will keep the game speed roughly constant, it's a much better approach to use the time that's passed in the prior frame as a factor for movement.  For instance, instead of this:Player->X += Player->XSpeed;Do this:Player->X += Player->XSpeed * LastFrameTime;This will allow the frame rate to go outrageously high or fairly low while still having the game progress at a normal speed.  To find the last frame's time accurately, Google up QueryPerformanceCounter and QueryPerformanceTicks.@OP - this is what you want to do, but you may want to add in a SDL_Delay(0) like mentioned to give up spare time, but only run this when you are getting high framerates. So..if(FPS > 75){SDL_Delay(0);}else{x = speed * ticksInterval;}For a (horrible) example.   ;  I'm using SDL as well and find that whenever I run my game it eats up all of the processor. If I use SDL_Delay(0) it still does, but if I use something like SDL_Delay(10) it does much better. Goes from around 99% of my processor down to 60% or so.But I'd really rather not have to use that since it could really mess things up on different systems.Do you guys know of another way to keep SDL from sucking up all of my processor? I run the same game under OpenGL and it uses maybe 5% of my processor- I don't get it. Is OpenGL just that much better? Or am I using SDL incorrectly?   do   {CurrentTime=SDL_GetTicks();  DifferenceTime=float(double(CurrentTime-LastTime));  FPS=1000/DifferenceTime;//CPU stuffSDL_Delay(0);  }  while(FPS>=60);   LastTime=CurrentTime;Probably not the best way to do it. Any suggestions? I'm still pretty new to game programming.   ;  Artum, you could try with SDL_Delay(1), but then you will have to use the timeBeginPeriod and timeEndPeriod I mentioned. If you do not, it will have the same effect as SDL_Delay(10).See timing faq. You will have to link with Winmm.lib, and enclose all that windows related code with #ifdef WINDOWS (or whatever it is) - #endif, to avoid needlessy restricting to one platform. However, is it really a problem that SDL sucks up all the cpu power? If you have software surfaces and especially when alpha blending, SDL needs this processing power. OpenGL does everything on the GPU, so it does not affect the CPU (generally speaking of course).   ;  Ah. Well that makes sense. Thanks for the tip- I'll give it a shot. It doesn't really matter that it uses up so much CPU, just I don't like it. ;)Thanks again!   