Is timing in C2 accurate?

Discussion and feedback on Construct 2

Post » Sun Feb 01, 2015 8:17 am

So I have been looking into timing and such - and, obviously it's always "use dt for smooth and proper timing in C2" and "behaviours have dt built-in so they are accurate". I built a little test and there's some strangeness afoot - the longer it runs there's both more and more shift from the "reference" every second thing, but also between a behaviour and a simple +dt*X action.

Image

I realise it can be fixed with some extra variables and math, but can that be avoided and reasonable accuracy expected with simple behaviour/dt usage? dt seems to be rounded down to 3 digits and the sum total in 1 second apparently almost never comes down to a clean 1? Or am I doing something wrong?
You do not have the required permissions to view the files attached to this post.
B
19
S
6
G
7
Posts: 1,101
Reputation: 6,146

Post » Sun Feb 01, 2015 9:34 am

This is normal behaviour ; accumulating floating point values will also accumulate errors and encoding inaccuracies and will never give an exact number. Which is why we never test for equality between floating point numbers ; you never have "1.0 + 1.0 = 2.0", you always have "1.0 + 1.0 = 2.0 + epsilon". When using floating point values, always work with ranges and threshold.
If you know the expected result (like in your behaviour), add a manual correcting factor or snapping mechanism for key values.

Also, dt doesn't guarantee proper timing, it guarantees framerate independence. "Proper" timing is a very loose concept that should be considered only in the context of a specific platform, as the timing logic differs widely depending on the hardware.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Sun Feb 01, 2015 9:40 am

Which makes me feel like the dt should have this built in - like always make the closest end value a round 1.0 - wouldn't that make sense? If it's advertised as "1.0 every second" then some of these 0.01-0.05 errors can quickly mount up.
B
19
S
6
G
7
Posts: 1,101
Reputation: 6,146

Post » Sun Feb 01, 2015 10:04 am

Having an automated correcting factor built-in would implicitly mean knowing what the exact value actually is. That's just not possible ; you only get values from sensors and timers to a specific accuracy defined by the limitation of the hardware. And having C2 try to compensate to ensure that we have sum(dt, 0.0, 1.0) = 1.0 would introduce time dilation unrelated to the frame time which would break all consistency in the simulations.

And why over 1 sec ? That's arbitrary, and in a different example we might prefer time consistency over 0.1 sec, or maybe 60 sec, etc. The definition of dt is not to accumulate exactly to 1.0 over 1 sec ; it is to represent the time elapsed since the last frame, and one doesn't guarantee the other.

If you know that after x seconds your value should be 123.456, great, you can have a correction factor for your simulation ; but only you know that.

Plus it's an egg/chicken problem ; assuming you want to enforce that after 1 sec your sum(dt) is indeed 1.0... how do you know that exactly 1.0 sec has elapsed, since your measured timer value is inherently inaccurate as it's limited by its frequency and the encoding of floating point values. Exact floating point values just don't exist in computer science ; and you might be surprised to know that the floating point value "1.0" is NOT actually equal to the exact value "1.0" on many common platforms
Last edited by Refeuh on Sun Feb 01, 2015 10:13 am, edited 1 time in total.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Sun Feb 01, 2015 10:13 am

"The definition of dt is not to accumulate exactly to 1.0 over 1 sec ; it is to represent the time elapsed since the last frame, and one doesn't guarantee the other."

actually it is also this, except that if you unfortunattelly remember that the time between two frames is not only variying slightly and that it alsomakes the game only refresh when the screen refreshes, basically, there is no rouding accumulating errors in that case (at least in the first), I would suspect more that the rendering (recalculating) does not happen at the right time you need it, the last frame, it was not at the good angle, the frame after that, it already went too far.

summing up dt will make it add 1 every second at a timescale of 1 (it is the side definition of dt, as it is in seconds per frames), but remember that the game only calculate every frame, so timing cannot be more precise to the point it happens between two ticks.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
22
G
18
Posts: 2,123
Reputation: 17,150

