Repository navigation
Segment timer is way off at full-run length #293
Description
Cutie's splice has a 38:20 real time with a 36:46 segment timer https://youtu.be/xAlAYaMdW3M&t=2322
My theory TAS has a 32:23 real time with a 32:26 segment timer https://youtu.be/XirjdGQS2Ig&t=1961
Something is broken in the master branch. There are two hijacks in early game that add time to the segment timer to account for frames where NMI was disabled. They probably amount to about this much difference.
Activity
idlechild commentedon Sep 13, 2026
First let's correct for the timer setting. Cutie used standard room timing (likely to compare with personal best room times) and collected 19 items, so add 19 x 328 frames = 6232 frames + 36:46 = 38:29.52f segment timer, vs real time 38:20.540ms
That is still incorrect compared to IFB's theory TAS of 32:26 segment timer, which when divided by 60.09 gives 32:23 real time. I wouldn't consider it "way off" for a speed run over a half hour long, but I suspect we are scamming runners by adding one frame either in each room time or in each door transition. I don't know how many rooms/door transitions there are but I think it's in the ballpark of the error. I am biased by "frame-counting" one Ceres room where room time showed 2.12 but I counted 131 comma button presses... there are so many problems with that (trusting youtube to next-frame, trusting youtube again to have a properly encoded video, trusting my own ability to count to 131, the fact I only did this once in one room, etc.) I suspect there is a discrepancy though based on segment time 38:29 (almost 38:30) vs real time 38:20; those final times do not match up. Also times are not that far apart after Samus lands on Zebes so it's not all in those opening cutscenes; the discrepancy has to be happening elsewhere.
idlechild commentedon Sep 13, 2026
Just to be clear, my focus is on whether or not the practice hack counts time correctly in normal circumstances. I don't care whether or not the prac hack timer or splice timer in Cutie's video (or Firebat's video for that matter) is 100.00% accurate; I think that's missing the forest for the trees. The goal is to showcase optimal strats and the timer is just there to supplement, and in fact as long as the timer is relatively accurate it will still do an effective job at demonstrating the power of various strats. In this context, ~6 seconds over the course of a half-hour showcase is a nothing burger of an issue.
Okay, first let's address an oversight I made in my previous post. I mentioned Cutie used standard room timing, but I neglected that the fanfares are being played. The prac hack is not supposed to give standard room timing when playing the fanfare music, and it doesn't. I thought we had a previous issue for this but I've checked the changelog and commit history and I can't find anything recent regarding timing being incorrect when fanfare music is present. Perhaps Cutie also spliced the fanfares in? Perhaps Cutie had some version of the prac hack with a bug on fanfare timing? I don't care what the cause of that issue was either. It's not the source of the final time discrepancy. I checked a time in the middle of the run (entering metal pirates) where most items had already been collected, and the discrepancy was ~3 seconds there, so that lines up with my theory of a consistent discrepancy over the course of the run rather than it all happening in one place or only during fanfares.
For testing the prac hack timing, I turned to a TAS I already made. It's much shorter than Cutie's or Firebat's video, but I can play it back with BizHawk and BSNESv115+. I checked several room and door transition timings, including an elevator ride and room with a power bomb for some lag. All time measurements were accurate. If BizHawk said 400 frames elapsed in a room, that's what the room timer and segment timer reflected, and same for the segment timer during door transitions.
Does this mean the prac hack counts time accurately in all cases? Not necessarily. For example my TAS didn't have an item pickup. However it does give me confidence that room-to-room and door-to-door times are functioning. I'm not saying the splice is wrong either; I haven't proven that (and also as noted above, I don't think it's wrong even if it's wrong!) I am saying I don't have enough to proceed further; the TAS testing I have done has restored my confidence in at least the current release of the prac hack. Now I can look forward to watching the BTTB reaction to the splice :)
idlechild commentedon Sep 14, 2026
After typing all this up, I realized I didn't test saving or loading state in the prac hack with the TAS and that might be important. In some preliminary testing, I'm noticing saving state may be creating a lag frame. BizHawk shows saving state creates several lag frames but I would expect none of them to count. However I'm seeing the lag frame count, room timer, and segment timer all increment by one. If either saving or loading creates a lag frame that gets counted, that could explain the timing discrepancy.
I won't be able to dig more into this until later tonight, but not ready to close this issue just yet.
idlechild commentedon Sep 14, 2026
Okay... looking at Cutie's splice, there's no way there should be a lag frame in this room, correct? (coming up from morph to enter pit room). This looks like an issue with the prac hack.
Just messing around in this room, if I save during the fade in, I can reload and not get a lag frame, which makes sense. However if I save after the room fades in and room time starts counting, sometimes I'll get this lag frame and then every time I load and exit the room, the lag counter is 1. In fact it seems every time I save, the next time I load the lag counter increases.
InsaneFirebat commentedon Sep 14, 2026
I created the issue so I'd remember to look into it later since I've been occupying my assembly time with the disassembly. I agree that a few seconds over the course of the run is insignificant, and I already knew that was happening. Being off by over a minute was the only concern.
I hadn't really put much thought into it yet. The two cutscene adjustments were just the first things that came to mind. Fanfares and savestates are good leads. I'll ask Cutie what settings they used. My theory TAS uses music/fanfares on and savestates exclusively with the emulator.
InsaneFirebat commentedon Sep 14, 2026
Cutie confirmed that fanfares were off, and the timer wasn't being corrected. That's a good enough explanation for me, you can close it when you're satisfied.
jnkel commentedon Sep 14, 2026
Zeni and Drewski mentioned to me this weekend that saving and loading state during an elevator ride causes the room timer to be one frame off.