Limiting Frames Per Second?
Author
In my game engine, I would like it to run at a smooth 60 frames per second, but it always seems to be higher than this. How would I limit the number of FPS? I am using Dev-C++ and Allegro.
Quote:
...thou shalt not limit your frame rate.
...thou shalt use time based updates.
found carved on stone plaques in during a cave excavation, heed the wisdom of ancient cultures and listen to the message.
Author
I thank you for your help so far, but I am confused as to how I use that snippet of code.
Quote:Original post by skittleo
I recommend limiting your framerate, and you will find many games do. They do this because as framerates increases, movement distance decreases per frame and eventually you'll run into floating point errors and things happening that wouldn't normally happen at 60fps.
This is basicly a fallacy. Most games don't and the problems that you mention are easily remedied by using a 'scrap' counter and for physics using a fixed timestep (something you probably want todo anyhow). With that out of the way you can use the extra framerate to react faster to user input handle networking and do loads of stuff that's far better than sitting in a busy wait loop.
Agreed, if you really want a fixed framerate, then for heavens sake, don't use a busy idle loop. Either use Sleep(), so other apps can use the leftover CPU time, oro do something with it yourself. You might be able to process input or physics or networking or other stuff while waiting for the next frame (or as DigitalDelusion says,just use a fixed timestep, and the entire game can run at the faster framerate, which will be a lot easier for you to manage)
Quote:Original post by skittleo
Ps: Sorry DigitalDelusion, but I had to disagree. I never used to cap my framerate until I started experiencing precision problems, and then I realized that capping the framerate is pretty common in games.
The inprecision arise because you're taking varied timesteps and will often cause very strange things indeed (like jump distance dependant on framerate etc) so you've correctly identified one problem (varied timesteps) but your solution is to be blunt, crap!
What you really ought todo, and what I've been trying to say all along is that you problaby want something like
delta = scrap + TimeSinceLastFrame();//handle physicsfor(; delta >= timestep; delta -= timestep) StepPhysics( timestep);scrap = delta;//save scrap time//handle input and non time dependant stuff herethis way you keep your physics chugging along nicely and keep it quite deteremnistic while not busy waiting and spending the extra cycles doing real work (like responding to player input)
I've been seeing a post about FPS limit at least once a week for some time now.
Try to recycle.
Answered here.
Try to recycle.
Answered here.
Quote:Original post by skittleo
I already acknowledged that fixed timesteps are a better solution. And it's good that you for providing some sample code to kelcharge. I have used both in my applications, and if you did not provide an example for fixed timesteps, I would have.
That said, my solution is not "blunt crap." I am sorry you became offended when I pushed for a very simple solution. Take it with a grain of salt next time. But it's better than no limit at all.
My main objection is that the solution is hiding a problem instead of solving it, correctly identifying what goes wrong and handling the cause is in my oppinion much more valuble than providing a quick fix in many circumstances.
Maybe my reply was overly rethoric but at a grander scale it did help foster a more throug discussion providing a more solid (although perhaps not as clear cut) answer to the original post.
Author
xor, you were extremely helpful in pointing me to that other topic. I can finally get it to stay at 60 FPS.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement