I use a Timer with a recurring, regular interval and I find it slips behind. This is unlikely due to the lack of microsecond accuracy since it starts slipping within a few seconds. It could be due to 1/60th frame accuracy, but there seems to be nothing I can do about it.
So I can’t use it. Is Enterframe and comparing the interval calculation to system.getTimer the best solution, or is there something else I could use?
It occurs because Corona (like many other engines) work in frames and frames per second can fluctuate.
What you are describing, i.e. using delta time (link to a tutorial), is the best and easiest method that I know for achieving this.
i havent used it myself but i remember reading somewhere about calculating delta value between frames to get exact timing, mostly used for animations, but should help with the similar issue.
timers are bound by framerate so if device performance, or lack there of, make the framerate fluxuate, so will timers.
at best, with 60fps running, you are still looking at a minimum of approx 16ms irrelevant if you input lower values in the timer.
then of course, time steps will relate to this so next possible event will in the above example happen at about 32ms, and so on.
I seem to remember doing something like this. I adjusted the gap between each iteration depending on how close to the target gap the last iteration was. So in enterFrame I check whether the time elapsed is within say 20-30ms of the target. If so that’s good enough, run the timed event. Say it’s 986ms the next target gap will be 1014ms. If that ends up being 1016ms then the next target is 998ms.
Over the long run your timer should even itself out and 30 iterations will be a lot closer to 30 actual seconds.
it would help to have a short bit of code to demo the problem
in the timer source on line 232 you’ll find the calc for the next recurrence time:
-- this means "next scheduled time will be: current scheduled time plus interval" (comment added) local fireTime = entry.\_time + entry.\_delay
and note that there’s no dependence on system time at this point, so it SHOULD auto-correct itself (to the resolution of frame events)
ie, if it’s a one second interval, and the first call occurred at (fe) system time 1234, then next is 2234, then 3234, then 4234, etc.
(iow, it would be a major blunder if that line had been written as “local fireTime = system.getTimer() + entry._delay”, but it’s not)
actual execution time (vs scheduled execution time) is of course subject to the frame rate resolution, so figure a +/-frame’s worth of “slop” for the actual callback, but you should NOT be seeing an overall trend of increasing interval “lag”. (fe 1000ms interval, then 1030ms, then 1060ms, then 1090ms, then 1120ms, etc)
Hmm, it looks like there might be a fix on that github repo for this exact issue from 2 months ago. What Corona version are you using?
The latest Daily Build doesn’t have the accumulating delay, and fixed it immediately. Thx Nick & Dave! 
It occurs because Corona (like many other engines) work in frames and frames per second can fluctuate.
What you are describing, i.e. using delta time (link to a tutorial), is the best and easiest method that I know for achieving this.
i havent used it myself but i remember reading somewhere about calculating delta value between frames to get exact timing, mostly used for animations, but should help with the similar issue.
timers are bound by framerate so if device performance, or lack there of, make the framerate fluxuate, so will timers.
at best, with 60fps running, you are still looking at a minimum of approx 16ms irrelevant if you input lower values in the timer.
then of course, time steps will relate to this so next possible event will in the above example happen at about 32ms, and so on.
I seem to remember doing something like this. I adjusted the gap between each iteration depending on how close to the target gap the last iteration was. So in enterFrame I check whether the time elapsed is within say 20-30ms of the target. If so that’s good enough, run the timed event. Say it’s 986ms the next target gap will be 1014ms. If that ends up being 1016ms then the next target is 998ms.
Over the long run your timer should even itself out and 30 iterations will be a lot closer to 30 actual seconds.
it would help to have a short bit of code to demo the problem
in the timer source on line 232 you’ll find the calc for the next recurrence time:
-- this means "next scheduled time will be: current scheduled time plus interval" (comment added) local fireTime = entry.\_time + entry.\_delay
and note that there’s no dependence on system time at this point, so it SHOULD auto-correct itself (to the resolution of frame events)
ie, if it’s a one second interval, and the first call occurred at (fe) system time 1234, then next is 2234, then 3234, then 4234, etc.
(iow, it would be a major blunder if that line had been written as “local fireTime = system.getTimer() + entry._delay”, but it’s not)
actual execution time (vs scheduled execution time) is of course subject to the frame rate resolution, so figure a +/-frame’s worth of “slop” for the actual callback, but you should NOT be seeing an overall trend of increasing interval “lag”. (fe 1000ms interval, then 1030ms, then 1060ms, then 1090ms, then 1120ms, etc)
Hmm, it looks like there might be a fix on that github repo for this exact issue from 2 months ago. What Corona version are you using?
The latest Daily Build doesn’t have the accumulating delay, and fixed it immediately. Thx Nick & Dave!