• Create Account

Banner advertising on our site currently available from just \$5!

### #ActualMagdev

Posted 23 May 2013 - 08:47 AM

if (camPos != playerPos) camPos += (playerPos - camPos) * strength;

This seems dodgy to me. What happens if the distance between player and camera is smaller than the length of (playerPos-camPos)*strength? This would happen if strength>1. You don't show how you calculate strength, so I assume it's tied to elapsed time somehow. If strength>1 then the camera will over-shoot the player's position which can possibly cause camera stutter. You might try clamping strength to 1 to keep it from overshooting.

Strength is just a constant between 0 and 1 that I define in-code which is just the strength that the camera follows the player. No time variable is needed.

The problem is in my opinion that the camera may sometimes need to move faster then the player to catch it.

That's not related to the jittering problem, but it can be a problem for some people. I don't see it as a problem though. I don't think it's even possible for the player to move fast enough to leave the camera's view, but if it is, it's not really a big deal. If it becomes an issue then I can just constrain it.

To some degree this is an inevitable consequence of the system you have. You're essentially rounding a real number to an integer and so you have an effective error of +/- 0.5 each time. This means the movement speed in pixels varies by up to one whole pixel from frame to frame, which means it's going to jump ahead and behind a camera moving at a continuous rate. Making the camera track the pixel position like I suggested may reduce the problem but, now I think about it more clearly, it can't solve it.

I think the only real solution is to be able to move both the entity and the camera with subpixel precision, or to lock the camera to the entity pixel position (rather than attempting to smoothly track it after it moves).

Yeah, it does seem like the nature of the system. I have a few workaround ideas in my head, but at the very least, the first fix did make it pretty acceptable and not very noticeable. The jittering how it is now is exactly like Cave Story's jittering, which is barely noticeable, which also reinforces how it's probably not worth fixing further. Thanks a lot for your help.

If I come across anything that makes it better, I'll post it in this thread.

### #2Magdev

Posted 23 May 2013 - 08:46 AM

if (camPos != playerPos) camPos += (playerPos - camPos) * strength;

This seems dodgy to me. What happens if the distance between player and camera is smaller than the length of (playerPos-camPos)*strength? This would happen if strength>1. You don't show how you calculate strength, so I assume it's tied to elapsed time somehow. If strength>1 then the camera will over-shoot the player's position which can possibly cause camera stutter. You might try clamping strength to 1 to keep it from overshooting.

Strength is just a constant between 0 and 1 that I define in-code which is just the strength that the camera follows the player. No time variable is needed.

The problem is in my opinion that the camera may sometimes need to move faster then the player to catch it.

That's not related to the jittering problem, but it can be a problem for some people. I don't see it as a problem though. I don't think it's even possible for the player to move fast enough to leave the camera's view, but if it is, it's not really a big deal. If it becomes an issue then I can just constrain it.

To some degree this is an inevitable consequence of the system you have. You're essentially rounding a real number to an integer and so you have an effective error of +/- 0.5 each time. This means the movement speed in pixels varies by up to one whole pixel from frame to frame, which means it's going to jump ahead and behind a camera moving at a continuous rate. Making the camera track the pixel position like I suggested may reduce the problem but, now I think about it more clearly, it can't solve it.

I think the only real solution is to be able to move both the entity and the camera with subpixel precision, or to lock the camera to the entity pixel position (rather than attempting to smoothly track it after it moves).

Yeah, it does seem like the nature of the system. I have a few workaround ideas in my head, but at the very least, the first fix did make it pretty acceptable and not very noticeable. The jittering how it is now is exactly like Cave Story's jittering, which is barely noticeable, which also reinforces how it's probably not worth fixing further. Thanks a lot for your help.

If I come across anything that makes it better, I'll post it in this thread.

### #1Magdev

Posted 23 May 2013 - 08:34 AM

if (camPos != playerPos) camPos += (playerPos - camPos) * strength;

This seems dodgy to me. What happens if the distance between player and camera is smaller than the length of (playerPos-camPos)*strength? This would happen if strength>1. You don't show how you calculate strength, so I assume it's tied to elapsed time somehow. If strength>1 then the camera will over-shoot the player's position which can possibly cause camera stutter. You might try clamping strength to 1 to keep it from overshooting.

Strength is just a constant between 0 and 1 that I define in-code which is just the strength that the camera follows the player. No time variable is needed.

The problem is in my opinion that the camera may sometimes need to move faster then the player to catch it.

That's not related to the jittering problem, but it can be a problem for some people. I don't see it as a problem though. I don't think it's even possible for the player to move fast enough to leave the camera's view, but if it is, it's not really a big deal. If it becomes an issue then I can just constrain it.

PARTNERS