C2 games and 120hz monitors (*dt problem?)

Aphrodite

yea i rephrased it, you quoted a post i edited a few seconds later realizing what i said sounded off from my exerience

I'd start with:

Don't use dt in conditions. Use it in actions.

Then only use dt if you can imagine a scenario where you might want to timescale the output.

And all behaviors should have dt built in.

newt Thank you! That I can understand, super helpful : )))

(Sorry if I sound like a dumb 8 years boy. It must be super irritating for you guys, really sorry. But picture someone who never did any math at school due to a cursus only focused on arts. I'm wayyyyy behind you all.)

Aurel yeah, that is the issue, it is considered so basic that it is hard to explain for those who understand it, but when you do not understand it it is hard to get into (kind of like "why 1+1 =2", hard to explain, and if you do not know it, it won't come like that).

try to think "if the game ran twice as fast the event sheet, would the action be affected?", every x seconds will not, since it will run every x seconds (it Ill be checked twice as much, but still will only be true every x seconds), not every x frames. triggers won't also (as the manual states they do not run in the normal loop logic checked every tick).

but changing the position of something every tick by hand to make it move fluently will (the events runs twice as much in the same duration).

behaviors are mostly defined with "by seconds" so it is time dependant and not framerate dependant.

Let me just add that you should assume you might want to use timescale in all projects.

Aphrodite newt Allright, pretty clear in my head now. Thanks again, guys. And also to everyone else who patiently tried to explain : )

Let's get rid of these useless *dt in some events, and add it where it could be missing or done wrong.

(I'm editing the 1st post to write the answer in plain text: I was making things wrong.)

Oh, and thanks Ashley for the timescale test.

The game is using timescale a lot BUT on the 2 events which make the game crazy.

I'm using your idea to be sure the fix will work, thanks again.

— - I agree with your calcs when using large lerp values. For the case A = lerp (A, B, X), the lerp equates to A = A + X * (B - A).

So, the lerp won't work correctly if the value that is added to A (which is X * (B - A)) is greater than the difference between B and A ( which is simply B - A).

So, X * (B - A) must not be greater than B - A

So, at the max value for X the equation becomes:

X * (B - A) = B - A

So max X = (B - A) / (B - A)

max X = 1

I think it's a good lesson (for me, at least!) that care should be used when putting dt inside a lerp in this way, because an inadvertent value greater than 1 will cause unexpected behavior.

newt I love your posts on the forum, always so short and to the point. makes me laugh

To end this story, I just made the timescale check everywhere I could in the game: 2 events had a dangerous use of *dt.

(Too bad you could see their effect in the very first level of the game *cough*)

Thanks again for your help, much appreciated.

I can't do the math to prove it properly, but FWIW I've found a proof by counter-example that A = lerp(A, B, dt) is not correct! It's a very good approximation, and in practice probably works OK, but consider this:

In this case the remaining distance m after one frame is (1 - dt). The remaining distance after N frames is (1 - dt)^n.

At N frames per second, dt is 1 / N. Therefore over one second at N frames per second, the remaining distance is (1 - (1/n))^n.

You can prove this isn't exactly correct just by substituting n = 30 and n = 60 for 30 FPS and 60 FPS:

(1 - (1/30)) ^ 30 ~= 0.36166

(1 - (1/60)) ^ 60 ~= 0.36479 (different!)

So there you go. It's a tiny difference and would probably never be at all noticable. But I think this proves the correct form is lerp(a, b, 1 - f ^ dt). Maybe this deserves a blog post...

It's really interesting that this is different, yet so close. I always did have a weird feeling when doing lerp(0,1,x*dt), and in fact I've mostly migrated away from doing lerp like that in my code, since in a lot of cases, it *is* bad practice, as some people have brought up. I don't agree that it's always bad practice, however, as it provides very pleasing effects when used on things like camera movement, etc.

Anyway, Ashley I'd love to see a blog post on this!

This is a strange one, because intuitively it seems like lerping by N*dt should work just fine...until you lay out the math. Definitely worth a blog post though, considering a lot of people have probably been using it wrong.

Ashley

maybe a blog post would indeed make people stop doing this (you could maybe also consider reading the other wall of text I did that shows that if x * dt becomes large, due to what operation lerp is in reality, it can become broken at low framerates, I could try to sum it up and even do some maths if that helps stopping that use of lerp once and for all)

TiAm

the thing is "lerping by N*dt (wierd verb I must say so myself)" is just doing a progression a1 = a0+N*dt*(b-a0), if you study it enough you may be able to find out how that works, if N*dt changes, the progression changes too but notjust like it will become the same after some time, the number of frames to go into 95% of a to b will be shorter at lower fps, BUT the allure is changed too, and it can become pretty different at extreme cases (I explained it earlier but did not proved it once and for all).

I wonder if perhaps a new expression for speed would be a good idea.

Something that would have dt applied, but be simplified to pixels per second, like say speed().