This movie is slight improvement over MrWint's save glitch TAS, manipulating the TID with only 10 frames of delay, instead of 17, using GBA RNG and using BIOS palettes. Run time appears slower though just because of the BIOS.
Alyosha made the initial discoveries for the GBA RNG, but canned his submission after the judge found a TID manip that took slightly less CPU cycles. I went ahead and
botted the TIDs on my own, and these were the two that ended up tieing for first:
red_pal1_gfskip0_hop5_title3_newgame0: TID = 0x64C1 (25793), Cost: 350760 Cycles
red_pal1_gfskip0_hop5_title0_newgame3: TID = 0x64C2 (25794), Cost: 350760 Cycles
The judge mentioned earlier found the 0x64C2 TID, this movie uses 0x64C1 if not just to be different. There is also another tiny "improvement," the BIOS exits 4 cycles sooner with pal instead of nopal, so a palette is set after the reset. The only other possible improvement would be to use SubGBHawk to make a sub-frame reset for save corruption, but even then SubGBHawk has a lot of issues and I couldn't get it to work correctly. (EDIT: alyosha was able to get it work, ignore what I said, this is the most optimized the movie can possibly be without a new strat.) Why couldn't we just have the 10 frame improvement and not go into a cycle war :(
ThunderAxe31: File replaced with a 35813 CPU cycles improvement (about 0.0085 seconds).
ThunderAxe31: File replaced with a 12 CPU cycles improvement... and judging.
ThunderAxe31: There are multiple aspects that should be addressed. First of all, this submission appears longer than the
movie that it's attempting to improve, due to the introduction of the BIOS. This is an emulation improvement, and thus it isn't considered as a time loss. If we disregard the duration of the BIOS sequence, the overall time of this submission end being actually shorter than the current record.
Another aspect about the BIOS that must be mentioned, is that this movie runs the game in GBC mode, as opposed of the previous movie which used the GB mode. The GBC BIOS sequence is much shorter than the GB one, however we don't count difference of loading times when comparing movies, if these are just the result of different console settings. On the other hand, if a different setting allows for the execution of new strategies that can save more time, these specific time saves will be counted. In fact, this movie exploits an intended GBC BIOS feature, the palette swap, in order to manipulate RNG better than the previous record, which allowed to save 7 frames. This is the main improvement introduced by this submission.
Now, let's move on to the nuances regarding the glitch performed for beating the game. It must be noted that a
faster setup exists for the Japanese 1.0 version of the game, however I don't consider that valid as it freezes the credits sequence right at the end. In order to be considered valid, a glitched ending must include the entirety of the credits routine, including the ability to get back to the title screen or to the save file, depending on which is the intended behavior. After that, it doesn't matter how much corrupted the save file is, or if the game is still playable at all. I also want to note that it's allowed for the video and the audio to feature corruption, though it's not the case for this submission.
Lastly, another important remark is about the validity of glitch itself. It was argued in an old forum
post that this glitch would be invalid, due to the fact that it relies on reading uninitialized SRAM data. The issue with that reasoning is that it doesn't take in account that this game features a built-in feature for wiping out the save data, which effectively turns all SRAM bytes to 0xFF, which is the exactly how the emulator used initializes it. Additionally, there are many other games which are known to give unpredictable desyncs when attempting to play back a movie on real hardware, unless the cartridge's SRAM is formatted to 0xFF bytes by using an appropriate device. There are even some games that rely on reading uninitialized bytes produced by hardware components of the Game Boy console itself, which makes it impossible to confirm a movie on real console at all, but this doesn't mean that movies made with those games should be considered invalid by default, or anything like that. So in the end, a glitch relying on how the emulator initializes SRAM data is not considered as an emulation exploit, as these bytes are intentionally initialized with an agreed standard that allows movies to be deterministically played back. A glitch is considered invalid only if it relies on an unintended emulator behavior, in other words an emulation bug, which is not the case for this submission.
Note for the publisher: the movie length displayed in the submission is incorrect, as the site's movie parser still needs to be updated for reading the CycleCount value of SubGBHawk movies. The correct timing for this submission should be 1:15.69. Also note that BizHawk 2.4.2 doesn't correctly count the cycles for SubGBHawk movies that feature hard resets, so the latest dev build should be used for that instead. I already corrected the CycleCount value for this movie, though. It should be 317452036.
