About lerp. Lerp(start,end, 100 / %).
This returns a value between start and end, at (100 / %) of the distance between them. So, lerp (100,200,0.5) returns 150 as value. 0.5 = 100/50 ... or 50% of the distance.
Lerp is not a tweening thing. It returns ONE value. And thats it, and thats all.
This also means that lerp is LINEAIR, there is no smoothing happening at all.
So how we make the lerp return a differend value every tick?
The same way as with (something easy as) a+b=c
We give a or b different values to have a different value for C.
Back to the lerp. The way you (and i, if am not lazy - yeah right) should do it is this way.
lerp(a,b,variable) where we add a certain amount to that variable.
variable % = 0
add 0.1 to variable %
lerp(static number a,static number b, variable %)
Now it takes 10 steps (ticks) to let the lerp return a value that envolves from a to b.
The way we almost all do it, is this way.
lerp(variable a,static number b, static number %)
When you move a sprite from a to b. The position of this sprite is changing, that actual turns a (start) into a variable. Hence CHANGING.
When the distance between a and b gets smaller, because a is moving, and % is static, lets say it is 0.5....
And we gonna move over a distance of 100 pixels.
Then the first tick the lerp returns a value exactly halfway a to b, or 50 pixels
We set the sprite at 50 pixels.
Now the next tick, the lerp start from 50 pixels to 100, and the value halfway is 75.
As you see, the steps get smaller and smaller.
We set the sprite at 75, the next value returned is 87,5.
And here is where the smoothing is happening.
But that comes with a catch. There will be always half of the distance left. So, at the end, it will never reach the end. It will always be at half of the distance to go. This will, used with the camera, give you a shaking camera at the end of the lerping. Solution: stop the lerp when the sprite is a few pixels away from the destination.
About using dt in the lerp. Lerp returns a value each tick. No matter how many ticks your computer will run, at tick x the value is y. But a tick does not take the same time on a slow computer compared to a fast computer. As a result, the speed of moving things is faster on a fast computer. Since speed is essential for gameplay, this difference is in fact cheating.
But, is it cheating if the camera follows a little faster on a faster computer ? I dont think so. Since dt is not static (because dt depends on whats gooing on in a event sheet / tick) the steps the lerp takes are not smooth at all. Using a dt corrected lerp to move the camera can stutter the camera.
If you have to, then use it this way lerp(a, b, 1 - ((100 / %) ^ dt)).
Where (100 / %) goes from 0 to 1. But that also means that you have to make the (100 / %) variable and a & b static, wich is the recommended way, the way i spoke about before.
In short: the lerp should have only 1 variable, else it acts weird. But that is when using it for the camera, not easy to do.
Specific comments about the way you do it.
You want to smooth the camera. So, you want the camera to be slower then the player can move. But. The lerp you use 0.1* 60 * dt (thats is 6 * dt) is FAST. When the game runs at 50 frames, that is like 12% the distance each tick. There is for sure not much smoothing happening. And in some cases it can overshoot its destination.
If i break down you lerp to lerp(a,b,%) ... then ..
a = scrollx >>> VARIABLE (camera moves)
b= (clamp(Player.X,zone.X+(160),zone.X+zone.Width-(160))) >> VARIABLE (player moves)
% = 0.1*60*dt >>> VARIABLE (dt is not static, and its a big %)
So you lerp(from a variable, to a variable, in a variable %)
Sorry, but this cant be smooth with that speed, and it probaly overshoots with such a big speed.
Try gooing for
value = (scrollx,player.x,0.02) ... yes two variables, but they dont jump, they evolve smooth, and they cant overshoot
clamp(value, max, min) ... clamp the lerps returned value
This is how mutch i understand of it at this moment, probaly will change again soon.