Strange behavior of Delta Time

I'm working on a project and trying to improve performance.

On weak machine the FPS is about 40-45, so I expected to see Delta Time between values of 0.025 up to 0.022, but instead the Delta Time is or 0.016 or 0.033, no values in between.

It is important because I want to relay on FPS to toggle effects and control how much particles will be created.

But I cant relay on Systems FPS, because its updated once in a while.

Delta Time is beter because its updated every tick, but it cant give clear unswer because it dont give values in between.

Current version of construct - 225b

Thank you.

Is that a 'every tick' log ?

Most likely cause is inconsistent garbage collection.

On the other hand worrying about minor values won't help with fps.

It's almost always cpu bottleneck that can only be corrected in logic.

Also don't forget the debugger drags the system.

Is that a 'every tick' log ?

Yes, you don't really need to specify "Every Tick condition" to run things every tick.

Most likely cause is inconsistent garbage collection.

On the other hand worrying about minor values won't help with fps.

It's almost always cpu bottleneck that can only be corrected in logic.

Also don't forget the debugger drags the system.

You are talking about improving performance (yes, it is good), but now I'm talking about how dynamically I can relay on performance to change behaviors of heavy things.

"On the other hand worrying about minor values won't help with fps."

I know what I'm doing.

For example I'm talking about turning on/off BLUR effect of a sprites, it is good to have, but I don't want it to lower FPS lower than 45 fps.

And blur is very heavy because it makes about 9 image pixel sampling a tick.

So I want to dynamically turn it off an on, but if it depends on FPS it will happen about once a second, and if I will relay on Delta Time it will flicker even on FPS 59.

"Also don't forget the debugger drags the system."

I know, and because off the fact that constuct debugger drags the system, I created in game debugger that shows the frame rate and other values that matter to me.

Not using a 'every' is still every tick. I know that. Anywayz.

Try this. Just an idea.

Measure wallclocktime in a 'every x seconds' condition. You will see that the measured time will not be 'x' seconds. But a little shorter. How less Frames/second, how more wallclocktime will pass.

The 'real dt' should be 'measured wallclocktime / x'. Warning: u can not use this calculated dt to make pixel movements frame independed, dt (the construct one) is limited (some square function) and therefor more reliable.

The resolution (amount of x) you will have to experiment with.

Frames per second (updated every tick) should be, when you measure wallclock for 1 second / measure wallclokc every tick .

https://

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

Yura G

I was thinking about this and it is because the browser is synchronizing with the refresh rate almost perfectly. That gives smooth animation and motion.

I don't think wallclocktime would help in this situation. What you can do is compare the time elapsed with the number of frames to get the current average fps. Actually fps is just frames/seconds, so you could add up the dt for the last 10 frames and do 10/sum_dt to get a per tick fps.

https://dl.dropboxusercontent.com/u/542 ... e_fps.capx

Things just got even more strange.

The theory that the project syncronising with frame rate of the browser makes total sence, BUT now I noticed that on realy slow frame rates (fps 15-17) the DT is still 0.033 and not 0.05!!! That means that the project starts to slows down and not making ticks last longer.

Acording to manual that should happen on fps 10:

Games are usually unplayable at such low framerates, but it is even worse if they become unstable like that. To help the game stay reliable even at very low framerates, Construct 2 does not let dt get larger than 0.1. In other words, below 10 FPS, dt stays at 0.1. This does also mean below 10 FPS the game starts going in to a slow-motion effect (described earlier as one of the issues of framerate dependent games), however this is usually a better result than the "teleporting objects" problem.

But the explanation might be also be found in the manual, in my project I have some objects with physics, and here is what the manual says about FPS, dt and physics:

Behaviors already use dt

All of Construct 2's behaviors use dt in their internal movement calculations. That means anything moved by behaviors like Platform and 8 Direction don't need any special treatment - they do this already!

Note that Physics is an exception. By default it does not use dt, and therefore is framerate dependent. This is because dt usually has small random variations. These variations can make the same setup in a physics game give different results even if exactly the same thing is done twice. This is often annoying for physics games, so by default it is framerate dependent. However, you can enable use of dt by using the Set Stepping Mode physics action on start of layout, and choose Framerate independent. Note in this mode it still clamps the maximum timestep for physics to 1/30 (about 33ms), because using a very large timestep can cause instability in physics simulations.

But its still strange if using some physics change the behavior of all the project.

Yura G

Look at the system action "set minimum framerate". It's by default 30, so that would explain those dt values. I had forgotten about that.

Yes, the new minimum framerate is 30 FPS. I should update the manual. That means dt will never be bigger than 1/30 unless you change the minimum framerate. Also because the display is v-synced, you will likely only see dt values which are multiples of 1/60.

Thank you all !!! Now my project much smoother, even on slow devices.

Yes, the new minimum framerate is 30 FPS.

Which was, by the way, a really good idea. A lot of problems simply vaporized by doing this.

> Yes, the new minimum framerate is 30 FPS.

>

Which was, by the way, a really good idea. A lot of problems simply vaporized by doing this.

In my opinion the best idea was to be able to set the minimum frame rate.

Faster minimum rate good to prevent many bugs, slower minimum frame rate good for smoother game flow.

So the developer has the option to choose in dependence on his game.