The old fixed timestep paradigm. Juicy stuff, and arguably the backbone of many a great gaming title Until recently, I'd not bothered to implement it, instead preferring my own questionable potpourri of odds and ends, with maybe a little vertical blanking here and there. I checked out DeWitter's game loop many moons ago but, in spite of it's virtues, it wasn't what I needed at the time.
After being asked by a work-colleage-turned-indy-gamedev guy for a rundown on how it worked, what the point of it is and 'what the hell is this interpolation business?', I cobbled together a little demo. In this video, everything is updated at a fixed timestep (60hz) however, only the colored bar is rendered with interpolated state. At about the halfway mark, after throwing some white boxes onto the screen, I switch down to a 10hz update rate (after a brief pause). Thanks to interpolation,, the colored bar retains most of it's smooth movement, even at `10hz. The white boxes, with all their physics goodness, don't fare well at 10hz without interpolation. I haven't implemented it there because I'm honestly not sure how..
https://www.youtube.com/watch?v=6SptavKHwew&feature=youtu.be
It seems to me that the only way to achieve a variable frame rate with consistent physics would be to scale the physics forces per the measured frame rate, which seems incredibly unreliable to me. Or decouple the physics loop from the rendering loop. I'm also working on how to figure that out. So, these are just wild guesses really.