Archived

This topic is now archived and is closed to further replies.

Iron Eye

Limiting FPS (Without gobbling up to much cpu)

Recommended Posts

I went on MSDN to figure out how GetTickCount() works, and made a working example that limits my program to 10fps, however it gobbles up 100% cpu on my 2.4ghz. This hardly seems reasonable for an ASCII character bouncing around the console. Heres my main game loop:
    
while(1) //make keypress exit later

{
          if(GetTickCount() - tikStart >= 100)
          {
              MoveBall(BallX, BallY, oldBallX, oldBallY, horizdir, vertidir);
              DrawScreen(BallX, BallY, oldBallX, oldBallY, ScreenBuffer);
              //system("pause"); //debug

              tikStart = GetTickCount();  
           }
}
  
edit: screwed up source tags [edited by - Iron Eye on March 1, 2003 1:22:08 PM]

Share this post


Link to post
Share on other sites
My "ball", which is actually a number sign (#), flashes in 50 different places at once, and looks horrible if I don''t limit it.

Share this post


Link to post
Share on other sites
quote:
Original post by ZealousElixir
For the love of all things loveable, implement framerate-independent behavior and use Sleep().


What header file has Sleep() in it?

nevermind, found it

[edited by - Iron Eye on March 1, 2003 1:32:31 PM]

Share this post


Link to post
Share on other sites
Look. You''re probably doing something like this

{
ballX += 2;
ballY += 1;
// test for collisions and respond, etc.
}

instead, you should be doing something like this

{
ballX += ballVelX * timeDelta;
ballY += ballVelY * timeDelta;

// etc.
}

What you do is calculate the time the last frame took (in seconds), then multiply by the number of units you want your ball to travel PER SECOND. Store everything as a float, then cast to int when you "draw." This will allow you to keep everything precise and add less than 1 to the position and have it stick (i.e. won''t get truncated because of int rounding).

If you need more explanation, just ask.

Share this post


Link to post
Share on other sites
but, um...if you are drawing at an independent frame rate, then you would want to draw as fast as you can...so you wouldn''t want to wait on anything...

at least, if you''re in dos, (like he is) or exclusive mode...

Share this post


Link to post
Share on other sites
yeah, the second you do Sleep, you are limiting framerate ...

but you still have to implement framerate independent behavior (ideally), so you can deal with the fact that sleep isn''t precise, and doesn''t guarantee your program will actually achieve the desired framerate when the system is under heavy load, or if your operations might take too long ... so the best possible way to write your program is:

A - all movement type calculations be completely framrate independent, so that they are as smooth as possible (moving an ammount corresponding to REAL TIME, instead of number of frames, is noticably less jerky to the eye)

B - you give up the processor when you do not need it (using sleep or equivelent) ... and therefore limit your framerate to a reasonable number ... a good maximum number to limit your rate to, is the vertical refreash of the monitor ... because you cannot possibly give the user frames than the monitor can display (although you can read input more accurately if you so desire - only really good for fighting / twitch type games).

Share this post


Link to post
Share on other sites
It's obviously a trade-off. You can use 100% of the CPU, or you can be nice and (slightly) limit your framerate. I have a function called Rest() that takes the (maximum) amount of CPU power you want to use and calls Sleep() every few frames with an appropriate number of milliseconds (always above 10, since Sleep isn't much more accurate than that). That lets you tweak your power consumption with respect to the framerate. I find that 80% consumption on my 3D engine lets it run plenty fast and it doesn't slow things down much.

Later,
ZE.

(P.S. I also recommend relinquishing a larger part of your time when you aren't drawing (i.e. when minimized); the user is probably trying to do something else, so it's best to hand over as much time as possible (and why not, since you shouldn't be doing much processing when the player isn't in the game anyway?)


//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links


[edited by - zealouselixir on March 3, 2003 11:58:01 PM]

Share this post


Link to post
Share on other sites
Yes, correctly skipping work and going to a sleep mode while minimized is something more games should support ... you see it in most A+ titles, but not most average / non-so good ones ... I think we need a gamedev.net article on how to do it ... so people don''t need to think too hard ... just add it to their engine and viola!

Share this post


Link to post
Share on other sites