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

Discussion and feedback on Construct 2

### » Sat Jan 24, 2015 10:36 pm

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...
Scirra Founder
B
415
S
247
G
92
Posts: 25,281
Reputation: 200,831

### » Sun Jan 25, 2015 3:54 am

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!
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,749

### » Sun Jan 25, 2015 6:04 am

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

Same here, it'd be great to see a distilled version of this thread.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

### » Sun Jan 25, 2015 6:13 am

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.
B
45
S
10
G
11
Posts: 1,106
Reputation: 9,732

### » Sun Jan 25, 2015 6:38 am

@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).
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
23
G
18
Posts: 2,123
Reputation: 17,200

### » Sun Jan 25, 2015 6:52 am

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().
B
179
S
50
G
207
Posts: 8,719
Reputation: 128,306

### » Sun Jan 25, 2015 7:13 am

newt wrote: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().

you mean like

a=speed(a, b, speedvalue)?
you should be able to do it with two min or max functions depending on where a is compared to b.

in a every tick logic:
a is inferior to b : set a to min(a+speedvalue*dt, b)
a is superior to b: set a to max(a-speedvalue*dt, b)

speed value being in value per seconds
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
23
G
18
Posts: 2,123
Reputation: 17,200

### » Sun Jan 25, 2015 7:49 am

newt wrote: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().

I think that would definitely just complicate things. The current method of using dt appropriately is perfectly fine, so long as the programmer knows how to use it properly. For someone without a math/programming background it can be a hard concept to wrap your head around though, so more education would always be nice. Perhaps even include a section about dt in the Beginner's Tutorial?
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,749

### » Sun Jan 25, 2015 7:58 am

Candid question.

Let's say 90% of the C2 users love C2 because it's simple, fast, and allow to focus on your game production while a brilliant mind/puppetmaster hides behind the scene. Couldn't something like this make sense to avoid beginner's mistakes with *dt and lerp?

Most of the users could use these presets, and if in need of more control, switch to the lerp expression.
When I see how crazy simple some C2 operations can be (the incredible save system, the shaders, the behaviors presets...), I really think it would completely fit with the core C2 audience. Without taking anything from the pros.

Stupid idea?
B
19
S
6
G
1
Posts: 307
Reputation: 2,500

### » Sun Jan 25, 2015 8:19 am

@Aurel define smooth, slow and fast, and I would say it may be something to potentially consider (even though I see more this as an expression meant for that, rather than misusing lerp)

also the beginner error with lerp comes only from one thing: someone used lerp that way, he liked it, and so everyone did use it, whereas it just does not make any sense, and then they assumed adding dt to the detourned formula would work (spoiler: it does not really).which is why even the potentially correct ashley version I would be agaisnt as, it is not a linear interpolation between a and b that is done, it is another calcul that just is similar math wise. Lerping does not mean, and will never mean, going smoothly from a to b, it just does not.

just understand what something does before using it, it is as easy as that.

you want to do a transition? then just do it, make the value increase more or less with time depending on what you want, we can help find which expression is the best for that if you need, you want a linear transition? then a good use of lerp willdo it, something slower first then quicker then slower again? cosp can do that, something fast first then slower that never reach the goal but divide the distance each second by the same number? the bad lerp does that, but an exponential formula will do the job in a way you can control fully and that will work even if dt changes.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
23
G
18
Posts: 2,123
Reputation: 17,200

PreviousNext