1
\$\begingroup\$

This question may be suited better for codereview.stackexchange.com?

I've been experimenting with a camera implementation / matrix SpriteBatch transformations and have run in to a bit of a snag.

The camera's .Update() method updates the transformation matrix and the camera's positioning.

My Player class depends upon the camera in order to work out where the mouse is in relation to the game world for a rotation calculation. This leads to the camera's information being one frame out of date when I need to be. This isn't noticeable when the player isn't moving as the camera's information is correct; even at low speeds I didn't personally notice the problem. However the speed was in excess of ~1000 pixels/sec (a few pixels per frame), it started to introduce a jittery-ness to the player's transformed position. Above and beyond these speeds resulted in very ugly drawing.

My thought process was "So I should update my camera immediately after the player's position has changed instead. Won't that introduce an unnecessary dependency? What happens if my camera isn't following the player or a player doesn't exist?"

My solution:

// in Camera2D.cs

public void ManualUpdate(GameTime gt)
{
    Update(gt);
    _hasAlreadyUpdated = true;
}

public void Update(GameTime gt)
{
    if (!_hasAlreadyUpdated)
    {
        DoUpdate(gt);
    }
    else
    {
        _hasAlreadyUpdated = false;
    }
}

private void DoUpdate(GameTime gt)
{
    ...
}

I can now manually call the camera's .Update() method early if I want to and it won't lead to multiple calls per frame. The jitter has been completely eliminated.

Would you consider this an adequate solution? Can you think of something more elegant?

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

It will depend a fair bit on the structure of your game.

One solution to this could be to convert all output-dependent inputs (ie: mouse inputs) into output-independent "commands" at the start of your update, before anything actually happens. This will completely solve any ordering problems. Kind of complicated, though.

A brute-force option might be to just keep two copies of the camera around. The current camera, and the one associated with the incoming input data (what the player saw when they clicked the mouse).

I think having the camera as an independent object that updates after everything else is probably the simplest solution - possibly the best. It is essentially the same as the "keep two copies" method - except you make everything update in the right order so you don't actually need two copies.

Having your camera update last does not seem to be an "unnecessary dependency". Although having the player responsible for updating the camera does seem to be a bad way to structure things. Make it an independent object and feed it a target position manually or give it a reference to its current target.

\$\endgroup\$
2
  • \$\begingroup\$ Well, the idea behind my solution was that both the player and the game loop can update the camera. The game loop will always attempt to update the camera, but if the player has already called for the update in that frame, then the game loop call does nothing. \$\endgroup\$ Jan 7, 2014 at 8:58
  • \$\begingroup\$ That seems very fragile and seems to "hide" which way the camera is being updated. How you eventually do it will be specific to your code, but I highly recommend giving Camera only a single Update method that is always called. Then make a decision whether Player should push data/commands to Camera, or your main Update method should fetch and feed the appropriate data into Camera (my default recommendation), or your Camera should pull data from its assigned target. (See also.) Probably give Player a GetCameraTarget method. \$\endgroup\$ Jan 7, 2014 at 11:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .