Is timing in C2 accurate?

Discussion and feedback on Construct 2

Post » Sun Feb 01, 2015 10:30 am

I still think this is the expected behavior of C2 since it recalculates every frame, not constantly (which implies it is innacurate to an extend), however @ashley could explain it if that is not the case.

I do not remember the exact chrome command to break v sync so the frame rate can go very high, if you find it and test it, and that the result is better, that would give one information valkdating my version of the fact.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Sun Feb 01, 2015 10:55 am

I think the example is flawed ; it assumes that "every 1.0 seconds" is actually accurate and uses this as reference. I wouldn't rely on "every x seconds" for anything that needs to be accurate, as there's little in the documentation about the scheduling of these triggers.

I modified the capx to just keep the rotate behaviour, and change the dt logic to a simple :
Every tick > set angle to Self.Angle + rotateSpeed * dt

The accumulated dt error is minimal and the behaviour and dt bars overlap perfectly from a visual point of view ; this proves the behaviour logic and dt logic are consistent with each other.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
23
S
9
Posts: 237
Reputation: 2,207

Post » Sun Feb 01, 2015 11:08 am

I modified the example further, to log the system time every time the dt bar completed a full circle ; the difference between each iteration is less than 0.0001s which is within expected margin given the frame time.

I'd say blame the "every x seconds" ; use it for gameplay stuff where accuracy doesn't matter (e.g. "spawn an enemy every 2 seconds" ; it doesn't really matter if it's 1.9 5 or 2.05), but not for timing behaviours
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
23
S
9
Posts: 237
Reputation: 2,207

Post » Sun Feb 01, 2015 11:09 am

I'll need to check your version once I'm back on pc, but then again if an example is flawed because it assumes stated system functions act the way they are presented - are they really flawed?

Most of my questions are based on the assumption that one can use just the behaviours and basic events to get reliable results, yet almost every solution ends up with "use these custom events with variables" and so on.

There was another question about "sub tick" object creation and movement and it seems the answers are also "basically programming". Call me lazy, but I would prefer reliable solutions using the built in systems.

As for the precision - then why isn't Every X seconds precise if one can get that precision with events?
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Sun Feb 01, 2015 11:41 am

The good news is that you can rely on behaviours :D

I believe Ashley said in other related topics that "Every X seconds" is not affected by the framerate, it runs based on real-world time rather than ticks. Therefore I am assuming it must be running on a less accurate timer (system clock, maybe ?), or using a parallel scheduler.

The only flaw in your example, if my analysis is correct, is that you were using a less accurate method (world time) to time a more accurate method (tick based).

I'm pretty sure you should be able to replace "every x seconds" in your example with a Timer behaviour, which would then be tick based, and then get consistent results.

Basically, see "every x seconds" as a way to schedule high-level events, e.g. "every ~20 seconds spawn a new monster", not as something to be used for animation or frame times.

As for "sub tick", I can definitely see cases where that can be useful (usually used for particle effects, etc.) but that's usually very specific and hard to make generic.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
23
S
9
Posts: 237
Reputation: 2,207

Post » Sun Feb 01, 2015 3:20 pm

The main issue here is game engines run in discrete steps (frames), rather than continuously. They create the illusion of continuous motion with many small incremental steps at a relatively fast rate (normally 60 FPS). A smaller factor is system timers are not always perfectly accurate, so dt has small random variations. And an even smaller factor is adding up floating point numbers accumulates error with every addition.

If you rotate an object by 90 * dt degrees every frame at 60 FPS, then it will be rotating about 1.5 degrees per frame. You only need 'Every X seconds' to be off by a single frame and you have greater than 1 degree error, without even taking in to account the small random variations in dt, or the floating point addition error. Even if all timers were perfect and the framerate was perfect, at 60 FPS then 'Every 1 second' is due to run exactly at the time the 60th frame runs. Then you only need the tiniest bit of random jitter in the timing systems to cause the next timer to fall on a random frame: either just before when it's due (so that frame), or just after when it's due (so the next frame). In practice there's probably enough jitter to throw this out by 2 frames.

Solution: don't expect to get the right number of frames. A better way to achieve this type of thing is to use an algorithm like "rotate at 90 * dt degrees per tick until it is clockwise of its destination, then assign the end value again". The "assign end value" bit means that if you end up somewhere like 90.0001 degrees (due to any of the other sources of error), then you just set it back down to the exact value of 90.

None of this is specific to C2 - it will be the case with any game engine using this approach.
Scirra Founder
B
395
S
232
G
88
Posts: 24,368
Reputation: 193,746

Post » Sun Feb 01, 2015 3:38 pm

Thank you once again, Ashley, for the detailed explanation. I see that custom event work is the solution. It would be great to have a timer component for the simple movements like rotation, bullet, etc. If it's 0 the movement doesn't stop, if it's a time it stops around that time and at the right distance/angle instead of around the time and around the distance as it is now (using Base events).

Why do I keep on about automating things that can be overall achieved with events? Laziness, user friendliness and being true to the "no coding needed" mantra of C2.

If I may ask, though - why does dt dt*90 end up at a different distance from the behaviour?
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Sun Feb 01, 2015 5:41 pm

Refeuh wrote:The only flaw in your example, if my analysis is correct, is that you were using a less accurate method (world time) to time a more accurate method (tick based).

I'm pretty sure you should be able to replace "every x seconds" in your example with a Timer behaviour, which would then be tick based, and then get consistent results

The results were about equally bad - like Ashley explained above an "error" of up to 3 degrees is apparently nothing special, so, like you mentioned something like this is called for (this was the cleanest and leanest I could come up with):

Image

It's basically imperceivable to the naked eye that there's a mild jump near the straight angles. What is annoying, though, is the need to set up the timer behaviour on startup - why isn't that streamlined like the other behaviours?
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Mon Feb 02, 2015 8:03 am

[Not my idea] There's two tricks I mostly resort to to ensure sync [timing]...
klang-become-one-with-the-music_t116761
Playable games:
http://jamesxxxyz.newgrounds.com/
Newest: Blue and red arrows
Latest update: Blue and red arrows

What you want in C3?
viewtopic.php?f=146&t=122050

Youtube: https://www.youtube.com/channel/UCLE7Ml ... /playlists
B
11
S
4
Posts: 281
Reputation: 1,543

Post » Tue Feb 03, 2015 8:33 am

So, r196 has had some changes, related to this post, I suspect:
Delta-time measurements are now based on the browser's rendering timestamps instead of time measured from JS code. This means motion should be smoother since it is based on when the browser is scheduling frames instead of when the JS code happens to run.

For one dt is suddenly way more accurate (no clipped to 2 digits):
Image

But at the same time - look at that framerate - same capture conditions, there's almost no CPU load when it runs without capture and yet unlike the previous example it never goes over 40 fps. And those DT numbers - are we in sub-tick territory now?
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: gamecorpstudio, SaRaB and 3 guests