#### Archived

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

# Limit FPS?

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

## Recommended Posts

The animation class in my engine is based upon FPS. How can I go about limited FPS to around 30? I tried using an incrementer and a timer and then not animating anything if it''s above 30 fps but it would play for about half a second and then stop, start again, stop, etc. I''m wanting to keep smooth gameplay, using an engine that''s based on FPS. http://roninmagus.hopto.org

##### Share on other sites
Are you sure that limiting FPS is something you want to do? You might want to consider making movement and game logic time-relative, and letting the framerate run free.

That said, if you really want to limit the framerate to 30, simply wait (1 / 30) - n seconds after drawing each frame, where n is the length of time it took to draw a given frame. So, for example, if it takes 1/60th of a second to draw a frame, just wait 1/60th of a second after rendering that frame, and you will have the equivalent of 30 FPS.

##### Share on other sites
That''s not recommended though, I was once down that road, and it''s not pretty. First of all, I''ve never considered 30 FPS as "smooth" and secondly, meassure the time a loop takes and multiply all your movements with that value... You should meassure speed in the game as say: 12squares/second or such, not 12squares/loop... Atleast I wouldn''t recommend that...

/G

##### Share on other sites
Well, it's an easy way the get a game to run at a constant 30 FPS.

But you never should limit the drawing:

    void Loop(){static DWORD OldTime = 0;if(GetTickCount() - OldTime > 1000 / 30) // 30 = FPS{  OldTime = GetTickCount();    UpdateControls();  MoveEverything();  AnimateEverything();}  DrawEverything();}

like that

[edited by - MindWipe on July 16, 2002 6:12:47 AM]

##### Share on other sites
MindWipe just showed the best way

if you do any of those nasty ''loops''... your proram gets choppy, out of sync, and boggles down the computer.

##### Share on other sites
You don''t want to let your FPS just "run free". Early in your games development, you will encounter obscene frame rates (especially if you have a high-end computer). My skeleton DirectDraw app runs at over 1000 FPS on my Athlon 1.33 when only a few small images are being blitted to the screen. You may experience strange problems (like delayed input) when the loop is going that fast.

I would recommend limiting your FPS at around 60, as it will be much smoother. But remember what Gee and Martee said: base physics and game logic off of your FPS (or

Go with MindWipe''s code. Otherwise, you might want to look into QueryPerformanceCounter() if you need a more accurate counter (though a little more difficult to implement).

##### Share on other sites
quote:
Original post by doctorsixstring
You don''t want to let your FPS just "run free". Early in your games development, you will encounter obscene frame rates (especially if you have a high-end computer). My skeleton DirectDraw app runs at over 1000 FPS on my Athlon 1.33 when only a few small images are being blitted to the screen. You may experience strange problems (like delayed input) when the loop is going that fast.

So the faster the game runs the slower the input? That sounds strange !!??

##### Share on other sites
quote:
quote by granat:
So the faster the game runs the slower the input? That sounds strange !!??

I know it sounds silly, but I have experienced this problem with DirectX. Mouse and keyboard input is lagged by quite a bit when my frame rate gets really high (above 400 or 500). I have never really studied the problem - I just acknowledged its presence and limited my FPS. If anyone has an idea as to why this lag occurs, feel free to enlighten me.

-Mike

##### Share on other sites
another issue is time based code above 1000fps ends up not working - at least with timegettime. elapsed time /1000 ends up = 0. i had to add an 80k triangle mesh to slow things down to 5-600 FPS. didnt have the delayed input problem but took awhile to figure out why my time based movement code was faster at 800x600 than 1600x1200. i switched to using the DX timer.

##### Share on other sites
quote:
Original post by sstecker
another issue is time based code above 1000fps ends up not working - at least with timegettime. elapsed time /1000 ends up = 0.

So what ? It still works. In time the timeGetTime() will return a non-zero value again and your physics is updated once more.

##### Share on other sites
yeah that doesnt make sense, i probably miscoded something

##### Share on other sites
Another point is you shouldn''t really let you app "run free" with no fps limiting. Although Windoze should cope with this I find it is usually better to hold the frame rate back with a Sleep(n). This gives Windoze some time to do other stuff. This is esp noticable on win9x.

I ususally let the game code run between 25-60fps, and the gfx around 60-85fps ( although this does depend on your monitors refresh rate ).

[IMHO]
I think people should not get to hung up on getting 100+ fps, the most important thing is a constant frame rate. If the frame rate is varying wildly (30-60, 60-100+) the user is going to notice this a lot more than a app constantly running at 30fps!

And disabling VSync just to get a more impressive frame rate is bad, since the resultant tearing looks ugly
[/IMHO]

Mark Duffill[The Jackal]
Eurocom Entertainment Software

##### Share on other sites
quote:
Original post by Mark Duffill
Another point is you shouldn''t really let you app "run free" with no fps limiting. Although Windoze should cope with this I find it is usually better to hold the frame rate back with a Sleep(n). This gives Windoze some time to do other stuff. This is esp noticable on win9x.

I ususally let the game code run between 25-60fps, and the gfx around 60-85fps ( although this does depend on your monitors refresh rate ).

[IMHO]
I think people should not get to hung up on getting 100+ fps, the most important thing is a constant frame rate. If the frame rate is varying wildly (30-60, 60-100+) the user is going to notice this a lot more than a app constantly running at 30fps!

And disabling VSync just to get a more impressive frame rate is bad, since the resultant tearing looks ugly
[/IMHO]

Mark Duffill[The Jackal]
Eurocom Entertainment Software

Why not let it run free? I''ve never met person who can play quake in a window and type a paper at the same time...

##### Share on other sites
quote:

Why not let it run free? I''ve never met person who can play quake in a window and type a paper at the same time...

I was on about windows house keeping tasks it does in the background. Although you could give writting an essay + quake a go

##### Share on other sites
I don't understand something said further above:
Have the game simulate at 20 fps and display at 80 fps.
Thats not neccesary if you ask me, because then you'd only draw the same scene 4 times and no change to the content.

I'd rather have it reversed. Calculating physics faster than the graphics, with graphics at 30+ fps. That at least would give you a higher accuracy and since the scenes will only change marginally you could do much optimizations.

 slight rephrasing
---------------------------
I may be getting older, but I refuse to grow up

[edited by - Dreamforger on July 17, 2002 3:08:40 PM]

##### Share on other sites
Most games run physics slower than they draw the graphics, at least in the FPS world. Quake, Quake 2, and Half-Life (and probably others but I''m only sure on those 3) run the physics only about 10 times a second, but the graphics can be drawn up to 100 times a second in half-life. The ''extra time''(between physics updates) is spent interpolating between animations and smoothly moving models from one place to another (you get 10 frames of motion between point A and B instead of only 1, and that makes motion look a lot smoother).

Also, I would suggest that fps not be limited to lower than 100. Sure most monitors now max at 85hz refresh rate but leave a little growing room for the future. Also, as somebody said, constant fps is better than high and low alternation, so try to code the game to find a nice stable fps rate =-) Just take the average fps over a short time, and limit the fps to that + 10 or something (to allow it to increase in case it was just a moment of windows processing in the BG or maybe one scene that was really complex)

"The Requested Information Is Unknown Or Classified" -Anonymous

##### Share on other sites
quote:
Original post by Mark Duffill
[quote]
Why not let it run free? I''ve never met person who can play quake in a window and type a paper at the same time...

I was on about windows house keeping tasks it does in the background. Although you could give writting an essay + quake a go

Oh. I don''t think those take too much time and windows will just take what it needs, causing a slight drop in the FPS. Personally I hate it when games take up a small percentage of my memory and processor and then run slow... So I set the process to realtime. But still, you do have a point, it''s just limiting it to 30FPS is silly.

##### Share on other sites
quote:
Original post by Dreamforger
I don't understand something said further above:
Have the game simulate at 20 fps and display at 80 fps.
Thats utter bogus if you ask me, because than you'd only draw the same scene 4 times and no change to the content.

I'd rather have it reversed. Calculating physics faster than the graphics, with graphics at 30+ fps. That at least would give you a higher accuracy and since the scenes will only change marginally you could do much optimizations.

Nope. It really is good to do the physics at a fixed rate and let the graphics run free. The trick is to do some interpolation or extrapolation during the draw calls, so you can animate between the positions the physics code comes up with.

You usually _don't_ want the physics to run faster than the graphics. If you want a multiple step integrator the proper thing to do is to integrate to a higher accuracy in one physics call, not call physics multiple times per drawn frame. Besides, if you run physics too fast, you can't keep up on all PCs and you end up losing the repeatable behavior that makes fixed framerates so attractive in the first place.

[edited by - cheesegrater on July 17, 2002 10:18:43 AM]