Body.velocity + Camera.follow is choppy

[hustlerinc]

I'm doing a 2D top-down game with arcade physics and I've run into a problem. When the camera is following a sprite moving with body.velocity the sprite starts jerking back and forth as if it's vibrating. This doesn't happen if the camera isn't following the sprite. Also if I change

sprite.body.velocity.x = 48;

into

sprite.x += 1; 

the movement is smooth even when the camera is following the sprite.

 

I've found a few results on Google where people seem to have the same issue, but no solution. Does anyone know how to fix this?

[valueerror]

which version of phaser are you using?

[hustlerinc]

which version of phaser are you using?

2.1.4 dev branch (Tilemaps are broken in 2.1.3 so I can't use it). But the issue is there in 2.0.7 too (don't have any older versions lying around) when I test it. I don't think it has anything to do with the dev branch.

[lewster32]

I know this is sidestepping the issue somewhat (which I believe is related to when the camera and physics do their updates to the objects - I think the camera ends up a frame behind the physics updates) but I created a really simple little smoothed camera routine which you could maybe make use of? http://jsfiddle.net/lewster32/5a866/

[hustlerinc]

I know this is sidestepping the issue somewhat (which I believe is related to when the camera and physics do their updates to the objects - I think the camera ends up a frame behind the physics updates) but I created a really simple little smoothed camera routine which you could maybe make use of? http://jsfiddle.net/lewster32/5a866/

In the example you're using per pixel movement (which doesn't have this problem), so it's hard to say if that will solve the issue. Could you maybe paste the relevant parts of the code here and I'll try it with my code (I tried adding physics and velocity to the fiddle but I don't know how to do it the way you set it up)?

[lewster32]

It should work regardless of how you move your character. First of all take out your game.camera.follow(player) code, then add the following to your implementation:

// ... in your state or game setup...this.cameraPos = new Phaser.Point(0, 0); // store the smoothed virtual camera positionthis.cameraLerp = 0.1; // specifies how tightly the camera follows; 1 for locked to object, lower values for smoother following// ... in your update function...this.cameraPos.x += (this.player.x - this.cameraPos.x) * this.cameraLerp; // smoothly adjust the x positionthis.cameraPos.y += (this.player.y - this.cameraPos.y) * this.cameraLerp; // smoothly adjust the y positionthis.game.camera.focusOnXY(this.cameraPos.x, this.cameraPos.y); // apply smoothed virtual positions to actual camera

[hustlerinc]

 

It should work regardless of how you move your character. First of all take out your game.camera.follow(player) code, then add the following to your implementation:

// ... in your state or game setup...this.cameraPos = new Phaser.Point(0, 0); // store the smoothed virtual camera positionthis.cameraLerp = 0.1; // specifies how tightly the camera follows; 1 for locked to object, lower values for smoother following// ... in your update function...this.cameraPos.x += (this.player.x - this.cameraPos.x) * this.cameraLerp; // smoothly adjust the x positionthis.cameraPos.y += (this.player.y - this.cameraPos.y) * this.cameraLerp; // smoothly adjust the y positionthis.game.camera.focusOnXY(this.cameraPos.x, this.cameraPos.y); // apply smoothed virtual positions to actual camera

Unfortunately it didn't work. I played with the cameraLerp value from 1 to 0.005 but even if it got a little better that low it wasn't really playable and either way sooner or later the camera has to adjust to the sprite speed and the chopping intensifies. I did notice that it gets better if I double the velocity (with and without camera.follow() ), but it's still noticeable and I don't want the sprite to move that fast.

 

If I can't find a solution the easiest fix might be to just change the physics system. Would Ninja physics decrease the performance on mobile devices alot for simple physics?

[lewster32]

Arcade is the fastest of the physics implementations in Phaser. Ninja is for all intents and purposes broken anyway, and I believe it's been deprecated now so it'll probably disappear soon. Any chance you could upload your game or an example of your specific problem so we can take a closer look at what's going on?

[hustlerinc]

Arcade is the fastest of the physics implementations in Phaser. Ninja is for all intents and purposes broken anyway, and I believe it's been deprecated now so it'll probably disappear soon. Any chance you could upload your game or an example of your specific problem so we can take a closer look at what's going on?

Sure, heres a .rar with all the files I use: https://www.dropbox.com/s/s78blrk8yj641y2/top-down.rar?dl=0

 

It's not much, just 100 lines of code so whatever I've done wrong should be easy to find.

[Skeptron]

lewster32 I really find your implementation of a smooth camera following really interesting. Unfortunately I am quite bad with Javascript : how would you properly override Phaser.Camera's methods to include your behavior in the object?

[lewster32]

The Camera object could do with a bit of work if this was to be properly implemented within it. For now, the way I did it in my fiddle would be a lot easier.

[Skeptron]

It is quite simple and effective, that's true, but it does not fit every game. For example with your code it is quite hard to unfollow a character to follow another one. Still doable, but it adds some code for a use-case which is already handled in the Camera object. It's just too bad we can't redefine the behavior of the camera.

[lewster32]

It's very easy to adapt it to follow and unfollow, here's a modified version where you can set a target to follow: http://jsfiddle.net/lewster32/e6cfnxbo/

 

When I get some time later in the week or the weekend I may have a look at adding this to the Camera object as a PR rather than a patch, which would be difficult with the way it's currently written.

[Skeptron]

Yes like I said it is possible, but it adds code in the update() function, which begins to be huge in my project, and I'd rather have this code in its own object's update function (the camera's update function, in fact), where it truly belongs.

 

Thanks a lot though for the  explanation, the great code sample and the amazing support! I'll definitely consider using this code untill something even cleaner comes up.

[valueerror]

with this code @lewster..  it seems the camera would never come to rest or am i wrong? is always trying to focus even if the object is not moving anymore..  

 

x.8, x.9, x.99,x.999,x.9999    it will get closer and closer but never actually reach the target..   

 

i'm doing the same thing in my code for examle with game scaling but today i wondered if it wouldn't be wise to catch the point where the final target is near x,9999999999 (maybe x.9) would be near enough to stop the camera..  

[Dr. john doe]

I just tested using a incognito tab in Chrome and the "jittering" is gone, and now the sprite movs smoothly This is really strange.

[hustlerinc]

I just tested using a incognito tab in Chrome and the "jittering" is gone, and now the sprite movs smoothly This is really strange.

With the code I attached? Still does it for me in incognito aswell.

[jpdev]

Since RC12 2.2.0 still has this bug (just ran into it) I posted this github issue: https://github.com/photonstorm/phaser/issues/1377