every x milliseconds accuracy

For questions about using Classic.

Post » Thu May 07, 2009 2:10 pm

Since I don't know how was this solved by programmers, experiments will show some stuff.

Here is the simple "add timedelta" thingy:
:arrow: Text('t') adds timedelta meaning it counts seconds
:arrow: Text('t1000') adds timedelta*1000 meaning it counts miliseconds
:arrow: Timer retrieves play time

And all those errors provide difference between Timer and Text('t')*1000 or Timer and Text('t1000'). The [msec] error doesn't divide stuff, the [s] error divide result by 1000.


:arrow: Timer is based on adding timedelta
:arrow: 1000*timedelta produces numerical errors
:arrow: Numerical errors are random (one time positive, one time negative) and that leads to minimalizing the error
:arrow: The bigger the time is, the bigger numerical error is produced on every tick
:arrow: 0 error for adding nonscaled timedelta doesn't neccesary mean that Timer is compatible with system time (well, actually who'd bother if there was like 0.001msec error during the longest play possible?).

I'm now leaving program on to see results after some time...

Because errors are random, maybe after few hours the error will be positive value ^^.

Maybe there's a better point in checking this incrementing with Profiler's "getTickCount()"? I remember using getTickCount() and it's resolution wasn't really pleasing, is it the same way in Construct's profiler?


...positive :-).

Posts: 219
Reputation: 3,013

Post » Thu May 07, 2009 4:20 pm

BROO: Your application does not prove anything wrong with Construct's timers. Construct uses double-precision timers using QueryPerformanceCounter, which is accurate to microseconds or better. The 'timer' system expression returns the sum of all past timedeltas (in effect, the runtime is doing what your 't' variable is doing, adding all timedeltas). So 'timer' is not the system timer, there's no way to retrieve it in the runtime currently, since it's difficult to apply timescaling to the system clock. In effect, the .cap you posted merely explores the effect of double-precision rounding errors when you multiply a number by 1000, which is independent of any timers.

I realise the timer in the runtime therefore may accumulate a rounding error from summation of the timedeltas, and I might be able to improve the resolution of this in the next build. Still, the error shouldn't be large except over long durations.
Scirra Founder
Posts: 22,821
Reputation: 176,106

Post » Thu May 07, 2009 5:43 pm

[quote="Ashley":1zd2tnya] So 'timer' is not the system timer, there's no way to retrieve it in the runtime currently, since it's difficult to apply timescaling to the system clock.[/quote:1zd2tnya]

:O could we get a way to retrieve the unscaled system timer? I've been assuming it was.
Posts: 1,445
Reputation: 4,665

Post » Thu May 07, 2009 7:58 pm

[quote="Madster":1om1qp83]I don't think it is a problem actually.
One has to blow up the error almost on purpose.[/quote:1om1qp83]
well for me it is a problem, for some reason (don't ask :) I use every 50ms to do something, and every 1000ms to do something else that should be done exactly after running the first event 20 times. and between the 20th time and the second event there is some lag always, because, the 19th time is not after 950ms, but about 900ms... I think, this kind of accuracy will spawn multiple problems in the future, so if possible I think it should be corrected.

a cap is available here: viewtopic.php?f=16&t=3567
Posts: 555
Reputation: 12,989


Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 2 guests