LÖVE

A few games use a hybrid approach (as in the link that was posted above). They use a variable timestep for Draw, calling it as fast as the GPU retrace will allow, but apply fixed timestep CPU logic to control the frequency of Update. To smooth out the visual results (since Draw may now be called half way in between two Update time locations, or there could even be more than one Draw per Update), they interpolate the game state some fraction between two different Update results when drawing at times that do not exactly align to a fixed timestep tick point. This allows them to maintain as good as possible monitor sync, while still being able to write their physics assuming a nice simple fixed timestep. The downside is the extra code for lining up the two timelines and doing the state interpolation, which can be a serious PITA. There's nothing built into the XNA Framework to help you if you want to use this mode: you'd have to start with our variable timestep and then implement your own logic on top of that.

Taehl wrote:State interpolation sounds like an awful idea to me. Not only does it mean you need to keep the current state, but also the last state (meaning, twice as much memory usage); you need to do interpolation on all that (meaning eating more CPU); and the controls would always lag at greater than or equal to [the time it takes to update the state] + [the time you wait between state updates] (since the time the player touches a control is in the "future" of the game's state, since you have to wait for the next update before the control will have any affect).

So, you're using more RAM and CPU, and intentionally lagging the controls (a sin, in my mind!), all for what, exactly? I fail to see how this scheme would offer a smoother experience than without it (to say nothing of performance in general).

Bryant wrote:Xgoff -- Floating point precision is exactly the problem I have with a variable timestep Have you tried implementing your own fixed timestep in LÖVE yet?

Code: Select all

function love.update(dt)
	local accum = dt
	while accum > 0 do		-- accumulator for physics! no more penetration!
		local dt = math.min( 1/50, accum )	-- use whatever max dt value works best for you
		accum = accum - dt
		
		-- now, do whatever it is you need to do with dt
	end
end

accumulator = 0

function Update ( delta )
  accumulator = accumulator + delta

  while accumulator > 0.016 do
    world:Step ( 0.016, 10 )
    accumulator = accumulator - 0.016
  end
end

ivan wrote: That's not exactly how accumulators are supposed to work.
Your dt varies if accum is < 1/50.
Also, your accumulator doesn't really 'accumulate' anything since you set it to "dt" at each update.
If you are getting 'penetration' (usually called 'tunneling') with a particular body you might want to set its "bullet" flag to true.

My game works fine with variable timesteps, it just needs to make sure that things don't move more than half a meter in one update

Bryant wrote:at the end of those 200 updates, I still have some unaccounted for time, I'll run update() again with a fraction of my previous delta time (this step is what prevents it from being a perfect fixed timestep update loop)