   Variable framerate for 2d, yay or nay?
  I'm designing a sprite engine for use in OpenGL, and - having never built a full-out sprite engine - I'm weighing possibilities, one of which I can't decide on and am looking for criticism and thoughts on: variable frame rate.That is, having each animated sprite (a sprite being a little chain of images, each image a frame) have its own timing scheme, and just giving every sprite a chance to update if it's flagged to do so.I sense this is going to aggregate overhead very quickly, but I'm having trouble predicting how much and, thus, deciding whether it will really be a problem or not on modern systems. Any thoughts? My goal for the sprite engine is to be able to handle a large number of sprites onscreen at once (as well as loading and offloading the sprites when necessary) and not look (quite frankly) crappy. Also, how restrictive is a static framerate environement for 2d?Thanks for your time.   
  That will definately cause a problem. You will want to have a definate timing system which will be independant of the running speed. To do this use a timer and each time it gets to + 1 unit call a render method.   ;  I would definitely agree with Xpyder that you wouldn't want to do a per-object timer -- the overhead, if not in performance but in logistics, would be very problematic (and unnecessary).So, to the root of the thread's question, "Variable framerate, yay or nay," I'd say nay... rather, I'd update all sprites at the exact same framerate (if you want that old school sprite-based hardware look) and if a sprite doesn't have that many custom frames of animation to just "repeat" it (or have a do-nothing update if you're using some kind of directy rectangle scheme).;  It'll probably be better if you have a single, static timer in your sprite class. That'll save you the overhead of having a timer for each sprite, plus it'll make it easier to pause/unpause/sync frames if the need arises.   ;  What everyone said above ;)But to add, if you really would like some animations to play at, say, 60fps, and others at 30fps, you can still do that with a static timer in your engine.For example, let's say your game runs at 50 ticks per second, independant of framerate.  If your animation has X number of frames, but wants to run at 25 frames a second, then you just update the frame every other game tick.  Converse is true too, if you want to have a 100fps anim playing, you'll essentially be jumping two frames every tick.  So simple math and your animations know at which speed they need to play back :)It's an easy way of manipulating animation speed without having to write a seperate timing mechanism for each of them :)   ;  Thanks for your replies everyone. Taking them into consideration.Does anyone think it wouldn't be a problem? Now I'm curious if there's really any support for a variable frame rate at all. =)   ;  I'm curious to know how you can implement that. Basically, let's say that the static timer is set to 100ps and you set a sprite to 50fps. How will you know when you reach 50fps ? There's no message that tells you you're halfway to a tick.   ;  if your timer is running at 100 hz and your animation should be playing at 50 frames per second, then at any given tick of your clock, you should be displaying frame #(50 * currentTick / 100).  It doesn't matter about getting a notice half-way between ticks... you won't be able to draw then anyway.  You may end up skipping some frames if you try to draw a 200 fps animation on a 100 hz clock, but that's probably desired.   