I thought Codea was clocking at an attempted 60FPS, nominal delta time 1/60 or 0.0166 seconds. But tracking DeltaTime, I’m seeing cycles of 0.0166 but also 0.00833 and even one of 0.00419.
I’ve seen moderately long stretches of 0.008, only flashes of 0.004.
This program consistently shows 0.008ish on my iPad 3rd gen
-- t
function setup()
end
local min = 100
local max = -100
function draw()
local x = WIDTH/2
local y = HEIGHT/2
local d = DeltaTime
if d < min then min = d end
if d > max then max = d end
background(40, 40, 50)
fill(255)
text("min "..min, x, y)
text("max "..max, x, y+50)
text("DT "..d, x, y + 100)
end
@RonJeffries This is what I get on my iPad Air 3 after 1 minute.
Min 0.016668666619807
DT 0.016668666619807
Max 0.016753333387896
I don’t know this for a fact, but I think what’s happening is there’s a timer that runs 60 times per second, or maybe faster, but every time a 1/60 of a second tick hits, it does the draw function. If one draw takes more than 1/60 second to run, the next draw gets run on the next tick and the deltaTime will be shorter. I don’t think a cycle starts 1/60 second after the other one ends, but draw looks for the next 1/60 tick and runs.
Ah, so it won’t slow to random numbers but will realize it’s falling behind and drop to the next fixed slice size. Super, thanks. Still gonna have to scale, but we know how to do that Once slowed, does it ever speed back up in that run?
Yes if the complexity of the drawing lessens it can speed back up. It’s basically down to how long it takes you to draw a frame, but it sits at fixed thresholds to prevent the frame rate varying wildly (looks smoother to the user if you stay at a fixed frame rate rather than rendering as fast as possible)