Update Camera manually after Camera's target updates, bypassing the game loop. Is this a good or bad practice?

Question

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?

Answer 1

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.