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();
}
}
Limiting FPS (Without gobbling up to much cpu)
Author
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:
edit: screwed up source tags
[edited by - Iron Eye on March 1, 2003 1:22:08 PM]
For the love of all things loveable, implement framerate-independent behavior and use Sleep().
Author
My "ball", which is actually a number sign (#), flashes in 50 different places at once, and looks horrible if I don''t limit it.
Author
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]
Look. You''re probably doing something like this
instead, you should be doing something like this
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.
{ 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.
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...
at least, if you''re in dos, (like he is) or exclusive mode...
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).
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).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
