Your solution will lead to jittering when computation takes ~ desired frame time. This may happen all the time due to scheduling conflicts in the OS. You opt to slow down the whole simulation if you can't keep up. This leads to your game character running at, say, 1/2 real time speed only to switch back to full speed and back - it jitters. E.g. take a frame rate of 10 FPS:

Real Time Game Time
0             0
0.1          0.1
0.2          0.2
0.4          0.3 <- lagging
0.6          0.4 <- lagging
0.7          0.5
0.8          0.6

The 0.2 seconds are lost. Your simulation ran slower during the lagging frames and there's nothing you can do about it. So it doesn't run at same speed on all machines. Advanced game loops might catch up if simulation doesn't take too long.

If you start lagging heavily you have to drop frames, effectively slowing down the simulation. You're doing it implicitely by only simulating a single update step. Advanced game loop drop accumulated (and not yet accounted for) real time. There is no way around it. That's one of the reasons multiplayer lockstep simulations may halt - if one machine can't keep up all others have to wait for it.

The benefit of advanced game loops is that they cope with OS induced jitter that can be easily handled by performing 2 update iterations in a single render frame. The render delay is most of the time either irrelevant (say 60Hz game state updates) or can be masked (by animating wrt render rate instead of game logic rate).

To be frank, I don't see the advantages of your scheme as I understand it, except that my laptop might be killed by your busy wait loop :)

I agree with @duckflock; while it does cut down on temporal aliasing, it has three issues that jump out at me:

• It seems as if this drops updates rather than frames, which can lead to a discrepancy in gameplay (people trying to cheat online/trying to engage "slow-motion" by increasing the load on their machine).
• If update or rendering takes too long, all expectations are gone; all of a sudden, rather than the game busy waiting (and not repainting. Black window if you move it around before it repaints?), time no longer matches wall clock time: 1 second in real life no longer counts as a second in game, and the game enters slow-motion as they update slower than realtime.
• Busy loop consumes quite a bit of CPU time.

I would recommend writing an actual program that demonstrates this concept, to better get your point across.

edit: Editor doesn't like bulleted lists?

I have to double this, your solution seems to have some drawbacks.

A dogmatic fix-your-timestep approach might push your game into a spiral of death, but you typically only apply this on critical parts of your game. Eg. game logic, animation, most rendering stuff, pathfinding etc. don't really need a fixed time step, a dynamic timestep is sufficient. Particle emission, physics depends on a fixed timestep, skipping one or more timestep will result in appreciable stuttering.

So, instead of putting it into your game loop shift the fixed timestep into sub-components in need of it.

>> You opt to slow down the whole simulation if you [the compter] can't keep up.

exactly. i consider it less player-unfriendly than having the simulation continue at real time speed while only render and input slow down. the speed of render and input dictates the "speed" the player can run/play at. if they slow down and the simulation doesn't, from a player point of view, the simulation is running faster than the player interface is, and the game can become momentarily unresponsive to the point of being unplayable. unfortunately, slowdowns often occur in heaviest combat, IE when the player is in a big life or death battle, exactly the WRONG time for the user interface to slow down with respect to the simulation.

the idea is to limit the fps rate to worst case all the time. if heavy combat in your title drops you from 55 or 60 down to 35 fps, you set the limiter to say 40 fps. granted, you do lose 20fps worth of animation smoothness, but your game doesn't become unplayable in heavy action.

obviously, games that don't stress the limits of the hardware much or in a spikey manner don't need to worry about playability at low frame rates. this is probably most useful for some sort of hard core combat sim that really pushes the limits of the hardware. - submarine simulators come to mind as an example.

>> (people trying to cheat online/trying to engage "slow-motion" by increasing the load on their machine).

this approach is for high accuracy single player simulations. in a multi-player environment, such a game would require lockstep sync to maintain simulation accuracy.

>> I would recommend writing an actual program that demonstrates this concept, to better get your point across.

looks like i've done a total of 37 games that way over the years:

Caveman 3.0 beta 14, released dec 26th, 2014:

http://rocklandsoftware.net/beta.php

Other titles with framerate limiters (from the Rockland website):

Caveman v2.0 - Caveman VR (2008) - Virtual reality caveman simulator / RPG / FPS. Unreleased.

>> So, instead of putting it into your game loop shift the fixed timestep into sub-components in need of it.

unfortunately, the whole point is that the UI (render and input) should never run slower than the physics simulation (update) to avoid playabilty issues when ET momentarily goes high. this implies that they should be in lockstep when ET is high.

I see no reason why the UI shouldn't run faster than the simulation when possible, for smoother animation and more responsive input. this would lead to a semi-decoupled design. lockstep when ET is high, variable timestep when ET is low. I'll have to think about how to best do that. i've done a lot of research on variable vs fixed timestep. i think one of the designs i investigated yielded that behavior. which is the best of both worlds.

it seems the typical approach today is to use variable timestep, then simply not tax the hardware too much. but this leads to design constraints based on hardware such as "scene complexity can never exceed 50-55fps minimum". well, what if you want to do a complex simulation where today's hardware just can't do that? do you wait 10 years? or do you change the rules: steady state minimum fps of 35-40, minimum fps in heavy combat of 20 fps.

Right now, caveman 3.0 is running at about 25-35 fps steady state and never drops below 15-20 fps under worst case scenario. its limited to 15fps, so it basically NEVER slows down. that's single threaded on a 1.3 Ghz laptop motherboard with onboard graphics only, and ~100 characters in fps combat. the SIm3 on the same PC gets about 12fps steady state, silent hunter 4 and rome2 total war get 15-20fps. skyrim, about 18fps with graphics set low.

Caveman 1.0 (released in 2000) could do 70 characters in combat with _almost_ no slowdowns.

many years of playing hard core combat sims has shown that 15 fps is about the minimum speed the interface can run at and still be sufficiently responsive to not impact game play. in such games, a momentary drop in interface speed (but NOT sim speed) to say 8, 5, or 3 fps in a life or death combat (the result of variable time step) is really unacceptable.