TestRunnerSRL
Bugfix for the Credits Timing issue from v1.0/v1.1 (fixed in v1.2)
I stumbled upon an issue that I haven't seen documented anywhere regarding version differences for Ocarina of Time, which I'd like to suggest as a bugfix for subsequent versions of the Randomizer.
Upon defeating Ganon in the final battle, you go through the usual Zelda sending you back cutscene, and then the landscape scenes for the credits.
However, when you reach the cutscene that changes songs, the one with the coloured flames and all the NPCs celebrating at Lon Lon Ranch, the music and the visuals start to desync from each other.
I've added an entry in TCRF about this issue: https://tcrf.net/The_Legend_of_Zelda:_Ocarina_of_Time/Program_Revision_Differences#Ending_Sync_fix
From my research, I found out that both v1.0 and v1.1 have the same problem, and said issue seems to have been fixed on v1.2 and onwards.
Here are some videos for comparison:
v1.0/v1.1 Ending Desync bug (Malon's vocals don't start until some seconds afterwards): https://youtu.be/YWHgACbvr6I?t=9442
v1.2 Ending fixed (Malon's vocals start as soon as she appears in-frame): https://youtu.be/osPKBBiYeio?t=1475
I usually use Malon's vocals as a point of reference to know if the track is in-sync with the visuals or not. If the vocals channel doesn't enter at the same time as Malon on-screen, then the track is desynced. This causes the track to be cut-off at the end of said sequence (before switching to Young Link in the Temple of Time).
My suggestion goes for a possible bugfix for this issue, as it'd be interesting to see what the root-cause of this issue is, and how it could be solved.
~~Are you able to provide a video of 1.0 on N64?~~ The 1.2 one is actually on N64 hardware. It might just be an emulation issue.
Let me get a recording myself real quick.
Hmm, in rando on hardware it's a little bit delayed, but not nearly as much as your example, so I'd have to assume a combination. I'll upload the video soon.
yeah Id be very suprised if this was an actual version difference. Definitely wouldnt go around adding tcrf entries and stuff for something tested on emualtor
~~Fair point. Can someone who has a legit v1.0 cartridge, or someone who can test the vanilla v1.0 ROM on console, verify this, please?~~
~~If it ends up being emu specific I will remove the TCRF entry asap.~~ (TCRF entry has been removed)
Sorry to bump this issue. User @ZombieBrainySnack contacted me about helping to test the issue at hand. The user holds a legit v1.0 cart of OoT, and was kind enough to record the credits section of v1.0, where the troublesome sync issue comes in in flashcart and emulators.
Here's the video: https://youtu.be/kYAe9UAajus
So, as you can see, the issue is not there in real hardware with a legit cart, but what I find weird is that the desync issue is present with a Rando ROM when played through a flashcart on original hardware, and even through emulators like Mupen64 Plus Next.
I am still not sure if the issue boils down to either Rando code itself, or if it's emulator. Though if it happens even on real hardware, I'm inclined to believe it might have something to do with Randomizer directly.
You're not going to believe this. If you give the bunny hood to the marathon man, he's running around kicking up dust clouds. Drawing the bunny hood and dust particles causes enough lag to cause timing differences. Tested using decomp on a SummerCart64 to test PAL 1.1 vs NTSC 1.2 timings:
NTSC play normally: Incorrect Timing (late)
NTSC play normally + ITEMGETINF_3B set: Correct Timing
NTSC load credits from debug menu: Correct Timing
NTSC load credits from debug menu + ITEMGETINF_3B set: Correct Timing
PAL play normally: Correct Timing
PAL play normally + ITEMGETINF_3B set: Correct Timing
PAL load credits from debug menu: Correct Timing
PAL load credits from debug menu + ITEMGETINF_3B set: Incorrect Timing (early (barely))
Loading this cutscene from the debug menu doesn't disable sound effects, so those seem to cause additional lag which just barely makes the PAL timing just a bit early with ITEMGETINF_3B also set. That probably means there is a way to re-time the NTSC scenes to last a little longer so that ITEMGETINF_3B doesn't cause such a noticeable difference.
Note: The amount of text on screen at any one time can be different between NTSC and PAL which also contributes to how much lag occurs.
Delaying gLonLonRanchCreditsPart2Cs.csdata.inc.c's CS_DESTINATION command by 15 frames seems to give a decent compromise IMO.