Does the function, timer.performWithDelay, have any limitation?

Solar2D General Questions/Discussion
#1

Does the function, timer.performWithDelay, have any limitation?
If I write fallow code, pass 1 into the very first parameter:

–srart of my code
local checkTime = 0

local function runtimeplus()
checkTime = checkTime + 1
if (checkTime == 1000) then
print(“1s”)
checkTime = 0
end
end

timer.performWithDelay( 1 , runtimeplus, 0 )
–end of my code

I found the function, timer.performWithDelay, didn’t work exactly 1 millisecond.

Of course I know I can change my setting to
timer.performWithDelay( 1000 , runtimeplus, 0 )
and get exactly 1 sec,
however my question is not solved,
My question once again:
Does the function, timer.performWithDelay, have any limitation?
Thank You for viewing this [import]uid: 199195 topic_id: 35599 reply_id: 335599[/import]

#2

timer.performWithDelay is not perfectly accurate, especially with very low delays.

C [import]uid: 147322 topic_id: 35599 reply_id: 141507[/import]

#3

That’s what I found [import]uid: 199195 topic_id: 35599 reply_id: 141527[/import]

#4

However…

The higher the frame rate, the more accurate the timers are.

The reason smaller delays are less accurate is as follows:

If your frame rate is set to 30 FPS, that means every second, approximately 33 updates are going on. (the real number would be 33.3333333333333333333333333333333333333333333333333333 going on forever) but you have to take into account the fact that even the frame rate isn’t constant. So one frame, it might be 33.141592653589793238462643383279502 milliseconds, and the next it might be 31.1, etc.

What the timer does is, every frame, check if the elapsed time since you began the timer to that point is greater or equal to the delay you set. So here’s a walkthrough of it:

We’ll call the moment you started the timer as 0 milliseconds.

[text]
0 Milliseconds

  • 1 millisecond - this is when your timer is supposed to go off… BUT! The update hasn’t occurred yet.
    10 (milliseconds)
    20
    30
    Update 1 (33 milliseconds after timer is started) It checks whether elapsed time (33 m) is over the delay (1 m). It is (33>1), so it triggers the listener. However, it’s at 33 m instead of 1 m. So it’s not exactly accurate.
    [/text]

Hope this helps :slight_smile:

Caleb [import]uid: 147322 topic_id: 35599 reply_id: 141534[/import]

#5

timer.performWithDelay is not perfectly accurate, especially with very low delays.

C [import]uid: 147322 topic_id: 35599 reply_id: 141507[/import]

#6

That’s what I found [import]uid: 199195 topic_id: 35599 reply_id: 141527[/import]

#7

However…

The higher the frame rate, the more accurate the timers are.

The reason smaller delays are less accurate is as follows:

If your frame rate is set to 30 FPS, that means every second, approximately 33 updates are going on. (the real number would be 33.3333333333333333333333333333333333333333333333333333 going on forever) but you have to take into account the fact that even the frame rate isn’t constant. So one frame, it might be 33.141592653589793238462643383279502 milliseconds, and the next it might be 31.1, etc.

What the timer does is, every frame, check if the elapsed time since you began the timer to that point is greater or equal to the delay you set. So here’s a walkthrough of it:

We’ll call the moment you started the timer as 0 milliseconds.

[text]
0 Milliseconds

  • 1 millisecond - this is when your timer is supposed to go off… BUT! The update hasn’t occurred yet.
    10 (milliseconds)
    20
    30
    Update 1 (33 milliseconds after timer is started) It checks whether elapsed time (33 m) is over the delay (1 m). It is (33>1), so it triggers the listener. However, it’s at 33 m instead of 1 m. So it’s not exactly accurate.
    [/text]

Hope this helps :slight_smile:

Caleb [import]uid: 147322 topic_id: 35599 reply_id: 141534[/import]