Super Mario Bros. Deluxe is a 1999 remake of the classic NES title, released for the Game Boy Color. This movie aims to complete the game as fast as possible, using warps to skip sections of the game. This movie is a 4 frame improvement over the previous publication; 1 frame was saved in 1-1, 1 was saved in 4-2, and 2 were saved in 8-4.
Emulation Details:
Emulator: BizHawk 2.10
Core: Gambatte
BIOS: Official Nintendo BootROM
ROM Checksum: 94466f48d8b4f811608ce8641de5f82315cd60b5
Level-by-Level Breakdown:
1-1:
1 frame was saved here thanks to a discovery made by Shot313 a few months ago; a frame can be saved when entering vertical pipes if you have a good y-subpixel.
4-2:
Another frame was saved entering the World 8 pipe in the warpzone due to another better y-subpixel.
8-4:
Two frames were saved due to better pipe entries in the first room and third room.
There are 2 other vertical pipes in this movie (the World 4 pipe and the walljump room pipe), however a frame cannot be saved on them because the World 4 warp pipe requires Mario to land on the edge of the pipe to enter them optimally (A good y-subpixel can only be achieved if Mario doesn't land on the edge of the pipe before he enters it), and the walljump pipe doesn’t work with any jump height from the walljump (I tested them all.)
Special Thanks
Thanks to Shot313 for discovering the new timesave, this TAS wouldn't have been possible without you! -King Kappa
I’d like to clarify something really quick. When I say “a discovery made by Shot313 a few months ago” in the submission page, I am referring to Shot313’s previous submission. He did find a single frame save in 4-2 (due to the better y-subpixel), that submission does in fact touch the axe in 8-4 a frame earlier than the current publication. I think some confusion arose as to whether his TAS was identical or slower because A. He ended inputs on the axe instead of ending them as soon as possible and B. The way this game’s publications are encoded causes all transitions to appear shorter than they actually are when played back in BizHawk, which led to the current publication appearing shorter in the comparison linked in that submission’s discussion thread.
I also noticed something really weird with the submission framerate. It isn't the GBC's native 59.7275 FPS, but instead it is 59.8897 FPS. Just something kinda odd I wanted to point out.
It isn't the GBC's native 59.7275 FPS, but instead it is 59.8897 FPS.
I think the submission is timed that way because LCD-off frames bring up the average framerate. As explained here:
CasualPokePlayer wrote:
The Game Boy effectively has a variable framerate. The ~59.7275 FPS only applies while the LCD is on. The game can turn the LCD off, at which point, there is no concept of "framerate" anymore. Gambatte by default runs for 35112 samples (i.e. the amount of audio in a nominal 59.7275 FPS frame) or when VBlank occurs, whichever comes first. As such, you will generally end up getting a frame much shorter than expected when the LCD is switched from off to on. If you were to say remove all the "short" frames, you would return back to an actual ~59.7275 FPS.
Since the frame count alone can't encompass these variable-length GBx frames, the site parser seems to also read the CycleCount included in the .bk2. This is then output as a custom framerate for that particular submission. So two TASes of the same game may have different calculated FPS, at least where LCD-off frames are present.
CasualPokePlayer wrote:
BizHawk will encode a CFR video file, which uses the nominal framerate reported by the core (which case is ~59.7275 FPS).
...
BizHawk will attempt to keep video and audio in sync by either sacrificing video or audio. With "Sync To Audio", video is sacrificed, skipping or duping frames when needed. If you uncheck Sync To Audio, you will instead have audio sacrificed, leading to various pitch issues throughout the video. Audio issues are much more noticable than a few video frames being skipped/duped occasionally, hence why Sync To Audio is the default.
In practice too, this doesn't actually affect GB encoding, since the few frames which get duped would be identical to the ""correct"" frame anyways, leading to no actual sacrifice of video output.
I'm not sure if the final paragraph here addresses your earlier post about encode times. If you're counting transition frames in BizHawk and dividing by 59.7275 then the time may be off compared to what the video dump shows. Of course, someone can correct me if any of this is wrong.
