I once thought I was doing everything right but my game would still act different on 40fps compared to 60fps. It turned out, here and there there was somethings that should have been scripted different.

I don't see anything wrong with the event above; you have dt in the correct place.

I've wondered before about what would happen with C2 games on a 120hz monitor. What do you mean the game is 'going bandanas'? Is it running too fast, too slow, dropping frames?

My understanding is that it's problematic to 'sync' frames in browser engines when the monitors refresh rate differs from the refresh rate of the game. So, TLP is probably 'ticking' 120 times per second on the 120hz screen.

It's possible that you have some logic that should be "*dt", but isn't, and you've never noticed before since C2 goes apesh!t under ~40fps anyway, especially when GPU limted.

Unfortunately, we just don't have a good way of doing framerate-dependant or framerate-locked games in C2; to do so you have to eschew most of the built in behaviors entirely.

For example: CC had a setting called 'Override Delta Time' which would slow down/speed up the game when running at less/more than the intended framerate.

This is basically what you get in C2 if you do event based movement and don't use dt; the game speed is variable, but collisions will always happen the same given identical settings.

However, none of that applies to the built in behaviors in C2, whereas in CC it did.

Woah, you should definitely never have an event which runs as a factor of dt. The underlying Construct 2 engine uses something called "requestAnimationFrame" to attempt to peg the game tick at approximately 60 times per second, but it usually matches the display refresh rate of the browser/computer(nearly always 60hz except in the case of these new 120hz monitors).

This means that in most cases, dt ~= 0.0167 of a second (remember that dt is the elapsed time in seconds since the previous game tick). Obviously though, cpu intensive games and other things can cause the frame-rate to fluctuate. However, on a 120hz display, dt will average ~= 0.008, since the engine will attempt to run the game tick 120 times per second. So then, setting up an event which runs every 60*dt is going to run approximately once a second on a 60hz vsync, and once every 0.5 seconds on a 120hz vsync. Obviously not good, since the game behavior will be inconsistent depending on the hardware.

For setting up events that should run at specific times or intervals, either use the system expression "time" or events such as "Every X seconds". In this case, this event should just be "Every 1 second". For example, if you wanted to schedule a one-time event to run 5 seconds in the future, you could record a instance variable NextActionTime = time + 5. Then in the event:

If time >= NextActionTime & Trigger Once ---> Do something here.

You should use dt as a means of scaling movement/velocity/vectors/etc. So for example, let's say you have some Sprite1 with CustomMovement, and you want it to move approximately 100 pixels every second. Under an event:

Every Tick (aka every game cycle): Move Sprite1 by dt*100.

This way even if dt fluctuates because of slowdown or because of computers with different refresh rates, you are guaranteed a constant rate of movement.

You should use dt as a means of scaling movement/velocity/vectors/etc. So for example, let's say you have some Sprite1 with CustomMovement, and you want it to move approximately 100 pixels every second. Under an event:

Every Tick (aka every game cycle): Move Sprite1 by dt*100.

This way even if dt fluctuates because of slowdown or because of computers with different refresh rates, you are guaranteed a constant rate of movement.

so in what situations would the "dt*100" provide inconsistencies across different framerates? I use it a lot for adding/subtracting from a variable, for things like cooldowns, is that ok?

Yeah, using dt to adjust the speed at which variables are modified is great. DT is there so that by saying Add (DT*X) to SomeVar, you can make sure that it is added at a total rate of X per second.

DT returns the elapsed time since the last game tick (basically the last time the event sheet was processed), and it usually hovers around 0.01667 on most 60hz systems (aka 1/60) because Construct 2 uses underlying v-sync related browser timing.

So for example, if you wanted a variable Life to gradually regenerate at 20 points a second. You would say: Add DT*20 to Life. If you test your game on a 60hz refresh rate display: Every game tick, you are adding dt (~0.01667) * 20, or approximately 0.334 life points every tick, after 60 ticks or approximately 1 second, it will have added 20 points to life.

When running same game on 120hz display rate, every game tick, you are adding dt (~0.0083) * 20, or approximately 0.166 life points every tick, and after 120 ticks or approximately 1 second, again it will consistently have added 20 points to life.

So no matter what your frame rate is, dt allows you to maintain consistent value ratios.

Just avoid using dt as a part of a time-dependent condition in an event, so for example, you wouldn't want to have:

Every DT*60 seconds: Add 20 points to Life.

On a 60hz system, dt is 0.01667, so in this case, the statement is roughly equal to: Every 1 second: Add 20 points to life.

But testing on a 120hz system, dt is ~0.0083, so the statement is roughly equal to: Every 0.5 second: Add 20 points to life. Completely different behavior.

I really though we should use DT each time we use a time value to secure the game behavior depending on the fps variation. But now I read that's not the case.

Sorry to say that (and I blame nobody) but it's unclear and unintuitive. I just want to make games, not formulas for waiting 1 second depending on the fps, the frequency, the size of the sun and the weather outside.

I have the bad feeling I will have to spend a day, changing all the time events of my game. But right now, I don't even know what to change exactly. Ho bother....I'm lost.

What about every tick event ? Wait action ? We should not use DT too in these cases?