Archived

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

Limiting Frame Rate

This topic is 5585 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

My maximum frame rate is 62 frames/ second. When I try to slow it down then the animation becomes choppy and I can see a double image. I'm using Jim's cGraphics and cTiles classes. The code is: Time = timeGetTime(); Graphics.BeginScene(); Graphics.Clear(); x+=5; y+=5; Tiles.Draw(0,0,x,y); Graphics.EndScene(0; Graphics.Display(); while(timeGetTime() < Time+20) { //do something } This code slows down my framerate to about 50. Sometimes it's 1 more. For some reason the frame rate changes by a few frames every second or so. Anyhow I've been trying different methods to make my animations smooth under my 62 frames/second and nothing works! If I tell it to move every other frame then the image is blinking and looks transparent. And if I slow it down to 50 then the image vibrates and stuff. I'm using DirectX 8.1. I also tried to change the x and y coordinates when .02 seconds go by( 20 millisewconds) with the same effect of choppy movement,etc. [edited by - GiantPaul on August 29, 2002 6:54:48 PM] [edited by - GiantPaul on August 29, 2002 7:13:14 PM]

Share this post


Link to post
Share on other sites
That''s not a very sound way of limiting your framerate. Basically you''re telling it to update the game (which may take a variable amount of processing time), then wait for a fraction of a second. A better way of doing things would be to skip the game update if the timer hasn''t reached a certain point like so:


  
//This would be a global...

DWORD g_dwLastTick = 0;

//Inside your game loop...

if(GetTickCount()-g_dwLastTick>1000/dwDesiredFrameRate)
{
g_dwLastTick=GetTickCount();
//Update game

}


Also, GetTickCount() is a lot more precise than timeGetTime() (no extra libraries required either).

Share this post


Link to post
Share on other sites
I'm still confused. Are you saying I should change the x,y coordinates when the tickcount is greater than 20 milliseconds
(50 frames per second) but keep writing to the buffer at full speed which is 62 frames per second? I do all my logic calcualtions between clearing buffer and flipping the buffer to the screen. Was that wrong?

Is my problem created because I'm varying the time between buffer flips or rather slowing it down?



[edited by - GiantPaul on August 29, 2002 9:58:05 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by GiantPaul
Is my problem created because I'm varying the time between buffer flips or rather slowing it down?



You're doing both. The code I described would update and draw everything (you should put your draw code as well as your game code in that if statement) if and only if a certain amount of time has passed. Your code would process the game regardless, then wait for a fixed amount of time, so all your code is doing is slowing things down and not doing an effective job at locking the framerate (but rather pausing every nth of a second). Basically, you only update your game and screen on the condition that at least 1/60th of a second (in the case of 60 frames per second) has passed. That will pretty much guarantee your game will run no faster than 60 frames per second (although it will run slower on systems incapable of running your game at at least 60 frames per second, but this isn't usually a problem since you're still apparently doing small stuff).

[edited by - Johnny_W on August 29, 2002 10:22:48 PM]

Share this post


Link to post
Share on other sites
I had sleepless nights for a whole week trying to figure this stuff out. Thank you so very much for explaining this to me. My friend says hi and thanks also; I''ve been bothering him that I can''t comprehend why this was happening to me.

Share this post


Link to post
Share on other sites
you should draw just 60 frames per second.
Lets pseudo-say:
  
#define FPS 60
#define MAXFPSTIME 1000/FPS

DWORD dwLastTime;

void DrawScene()
{
dwCurrentTime = GetTime(); //(or tick whateva)


if (dwCurrentTime-dwLastTime) > MAXFPSTIME)
{
DrawStuff();
}

dwLastTime=dwCurrentTime; //or GetTime() again


}

This way you''ll draw only 60 times per second and you''ll free processing time for other bussines.
Getting the input state should have the same procedure but using other refresh rate.

Share this post


Link to post
Share on other sites
Why limit the framerate at all?

make the movement time based. Let''s say you want something to move a 10 pixels/second. If your app runs at 10 frames a second, the object will move at 1 pixel/frame. Better frame rates will only move the object on certain frames, but this ensures you are never artificially limiting your framerate.

Why should a 4GHz with a GF10 run at your predetermined 60fps?

Share this post


Link to post
Share on other sites
Because I''m not sure if the human eye can see more than 60 fps per second. Why should I waste 4GHz rendering frames that nobody will see?

Share this post


Link to post
Share on other sites
(Lacking context about what you are actually doing...)

IMHO, this is somewhat misinformed reasoning.

In the early days of film, they determined that you could get by with very low framerates and the eye/brain would fill in the missing info. Early film was 18fps, current film is 24fps, and video is 25/30fps (25 for PAL, 29.97 for NTSC)

From this, you could say that 24fps was probably plenty, but if you watch a film with sweeping panoramic shots, you''ll see they''re actually quite choppy.

All this is relatively moot because the critical difference between film and gaming graphics is that film captures little cues like motion blur and a fair amount of "subpixel" information that changes slightly between frames. Gaming graphics are rock solid and the eye sees that.

I''m no video/audiophile, but I can distinctly see the difference between Quake at 60fps and at 90fps. On most good monitors, you can see the difference between 60Hz and 70Hz in terms of refresh rate alone (try coding on a 60Hz CRT vs. a 72Hz CRT) The reason is that your brain has more information and has less gaps to fill. Besides, while your game is running, what else is the CPU doing? You could answer "physics", but I don''t necessarily think that''s a good reason for arbitrarily picking 60Hz. Hopefully your game will be interesting 5 years from now and you could build your app such that it runs at 100Hz AND does more robust physics calculations.

The point is that you shouldn''t limit future hardware without a really good reason. You could say things like "I don''t believe people can see more than 60Hz", but you might also be compelled to say "I don''t believe people can see movements of less than two pixels", or "I don''t believe people will want to run my game at higher than 640x480". If you were coding "pong", you could reasonably make the above assumptions, but why should the player be subject to those (arbitrary) restrictions?

Share this post


Link to post
Share on other sites
Like CrazedGenius said, limiting framerate is fine for the small stuff you''re doing now but down the line its better to factor in the time with game update equations. Oh, and xaxa, the code you posted does exactly the same thing as the code I posted.

Share this post


Link to post
Share on other sites
Two things you should make sure you do:

A) Implement time-based movement. This should be done no matter what, as it makes a very fast or very slow performance of your program still "playable" for the user. So, whether your limiting your framerate or not (which I'll get to in a moment), you should be implementing time-based movement in all of your programs... Its a good practice to get into.

B) You shouldn't be limiting your frame rate, as some previous posters suggested, at all. Its just not a good thing to do. If you want to make sure that your program doesn't experience the all too present "tearing" effect on any cards, just make sure that you make sure to wait for verticle sync (V-sync, as it is more commonly referred to as). This will always prevent tearing, without too much work on your part.

Remember, however, that if you choose the route in B, that you should still be implementing time-based movement.

Trent(ShiningKnight)
trent@voxelsoft.com
The Official Site of All True Programmers

[edited by - ShiningKnight on August 31, 2002 2:39:44 AM]

Share this post


Link to post
Share on other sites