I'm making a camera which tracks the player. I am using a basic algorithm to calculate a position for the camera relative to the player. Then I am taking an average of this over the last x number of frames. This creates a nice chase camera which always slightly lags and evens out the players movements.

Where I am running into trouble is with delta Time. How can I weight each entry in my list of previous positions so that delta time is taken into account. Currently I'm having an issue where, when the frame rate is particularly slow, the camera lags really far behind the player.

I should also mention that currently I am adding each entry ElapsedTimeInSeconds/0.01f times to give the weight. So the average is effectively over fewer frames if the frame rate is slow. I also tried entering values as Value * DeltaTime, then keeping an average of delta time to divide the values by when I get them back out of my average tracking class but that didn't work.

What I think I really want is an average over the last n seconds rather than the last n frames.

  • \$\begingroup\$ Not a direct answer, but have you considered using spring physics to model your chase camera? Here's an implementation in XNA taken from this sample. \$\endgroup\$ – David Gouveia Apr 27 '12 at 2:38
  • \$\begingroup\$ The camera averaging is working really well as it is, I just want to fix issues caused by the frame-rate dropping. It gives me a lot of the desired effects like lagging more behind the player when their moving fast but catching up and fixing on them when they've stopped. \$\endgroup\$ – OriginalDaemon Apr 27 '12 at 16:46

Because your historical positions are recorded with delta time "baked in" applying any corrections on top of that seems excessive if not counterproductive. You don't want to change their values, but you do want to change how much the history affects the current target position.

This might work for you:

Pick an ideal framerate, say 1/30, and use that as a baseline to represent 100%. This 100% applies to how much the history affects the current camera target so at any framerate of your ideal 1/30 or faster your tracking acts as normal.

When your framerate slows down below 1/30 you want that 100% to drop so that the historical positions affect less and less of the camera's current target which will ease the camera closer to your target the slower the game is running.

| improve this answer | |
  • \$\begingroup\$ Good idea. I'll try it later to see if it works. \$\endgroup\$ – OriginalDaemon Apr 27 '12 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.