Does anyone do deltatime updating?

Questions
1

One technique you often read about is deltatime updating, ie, something like
pos = pos + heading * speed * deltatime

where heading is a unit vector and speed is measured in pixels per second.

This is mainly intended for variable frame-rate games, to ensure a steady rate of movement. But it could also be nice as “pixels per second” is easier to visualise then “pixels per frame” (I dunno, maybe you’re modelling a physical simulation and you arbitrarily decide that a pixel is a centimetre or whatever)

Given that the Codea draw loop runs at 60 fps perhaps this isn’t needed, but I wondered if anyone had tried it (ie could be useful for intensive projects running on older iPads when the frame rate dips below 60)

Whilst we’re on the topic of delta time, question 2: does anyone know why, when you measure the frame rate with deltaTime, you get a value that fluctuates between, say 59 and 61, even with a virtually empty draw loop, instead of a nailed-on 60 fps? Is it just a rounding error in the deltaTime/ fps calculation?

2

I quote from the Roller Coaster example project:

function draw()
    background(Colour.svg.Black)
    perspective(45,WIDTH/HEIGHT)
    if not paused then
        time = time + speed*DeltaTime

For your last question, Codea still does stuff with every loop even if you don’t ask it to and the exact time that takes can vary a little.

3

But the things it does take less than a sixtieth of a second, don’t they? I assumed (wrongly?) that Codea waits until the sixtieth is up before running the draw cycle again. (maybe this is just a hang-up of mine from the cathode ray tube days when you would tell your draw loop to wait for the next cycle in order to stay in sync with the monitor)

4

I guess what I meant was, does it make a difference, in terms of smoother-looking motion?

5

sometimes codea doesnt succeed with 60Hz, and 1 frame is, say, 20Hz-like, then the impact will be less strange if you use deltatime. Although not perfect.

6

my iPad 3 rarely runs at 60 FPS because I load it with graphics, so yes, I do use DeltaTime!

In terms of smoothness, using DeltaTime gives a more consistent speed, so if you have two iPads, one running at 20 and the other at 60, objects will take the same time to cross the screen, but the price is possible jerkiness on the slower one because it has fewer frames to do it in.

Not using DeltaTime gives smooth speed, but the slower iPad will appear to be in slow motion. So if you are playing a multiplayer game, you would want to use DeltaTime to keep everyone in sync. And even if you’re not, you might want to use if for reaction based games, so they don’t get too easy on slower iPads.

7

Thanks, hadn’t thought about keeping 2 ipads synced, that’s a good point. Also, a lot of formulas that you find online for modelling physical forces use a delta time component. I guess that’s also about getting a consistent implementation of the force that you’re modelling across different systems. (or rather, the formula being adapted requires a time measurement more concrete than “a cycle”)

I’m still curious though as to why the delta time fluctuates even when Codea is idling. (it’s kind of cool though. Perhaps my iPad has an organic heart after all?)

8

garbage collection occurs regularly and generate a longer deltattime

9

(I think) one way to know when garbage collection occurs is to make a physics floor, put something on it, then delete the variable holding the floor (without destroying the physics object). When the object sitting on the floor falls through it, garbage has been collected.

10

Another way is to do parameter.watch("collectgarbage('count')") and watch when it starts to go down.

11

I’ve used delta time for the same reason as suggested above, for all timings, i used to use a count= count + 1*(fps_constant) but found this to be less intuitive than just deltatime

An unrelated question - does anyone know how to implement .h and .c libraries into xcode so that the main.lua code can read it? I’ve been stuck on this for days and its the absolute last bit of code before I can submit…