Support cutscenes and demos in the photo mode

[rr-]

Checklist

• I have read the coding conventions
• I have added a changelog entry about what my pull request accomplishes, or it is an internal change

Description

Resolves #1672.

[aredfan]

I found 2 issues:

• The Take picture sound only works once in cutscenes.
• There's a black screen for a short duration when loading the second cutscene. /play 17

[lahm86]

The actors seem to reset at the end of the cutscene back to the first frame if you've used photo mode.

I think the animations will just loop by default, so it could be a desync problem?

Similarly if you use it in the Vilcabamba demo, there seems to be desync as the remainder will play out differently (in my test a wolf remained alive).

[rr-]

@aredfan @lahm86 I've addressed both issues. Additionally, I've adjusted the Q/E/W/S inputs to align perpendicularly to the current vertical axis. In other words, the sideways and height-wise camera movements should now feel more intuitive when the player is looking directly at the ceiling or floor.

[lahm86]

Cutscenes look fantastic, everything looks great there.

The Vilcabamba demo still desyncs for me unfortunately. Tapping briefly in and out of photo mode is enough to cause it. I wonder if there is something calling Random_GetControl somewhere while in photo mode, which could cause he AI behaviour to change when the demo resumes? I can't think of anything that could be doing this though, but it's maybe a lead.

Re the change in controls, the fix for the A/D issue when facing vertically looks great. I do however feel that overall movement is a bit more restrictive than before. I think this is because the previous implementation allowed any combination of QEWASD e.g. previously you could hold WA and the camera would move diagonally, but now A takes precedence and the W input is lost until you release A. You could also previously hold Q/E together with WASD to combine that movement. The rotation behaviour remains flexible e.g. I can rotate up and right or down and left at the same time. This is perhaps just my preference - I appreciate that you can still get to where you need to go, but I do prefer the previous support that we had.

[rr-]

@lahm86 Thanks. It turns out the demo desync was caused by restoring user preferences too early – I had most of the enhancements disabled, which is why I couldn't replicate the issue. I've also resolved the ghosting issue with inputs – sorry for the regression there.

[lahm86]

@lahm86 Thanks. It turns out the demo desync was caused by restoring user preferences too early – I had most of the enhancements disabled, which is why I couldn't replicate the issue. I've also resolved the ghosting issue with inputs – sorry for the regression there.

Not a problem, after I posted the above I wondered if it was maybe not possible with the A/D vertical fix. Thank you!

[lahm86]

Everything looks fantastic, thank you 😄

[aredfan]

@rr- I can confirm the issues mentioned above are fixed, thank you.

I've noticed a new issue. In photo mode, if I hold down left then the camera will stop turning once it faces a specific direction. This doesn't happen when I hold down right.

[lahm86]

@rr- Re @aredfan's finding, this was also an issue I had in the original build, but casting the shift to int16_t resolved it then. Perhaps there is a better approach though.
Apologies, I missed this one.

[rr-]

@rr- I can confirm the issues mentioned above are fixed, thank you.

I've noticed a new issue. In photo mode, if I hold down left then the camera will stop turning once it faces a specific direction. This doesn't happen when I hold down right.

I can't reproduce this – can you link a save?
EDIT: I think I see what's wrong – I need to look at either the ceiling or the floor.

[lahm86]

@rr- I can confirm the issues mentioned above are fixed, thank you.
I've noticed a new issue. In photo mode, if I hold down left then the camera will stop turning once it faces a specific direction. This doesn't happen when I hold down right.

I can't reproduce this – can you link a save? EDIT: I think I see what's wrong – I need to look at either the ceiling or the floor.

Just checking if you saw my comment about the cast (tested this on the current PR code and it resolves it).

It happens in this save, so just enter photo mode and hold left. It stops at 180.
save_tr1_00.zip

diff --git a/src/tr1/game/camera.c b/src/tr1/game/camera.c
index 45977ccf..9ec552a2 100644
--- a/src/tr1/game/camera.c
+++ b/src/tr1/game/camera.c
@@ -377,11 +377,11 @@ static void M_UpdatePhotoMode(void)
 
         if (g_Input.left) {
             M_PhotoModeRotate(
-                g_Camera.target_angle - CAM_ROT_SHIFT,
+                g_Camera.target_angle - (int16_t)CAM_ROT_SHIFT,
                 g_Camera.target_elevation);
         } else if (g_Input.right) {
             M_PhotoModeRotate(
-                g_Camera.target_angle + CAM_ROT_SHIFT,
+                g_Camera.target_angle + (int16_t)CAM_ROT_SHIFT,
                 g_Camera.target_elevation);
         }
     }

[rr-]

@lahm86 @aredfan with Lahm's help I've established that this bug only occurs on Windows, whereas on Linux it worked fine. I've fixed this, and additionally I've refactored the photo mode code a bit in preparation for adding this feature to TR2:

• Given the substantial code size and numerous state variables for the photo mode, camera.c was divided into camera/common.c and camera/photo_mode.c.
• Dependence on m_PhotoMode was removed, opting instead to enter and exit the photo mode via public APIs. This allows more precise state lifecycle management.
• The variable m_Roll was removed in favor of just using g_Camera.roll.
• Camera_UpdatePhotoMode was split into smaller, more readable functions.
• Shift and rotation delta getter macros were converted to plain functions.
• CAM_PHOTO_MODE was introduced, as it felt like a better fit than directly updating the camera with Camera_UpdatePhotoMode() from the phaser.
• Photo mode's management of FOV was moved from the phaser to camera/photo_mode.c, where it seems more appropriate.
• The viewport.h FOV API was simplified, eliminating the Config_Write workaround when toggling the UI in the photo mode. Each frame now knows when to use the user's or the game's FOV choice. I made sue that using a widened FOV for the Midas Hand death animation and then drawing the passport with a different FOV works as intended by introducing Output_ApplyFov(). I also made sure that the game reacts as intended to FOV changes when using the /set command.

[lahm86]

LGTM. The separation makes a lot of sense, thank you for doing this.