Timing and loads
6 years ago
United States

The following 3 versions were analyzed via FCEUX 2.2.3:

NTSC-U PRG0 NTSC-U PRG1 (alternatively, "Revision A") NTSC-J

For reference, the NES NTSC framerate = 60.098813897441

In all 3 versions, the first frame of input to the character select screen appearing takes exactly 12 frames, or roughly 0.19967 seconds. With that said, if you record your runs at 60 FPS then feel free to find the first frame in which the "Please Select Player" screen appears, and then subtract frames accordingly. Lower framerates should be avoided if possible (for example, if you record at 30 FPS then there's a chance the first frame of character select would have been the second frame at 60 FPS, thus subtracting the amount of time detailed above results in a frame erroneously saved).

PRG1 and NTSC-J have slower loads between stages involving either doors or eagle heads. Exactly 1 frame is lost compared to PRG0 in each of these instances. Eagle heads that lead to different rooms within stages have no difference (e.g. 1-3 eagle head to Mouser), and the same is true for doors. No differences seem to exist for warp vases.

For end timing, I suggest we simply use the first frame the screen turns solid blue upon entering the final door.

Images for reference: https://imgur.com/a/t2nsc

Edited by the author 6 years ago
France

As a complement to this, to try and explain with as few words as possible what the impact of a VOD is (whether you record at 30 fps flat, 60 fps flat or anything that isn't exactly the NES framerate (which nobody records at really)):

_ At the start of the run, you can potentially "gain" up to 1 frame (VOD speed frame, not NES frame) compared to the actual run (it's actually infinitely close to 1 frame and not 1 frame but let's say 1 frame for simplification). This is because the VOD frames and the "real" frames are not synced. (So the VOD will show the 1st frame slightly after it actually happened, and the difference varies up to 1 frame).

_ At the end of the run, you can potentially "lose" up to 1 frame (VOD speed frame, not NES frame) compared to the actual run.

So concretely, if you framecount a run using frame values based on the actual NES values (like the 12 frames mentioned by bjw in his post), your final time is gonna be off by a value anywhere from -1 frame to +1 frame (the start and end are unrelated to each other due to NES & VOD frames not being synced so the time gained/lost doesn't necessarily cancel itself).

Keep in mind this is VOD frames we're talking about here. So if you record at 30 fps, you can save artificially up to 2 frames (60 fps frames) and you can lose artificially up to 2 frames (60 fps frames). If you record at 60 fps, you can save up to 1 and lose up to 1.

It's both a good approximation and kinda problematic because you can possibly overestimate your run and mark it as faster than it is (although by a very small margin).

A possible solution is to add 1 VOD frame to the start when looking for the actual start. Like if you recorded at 60 fps, instead of using a 12 frames value for the start, you use 13 frames. At 30 fps, instead of 6 frames, you go back 7 frames.

With that solution, you can never mark your run as faster than it is, but you can artificially lose up to 2 VOD frames (so if you record at 30 fps, you can lose up to 4 NES frames roughly).

All in all it's generally a very bad idea to record at 30 fps because framecounting gives way bigger approximations obviously. 60 fps flat recordings give a pretty good result, whether you use the -1/+1 range or the 0/+2 one.

Edited by the author 6 years ago
South Carolina, USA

I like the idea

I record my runs using amarec and lossless using a diamond vc500 cap card. So I can easily use your method to come up with a close enough time.

The difficult part is trying to get an accurate time on ilm's run, as the only video is a 60fps twitch highlight.