Limit FPS?

Started by
16 comments, last by Ronin Magus 21 years, 9 months ago
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
Advertisement
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.
ReactOS - an Open-source operating system compatible with Windows NT apps and drivers
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
---GUI Programming Division Manager at Wildfire Gamesworking on the 0 A.D. project
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]
"To some its a six-pack, to me it's a support group."
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.
"a low level aho master like you couldn't kill me even if I let you"
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).
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 !!??

-------------Ban KalvinB !
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
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.
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.


-------------Ban KalvinB !

This topic is closed to new replies.

Advertisement