Quote:Original post by leiavoia Measure the time, roughly
(THIS_FRAME - LAST_FRAME) = DIFFERENCEIf ( DIFFERENCE < DESIRED_FRAME_RATE ) { sleep( DESIRED_FRAME_RATE - DIFFERENCE ); // stop doing anything for a while }
Instead of just sleeping, have a timestamp saved when you begin your rendering, then check the new timestamp at the end of rendering. Take the difference in the desired frame rate as to how much time you have, and you can then make calls to AI, physics, background loading, morphing animation, etc. anything else that doesn't require actual rendering at that time... if you keep a count of how much time you have left before you have to render the next frame, you can get a lot accomplished in the background between frames, and make more complex games...
leiavoias way is completely flawed, and should never be used. You should never try to restrict the framerate, but instead make all animation framerate-independent. And well, there's a ton of material on that just here on gamedev.net. It's very simple really; Just see how much time each frame takes to calculate and render, and scale the animations according to that value.
I'd agree strongly with Tok-Junior. You should be using time based movement and animation, not capping the game to run at no more than X fps. People wouldn't touch you game for that very reason. Most people want to see the 260fps counter, even if anything over their refresh rate makes no difference.
And I would NEVER sleep/stop the system. Chances are you're letting the game give time to the system to poll for events anyway. A better alternative to sleeping would to just skip the frame drawing and updating of objects, and basically let the computer run dead, meaningless loops, until the proper frame time has elapsed. Then at least you could continue to let the system poll for events, etc.
"Creativity requires you to murder your children." - Chris Crawford
Quote:Original post by tok_junior leiavoias way is completely flawed, and should never be used. You should never try to restrict the framerate, but instead make all animation framerate-independent. And well, there's a ton of material on that just here on gamedev.net. It's very simple really; Just see how much time each frame takes to calculate and render, and scale the animations according to that value.
Quote:Original post by catch You should be using time based movement and animation, not capping the game to run at no more than X fps.
Now for the basic concept, i agree with you: just let the machine run at whatever pace it wants and keep it time-based to move objects based on time, not FPS. That is how i do it with my own project.
But I think you missed the intention of the OP. He wanted to cap the frame rate. That's one way to do it. I don't believe he was trying to create frame-based movement. Also it should be noted that you can restrict the frame rate to free up the CPU and STILL have frame-independent motion. The two ideas are not mutually exclusive. As DJHoy brought out, sometimes you need to intentionally cap the framerate to fit in other game function such as the AI. But that does not mean that movement needs to be based on a specific FPS.
On another forum though, there is a complaint by a fellow with am open-source game project that the game eats up 100% of his CPU and his cooler can't handle that for extended periods of time (his fault, i know). And i admit that i don't like to see the CPU spike either. The solution was to cap the frame rate and make that rate configurable via a config file somewhere.
Leiavoia, for the record, I wasn't agreeing with tok's critism to you, just agreeing that it would be better to generally use a time based movement procedure, so that faster computers can play the game as well. I should have made that more clear when I said I agreed with him.
Aside from that, it seems in the real world, game developers use both methods; a cap coupled with time based movement. I always have both features in my game projects.
It's always a good idea to manage your movement, animation, etc on timers and interpolation, but at the same time, a frame cap is vital during development (as you pointed out), as is it an excellent feature for clients when the product is released (again, as you pointed out).
No harm, no foul, I hope.
"Creativity requires you to murder your children." - Chris Crawford
Capping framerate makes perfect sense in environments where animations cannot reasonably be "scaled", e.g. because they're all sprite-based. And in anything other than games, hogging the CPU isn't considered good practice, because anything other than a game is likely to get multitasked with some other non-games. So may as well at least learn how to use sleep().
Dead loops are not a particularly good idea. You might consider putting your I/O stuff in a separate thread, so that you can actually pause your own thread when you'd like. Some APIs actually do this already (like J2ME). Of course, you want to simplify the thread communication as much as you can, to avoid bugs.
Quote:Original post by catch Leiavoia, for the record, I wasn't agreeing with tok's critism to you, just agreeing that it would be better to generally use a time based movement procedure, so that faster computers can play the game as well. I should have made that more clear when I said I agreed with him.
...
No harm, no foul, I hope.
No problem. I just wanted to point out that there is more than one way to skin a cat (and that the OP wasn't trying to skin a cat at all :-)
Gan's complaint was that "when the game ran at 200fps, it became unplayable". Which should be taken as he wants the game playable by making it run at a fixed speed, imho. Freeing the cpu for other tasks should NOT be done by sleeping or running meaningless loops, since that doesn't really free it. It should simple yield by not handling any events. Either by not doing anything in respons to them, or by not having them sent to it.
Quote: Capping framerate makes perfect sense in environments where animations cannot reasonably be "scaled", e.g. because they're all sprite-based.
Spritebased animation can absolutely be timescaled. And SHOULD be. If not, it would be like letting a movieprojector run at random speed, which never happens. It always run at a set 24 (or something) frames/sec.
[Edited by - tok_junior on August 20, 2004 1:09:27 AM]
