Transition timing: Is it accurate?

Getting Started Newbie Questions
#1

As mentioned in this thread - http://developer.anscamobile.com/forum/2010/12/21/timing-trouble - the performWithDelay functionality is not a “high performance timer”.

My question is whether the Transitions are better at timing than performWithDelay?

I was originally going to use performWithDelay to kick off a series of Transitions in time to the beat of a music track. As this has been proven not possible with performWithDelay - due to timing drift - I thought I could achieve the same thing using Transitions alone. So, instead of having a timer call a function every X milliseconds to start a Transition, instead I’d have a mass of Transitions triggered once, but with varying delays.

Would that work and keep time, i.e. is the delay property on a Transition a “high performance” timer? [import]uid: 26769 topic_id: 6998 reply_id: 306998[/import]

#2

NO! Eric already answered this in your other thread

“Sorry, none of the audio engines in Corona are designed for this kind of timing synchronization. (FYI, Android itself really isn’t setup for high performance audio.) In general, audio plays on another background thread while your Lua loop works mostly on the main thread so there will be drift when switching between threads.”

add a feature request for a stable audio buffer sample callback event. in Flash 10 this is SampleDataEvent.SAMPLE_DATA

note this event fires every time the buffer is processed and the audio hardware is ready for new samples. as such it isn’t necessarily directly linked to enterFrame or any timing event. if your buffer size is 8192 and your sample rate is 44100, this essentially happens every 0.186 seconds.

I’m not sure that with Lua being an interpreted language that this will be doable in Corona though.

i also explain the issue here:
http://developer.anscamobile.com/forum/2010/12/21/timing-trouble#comment-14811

[import]uid: 6645 topic_id: 6998 reply_id: 24778[/import]

#3

ok sorry, fair enough. don’t know.

[lua]local obj1=display.newImage(“test.png”)
local obj2=display.newImage(“test.png”)

local function transitionComplete(obj)
print("time taken for “…obj.name…”: "…(obj.startTime-system.getTimer())
end

– transition obj1 for 1 second after 1 second
transition.to(obj1,{x:100, time:1000, delay:1000, onComplete=transitionComplete})
obj1.startTime=system.getTimer()
obj1.name=“obj1”

– transition obj2 for 1 second after 2 seconds
transition.to(obj2.{x:100, time:1000, delay:2000, onComplete:transitionComplete});
obj2.startTime=system.getTimer()
obj2.name=“obj2”[/lua]

those values should be about 2000 and about 3000 supposedly? [import]uid: 6645 topic_id: 6998 reply_id: 24913[/import]

#4

Corona timers can’t be that accurate because all they do is fire events/put calls to functions inside a que whihc then be worked on at the next frame. Depending on how long the next frame took, it will be more or less accurate.

The same goes for transitions.

The minimum delta time for each frame is 16 millisecs, when you set the FPS to 60. You can’t go lower than that. [import]uid: 5712 topic_id: 6998 reply_id: 24943[/import]

#5

The title of the thread and the question I answered are both clear, i.e. the question is to the accuracy of the transition’s delay timer.

I appreciate that my use of an example regarding music may have muddied the waters slightly, but still I think it clear what my question was.

I could assume that the timers in question - performWithDelay and transition’s delay - perform the same, but I’d rather not. Hence the question. [import]uid: 26769 topic_id: 6998 reply_id: 24869[/import]

#6

Thanks for the info, guys.

@jmp909: I did some timing on performWithDelay and it was surprising. The times were consistent between calls (for the most part), but they weren’t the times I specified in the parameter! For example, my call every 250 ms would actually get called every 256 ms according to my time checks. Occasionally the call time would spike upwards to 270+, but then settle back down to 256 again.

This is probably down to the effect that MikeHart describes.

Anyway, my project has now gone in a different direction away from 100% accurate timing so it’s all good. [import]uid: 26769 topic_id: 6998 reply_id: 25070[/import]