Timebug or missunderstanding

Hi

I have 2 time related problems I noticed, but maybe I understand something wrong.

please can you confirm or ...

1. modula

in attached example time %4

In the debug layout I get very interesting numbers like 5.57695162006553e-02 (you have to pause in debug view). I think only the debug viewer gets it wrong.

2. time

so I made different clocks that count with different results

for this you need a browser/computer that drops frames

Till now I thought that dt is the correct clock, but actually, it is the wallclocktime

capx https://www.dropbox.com/s/ywbtcryivyrd2 ... .capx?dl=0

1.

That's not wrong. It's just in scientific notation. The e-02 at the end means move the decimal point left two numbers.

2.

Time and wallClockTime will be more or less the same except.

WallClockTime is always advancing even from one event to the other.

Time on the other hand updates only once per frame.

So if you compare the two at the top of the event sheet they will be about the same.

Now time is incremented by dt every frame, but dt is capped at I think 10fps so if the game ever dips below 10fps time will lag behind wallClockTime.

R0J0hound THX

For question 2 and "about the same" I get following results

60 seconds time = 60 dt time

= 63.8 wallclock = Real World Time

= 59.5 ticks/60

thats 5% difference between real world and everything else (except wallclock)

This was is kind of worst case szenario in Edge on my W10 i3-5010U Laptop

Just a note: doesn't matter if I add 30particle effects with 50objects each

Edit: now I made a test with 232 particles (100 objects each) where I get a 40fps framerate

60 time = 64 wallclock = 43 ticks/60

That's still acceptable in my opinion. There's probably some more details about it in ashley's blog or something. What it comes to is if you need to measure a timeframe that matches the real clock, use wallclocktime.

R0J0hound

I can only disagree, sorry.

https://

drive.google.com/open?id=0B1SSuCVV8v74MkdPWUlLWWNqRnM

Behaviors are dt corrected.

All time triggers are dt corrected.

Wich is awesome.

But.

Time and its expression is also dt corrected. That is the only conclusion i can make, bit i am a nut. Still, look at the capX.

dt is the Time, in seconds, since the last tick. To calculate this, dt is using Time. But because Time is also dt corrected, dt gets smaller and smaller with heavy ticks, and Time and its expression gets slower and slower.

I can (i probaly am) be wrong in the explination.

Yet, i think dt should be calculated with the wall clock. And that is for sure not the case.

Time has to be dt correlated, else we can have no pauzing game. But with a right calculated dt, that should be no problem.

Can't look at the capx because it uses plugins I don't have installed. You can look in preview.js for the exact implementation but if you had to do dt and time with the event sheet this is what it would look like:

global number time=0

global number previoustime=0

global number dt=0

every tick

--- set dt to min(0.1, wallclocktime-previoustime)

--- set previoustime to wallclocktime

--- add dt to time

R0J0hound

Knowing the real dt is helpfull to state the problem. But it does not solve it. You cant inject it in the behavours, you cant alter the time triggers.

But, you can use it to timescale the system, as in this capX. No plugins in that one.

https://

drive.google.com/open?id=0B1SSuCVV8v74dDhld0cwSzhBNlE

Now everything depending on time is correct, including dt and the time expressions. That also answers fm4fanAT question.

Your math is way better then mine. You probaly know how to optimize this much better. But i think this is the correct workarround if time is very importand in a game with heavy ticks.

I don't see any reason for it. If dt wasn't limited objects would teleport quite far if you hit a loop like that.

Hi, still confused

99Instances2Go - tried your file and was surprised that a single (empty) loop has such an impact

So with your capx I got following result

10 sec time = 13 to 30 sec wallclock / real world time

result depending on browser and if the computer is busy with something else (so sometimes WAY off)

Now one of my problems with time:

if I make an event like every x second

then actions inside the "every 1 second" runs completely depending on the computer speed (so maybe only 3 times in 10 seconds real world time)

So I can't trust C2 that 1 second is really one second and have to make a big workaround with wallclock?

Still it isn't an issue if your game doesn't lag. If it's really bothering you, file a bug report. I'm sure Ashley can give you a much better explanation than me.

time is just the game clock, it's advanced by dt. Dt is affected by the time between frames and timescale. Now when the time between frames gets too big c2 will limit it, which is what you have a problem with. This was done on purpose to slow down instead of letting objects move too far per frame and miss collisions.

Consider an object with a speed of 600.

At 60fps it will move 10 pixels per frame.

At 10fps it would move at 60 pixels per frame.

So if walls were only 32 pixels wide, the object could move right past it.

Limiting dt helps with this.

If a correct time is realy importand then "for every x seconds" will not be trustable. This is true.

Its no bug, it is intended to be able to pauze the game. That is why time has a dt factor by default. If i have to choose, i choose for 'able to pauze'.

On the other hand, there are workarrounds.

1/ Or you use wallclock to code your own time.

2/ Or you can use the timer behaviour to trigger, and timesscale only the object with that behaviour attached.

3/ You can also try to convince R0J0hound, because this dude has the skills to make u a wallclock based time plugin.

The comment about 'teleporting objects' i have to figure out myself, later today.

R0J0hound and 99Instances2Go

THX for clearing things up for me

I don't know if this is a bug or a feature and I'm new in C2 so I just was surprised

And I don't know which elements are affected (but I think all of them like timer, wait, ...)

A small example:

Let's build an Astroids clone where an object appears every second and if you have shot 99 astroids your game ends and shows the time it took.

The obj_Astroid - thanks to eg. behaviour bullet which uses dt - will always move the same speed. Doesn't matter which hardware.

But time... (kinda worst case)

Now the classic way of doing it would look something like

every 1 sec | create obj_Astroid

if g_counter >= 99 | set text to wallclock

So if I run on a fast computer I can finish the game in 100seconds

On a slow one the objects appear only every 2 sec in RealWorldTime so I can only finish in 200sec (easy to paly but bad time)

now I change set text to time

The slow computer still gets an obj_Astroid every 2 sec but the finished time shows 100 even if RWT is 200 (almost like cheating)

build custom x seconds

maybe solved - but only time will tell

I still think I will use every x second in future, but now I know that I can't use CS2 the easy way for e.g. Speedrun Games and think about "timed levels" a little bit longer

There is no way to keep fast objects on track in heavy ticks. Lets translate 'heavy ticks' to 'low dedection rates'.

Remarkable is that the system that calculates angles gives up before the collission dedections give up.

So, anyway, the objects will indeed fly all over the place in heavy ticks. WITH the current calculation of dt. A correct calculated dt will not change that, but at least 'time' and its expression will be the right 'time'.

double, sorry

fm4fanAT

Late reply, but I've found a solution to this in another topic. The is the system action: "set minimum framerate". By default it is 30 which means dt will be limited to 1/30. You can set this to 0 if you so desire and dt won't be limited. It's a trade off though. When dt isn't limited you can have issue of fast moving objects passing right past obstacles without hitting them.