0 Favourites

About "Lock cameras" problems.

  • Hello everyone, i am developing a Metroid-Vania like engine with mini-maps and stuff, but i having some problems with the camera style that i am using.

    First of all, i'm using a smoth following camera based on the area from the map that locks some rooms, and you have to enter to the camera follows the player to another screen yet in the same layout. The problem is when the player and the background with parallax effects, starts to shake, this happens when i have a room bigger than the screen size, since i am using 320x180 is a quadrant to make a room in the mini-map i have to use a sprite (called zone) with the condition if the player is overlaping this object and every tick, and for the action i use System\Scroll to:


    [b]Y:[/b] [code:hwr10nlg]lerp(scrolly,(clamp(Player.Y,zone.Y+(160),zone.Y+zone.Height-(160))),0.1*60*dt)[/code:hwr10nlg]
    This code seems to make the screen shakes too when you are walking and you stop.
    I made this video too, better images than words. [url=https://youtu.be/LOlK9hTLsUc]Movie[/url]
    So there is a way to fix this? Or there is a alternative way to do this? And sorry about the lag in this video.
  • Few questions: I'm correct to assume this uses point sampling? And do you have pixel rounding enabled by any chance?

  • 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.

  • Construct 3

    Buy Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Buy Now Construct 3 users don't see these ads
  • PixelRebirth

    Yes, i am using this configuration.


    Thanks, i think this can help, however there is a lot of information that i can't understand yet, so i will take some time to figure out this.

    One thing i know for sure, my game will run at 60fps, the smoothing camera is not truly necessary, but what i really want is locking the camera in some areas, and in another areas the camera will be free to move, just like metroid. And I'm not the right to request a capx file, after all, you explanation was awesome, i am just dumb for now, i have to study more of this codes to learn more. Oh my brain will melt. hehehe.

  • PixelRebirth

    Yes, i am using this configuration.

    Well, I guess since lerp moves in increments that end up being incredibly small and you're forcing the game to stick to integer positions... there's your problem

    You could have smooth movement of course by disabling pixel rounding, but that won't look pixel perfect anymore as I'm sure you are aware.

    Didn't entirely read what 99Instances2Go said, but I'm sure there's merit to it. You could indeed try to have lerp jump to it's actual (rounded) target position when the difference is reasonably small. I've done some similar things in the past.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)