My current zoom is setup like this:
Since its "static" numbers it means the effect is very fast when I am zoomed i, and takes way too long when I want to zoom out a lot. Is there a way to make sure that zooming always takes the same time? Or just make it feel more smooth in general?
Remove last two events and use this one:
On Every tick: Set layout scale to lerp(layoutScale, ZoomTarget, 10*dt)
You can try other values instead of 10 to make it faster/slower.
Remove last two events and use this one: On Every tick: Set layout scale to lerp(layoutScale, ZoomTarget, 10*dt) You can try other values instead of 10 to make it faster/slower.
Thank you!! this is great. I guess dt is delta? I am still new to using these smart functions and there isn't much explanation inside Construct for this. Is there a list somewhere of all the logic you can put inside a parameter?
You can look in the manual, namely the system expression section. But in general you can use any sort of math or combination of expressions as parameters. Construct supports expressions with text and numbers but you can convert between the two.
There's even a tutorial about the uses of dt.
construct.net/en/tutorials/delta-time-framerate-2
I ended up taking a dive looking a lerping like this in a framerate independent way.
In a frame dependent way we'd use:
set a to lerp(a, b, f)
Where f is a value from 0 to 1. The speed it moves will vary according to the framerate.
The quick improvement is to just multiply it by dt. 60 is multiplied by it too to make it have the exact same motion as the non-dt version.
set a to lerp(a, b, 60*f*dt)
With that it's largely framerate independent and approximately follows the same motion path no matter the fps, but the path can vary a bit and overshoot.
For full framerate independent version I've found two versions online.
One is from Ashley:
set a to lerp(a, b, 1-f^dt)
and one from Freya Holmer:
set a to b+(a-b)*exp(-decay*dt) or set a to lerp(a, b, 1-exp(-decay*dt))
Where decay is a value from 1 to 25.
But the rate of change is different between the two. Surprisingly if we tweak either of them to use a f value of 0 to 1 and shift it to match the f and f*60*dt version we get the same equation:
set a to lerp(a, b, 1-(1-f)^(60*dt))
Which will give the exact motion no matter the framerate.
Develop games in your browser. Powerful, performant & highly capable.
I ended up taking a dive looking a lerping like this in a framerate independent way. In a frame dependent way we'd use: set a to lerp(a, b, f) Where f is a value from 0 to 1. The speed it moves will vary according to the framerate. The quick improvement is to just multiply it by dt. 60 is multiplied by it too to make it have the exact same motion as the non-dt version. set a to lerp(a, b, 60*f*dt) With that it's largely framerate independent and approximately follows the same motion path no matter the fps, but the path can vary a bit and overshoot. For full framerate independent version I've found two versions online. One is from Ashley: set a to lerp(a, b, 1-f^dt) and one from Freya Holmer: set a to b+(a-b)*exp(-decay*dt) or set a to lerp(a, b, 1-exp(-decay*dt)) Where decay is a value from 1 to 25. But the rate of change is different between the two. Surprisingly if we tweak either of them to use a f value of 0 to 1 and shift it to match the f and f*60*dt version we get the same equation: set a to lerp(a, b, 1-(1-f)^(60*dt)) Which will give the exact motion no matter the framerate.
Wow I didn't consider frame rate at all. This looks like "the" solution to this issue. This is what I was doing:
It achieves a smooth effect and always takes the same amount of time to execute no matter how fast you scroll which is nice.
Just realised I just replied with what the first poster suggested