Post » Sun Feb 01, 2015 10:18 am

Framerate is also indeed definitely to be considered and could easily explain why things don't appear aligned properly. The animation shows a major error though, I'm still suspicious... I'll check the .capx if I get the chance !

Though I disagree with the following statement : "summing up dt will make it add 1 every second" ; I would correct to "summing up dt will make it add ~1 every second" with "~1" being "approximately 1, i.e. 1.0+epsilon", as inaccuracy will accumulate over time.
Last edited by Refeuh on Sun Feb 01, 2015 10:20 am, edited 1 time in total.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Sun Feb 01, 2015 10:19 am

Refeuh wrote:And why over 1 sec ? That's arbitrary, and in a different example we might prefer time consistency over 0.1 sec, or maybe 60 sec, etc. The definition of dt is not to accumulate exactly to 1.0 over 1 sec ; it is to represent the time elapsed since the last frame, and one doesn't guarantee the other.


Well, if I read Ashley's post on dt it certainly creates the impression that we can rely on it summing up to 1:
Notice that if you add dt to a variable every tick, it adds 1 every second, because the time between all the ticks over a period of 1 second must add up to 1! Here's an example showing just that. (Adding dt to an object's instance variable is also a handy way to have a timer in an object.)


Also "that's arbitrary" - in that case dt might be any random number, but it just happens to be a fraction of a second.

I'm not necessarily arguing about definitions here - I'd like reasonable precision in things - if it's set to 90 degrees per second and then we get 88,91,92,89,90,88 etc - seems a little vague, that's all.
B
19
S
6
G
7
Posts: 1,101
Reputation: 6,146

Post » Sun Feb 01, 2015 10:22 am

Refeuh wrote:Framerate is also indeed definitely to be considered and could easily explain why things don't appear aligned properly. The animation shows a major error though, I'm still suspicious... I'll check the .capx if I get the chance !

Though I disagree with the following statement : "summing up dt will make it add 1 every second" ; I would correct to "summing up dt will make it add ~1 every second" with "~1" being "approximately 1, i.e. 1.0+epsilon", as inaccuracy will accumulate over time.


I will agree that it does not reproduce on a case where dt is not a fixed number with 1/dt being an integer. it is a general rule, however I think the time expression actually can be used if you need a more accurate way too @Somebody
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
22
G
18
Posts: 2,123
Reputation: 17,150

Post » Sun Feb 01, 2015 10:25 am

Yeah, what puzzles me if the kind of error you get ; several degrees on just a single rotation, that's just plain weird and would not be explained by floating point error accumulation :-?

What I mentioned before certainly doesn't explain the massive inaccuracy you're getting. You could be getting 90.00000001 instead of 90, but 93 or so, that's just odd
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Sun Feb 01, 2015 10:26 am

Refeuh wrote:If you know that after x seconds your value should be 123.456, great, you can have a correction factor for your simulation ; but only you know that


OR... the behaviour should know that - if it's set to turn 90 degrees after a second I'd like that to happen. So it uses dt and isn't 100% reliable, but why then is the dt*90 sprite at a different angle than the behaviour one? Something somewhere seems a little off, you know.

Refeuh wrote:Yeah, what puzzles me if the kind of error you get ; several degrees on just a single rotation, that's just plain weird and would not be explained by floating point error accumulation :-?

What I mentioned before certainly doesn't explain the massive inaccuracy you're getting. You could be getting 90.00000001 instead of 90, but 93 or so, that's just odd

Which is why I built that demo - to show the rather big displacement in angles - so perhaps it isn't 3 degrees, but still plenty. And it doesn't just accumulate, but rather jumps back and forth, so in reality it's even bigger at times.
B
19
S
6
G
7
Posts: 1,101
Reputation: 6,146

Next

Return to Construct 2 General

Who is online

Users browsing this forum: Yahoo [Bot] and 11 guests