[SDL] Framerate independence?

Scott Harper lareon at comcast.net
Tue Mar 27 08:51:25 PDT 2007


>> Truth be told, I hadn't actually thought of the persistent framerate
>> with sub-frame interpolation idea!  Nice, that one!
> To be honest, I think that sub-frame interpolation is wasteful. You
> don't really need to run game logic more than once per display
> (because these extra computations won't be visible anyway - user will
> see only the end result), and don't need to run it less than that
> (because all objects will be redisplayed at the same position several
> times - user won't see this).

But what of situations where, say you have a platformer and the  
designer wants to put in some wicked hard jumps that are timed  
exactly to you have to do it JUST right in accordance to your  
avatar's jump height and timing.  How would you accomplish this on a  
system which cannot guarantee a given framerate?  Or what if the OS  
decides to be a process hog for the precious few milliseconds where  
you would reach the summit of your jump, crest the platform, and  
safely land on it?  That's the one that's always bugged me.  I've  
compensated for it by always having the player jump higher than their  
intended maximum jump, but never more than an extra block's height.

It occurs to me, however, that running a logic process with a fixed  
framerate would account for that sort of thing such that the designer  
could say "the player reaches their crest after 50 logic loops", and  
the game would calculate positions one loop in advance and instead of  
performing logic in between logic frames (I'm using the word frame  
here not referring to the visual kind, which is probably some kind of  
mistake, sorry) they would perform interpolation calculations so that  
the game objects appear to MOVE each frame, just they don't change  
their logic at all.

If you have a better way of dealing with these inconsistencies,  
PLEASE let me know!  I would love very much to not have to get into  
it that far with my next game! ^_^

-- Scott


More information about the SDL mailing list