Is timer.performWithDelay() lag independent?

Solar2D General Questions/Discussion
#1

Hey,

this question goes more to the Corona staff or people who did extensive testing on this matter.

The thing is, if you use an enterFrame listeners for your game logic (like updating entity positions etc.) and your FPS slows down (because of effects, particles, loading etc.) the game logic slows down too (and not only the visile FPS on screen).

The question is, may this be prevented by using an infinite looping timer?

timer.performWithDelay(1000/60, listenerFunction, 0)

Or to say it in other words, does the timer function relie on the passed frames or the real elapsed time in milliseconds?

Would be great to know how Coronas internals work here.

Cheers,

Torben :slight_smile:

#2

Hi.  The primary issue here is that, Corona is single-threaded.  Because of this, once the system is over-burdened, everything slows down.  

i.e If enterFrame gets delayed, timers will take longer to get run too. That is, they will still honor their durations, but after the duration passes, their work gets scheduled just like the enterFrame call.  That scheduled work has to wait for the next frame.

The real-trick is to figure out that you’re doing too much work on the current piece of hardware and reduce that work in some way.

#3

Hey, thanks for the clarification.

I just thought, that there are things that take more performance and others take less.

For example, graphic stuff, like moving, deleting and creating new rendered objects takes in general more performance then most of the game logic (calling functions, estimating stuff, setting positions and scores etc.).

So the idea is, if I got a timer function that repeats 60 times a second (so it takes roughly about 17ms for each frame) and due to performance issues it takes longer than these 17ms for the system to update the timer, would the timer function be called twice?

To clarify:

timer.performWithDelay(17, listenerFunction, 0)

Let’s assume due to performance issues, it takes Corona 40 milliseconds to update this timer. Would the listenerFunction be called twice, as the elapsed time is more than double of the timers delay?

#4

I’ve checked this before and as long as the timer duration is > 0, it will not execute more than once-per-frame.

#5

Ok, thanks for your insights :slight_smile:

#6

Hi.  The primary issue here is that, Corona is single-threaded.  Because of this, once the system is over-burdened, everything slows down.  

i.e If enterFrame gets delayed, timers will take longer to get run too. That is, they will still honor their durations, but after the duration passes, their work gets scheduled just like the enterFrame call.  That scheduled work has to wait for the next frame.

The real-trick is to figure out that you’re doing too much work on the current piece of hardware and reduce that work in some way.

#7

Hey, thanks for the clarification.

I just thought, that there are things that take more performance and others take less.

For example, graphic stuff, like moving, deleting and creating new rendered objects takes in general more performance then most of the game logic (calling functions, estimating stuff, setting positions and scores etc.).

So the idea is, if I got a timer function that repeats 60 times a second (so it takes roughly about 17ms for each frame) and due to performance issues it takes longer than these 17ms for the system to update the timer, would the timer function be called twice?

To clarify:

timer.performWithDelay(17, listenerFunction, 0)

Let’s assume due to performance issues, it takes Corona 40 milliseconds to update this timer. Would the listenerFunction be called twice, as the elapsed time is more than double of the timers delay?

#8

I’ve checked this before and as long as the timer duration is > 0, it will not execute more than once-per-frame.

#9

Ok, thanks for your insights :slight_smile: