Hi, I'm just looking into making a SDL-based game engine, and my initial stuff has gone well, but I need a way to control how often a frame gets drawn so my game doesn't run at 500+ fps. I would like to have redraws happen at 60 or 80 fps, how do I go about doing that?

This won't directly help you control the frequency of drawing, but it's probably the effect you're going for: http://www.sacredsoftware.net/tutorials/...tion.xhtml

http://www.idevgames.com/forum/archive/i...13323.html
http://sacredsoftware.net/tutorials/Anim...tion.xhtml

(yes, you need both).

If you're using OpenGL, you can also use this in SDL for vsynch:
SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, TRUE);

I just used delta time instead of framerate limiting -- works much better.

It isn't so much to have a constant step to update your models with as to keep your computer from doing way too much work going at a very high framerate. (heating up your CPU, video card, etc. and wasting more power, not to mention the fan noise)

ravuya Wrote:I just used delta time instead of framerate limiting -- works much better.

I agree, it does work much better.

akb825 Wrote:It isn't so much to have a constant step to update your models with as to keep your computer from doing way too much work going at a very high framerate. (heating up your CPU, video card, etc. and wasting more power, not to mention the fan noise)

yeah its a good idea I think to have a maximum framerate, but use variable timestep within that.

unknown Wrote:yeah its a good idea I think to have a maximum framerate, but use variable timestep within that.

There is a reason that commercial games don't use a variable timestep -- it's really bad for networking, where it helps the clients get out of sync rather than keeping them together. Using a fixed timestep makes demo recording and playback possible, fixes the amount of CPU you may have to use at a known level, means that different clients will be much closer in their simulations, makes physics much easier to code, and the list goes on.

Alex's fixed-interval tutorial is definitely the way to go.

Yeah, I'm definitely a fan of fixed interval timing. It makes things far more deterministic, and easier to code.

Also, laptop users such as myself will thank you that playing your game doesn't eat their batteries for lunch. Running a game at 300fps might be an ego booster, but if you can only see 60 of those on screen anyway, what's the point of using all that extra CPU?

Fixed time steps are definitely easier to deal with in the long run, but they can introduce visual glitches (stuttering/choppiness) unless you interpolate the rendered frames. Here are a couple more links (one, two) that may be helpful.

Regardless of using time-based or fixed step animation, you should always VBL sync your animation in your release build. If your content is meant to be viewed by a human (as opposed to offline rendering) then there is no need to draw faster than the display refresh.