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.
With all that said, accepting this submission for obsoleting the current Pokémon Red "save glitch" publication.
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.
Spikestuff: Publishing. Time got fixed.


TiKevin83
He/Him
Ambassador, Moderator, Site Developer, Player (154)
Joined: 3/17/2018
Posts: 357
Location: Holland, MI
The RAM state assumed by BizHawk for factory defaults is the same as the state after wiping save data in gen 1 Pokemon using the normal Up+select+B on the title screen, I'm not sure how much the movie relies on that state but it verifies fine on console from wiped save data.
Memory
She/Her
Site Admin, Skilled player (1551)
Joined: 3/20/2014
Posts: 1765
Location: Dumpster
Ah ok!
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Editor, Reviewer, Skilled player (1352)
Joined: 9/12/2016
Posts: 1646
Location: Italy
Memory wrote:
Does this rely on uninitialized RAM similar to previous publications? I remember hearing that this branch actually relies on uninitialized RAM that might not be possible on a factory condition cartridge and that the only way to achieve this RAM normally would be to set the values using glitches in a separate playthrough.
From the code of most games for GB, GBA, NES, and probably other platforms, it seems that most games expect to find a 0xFF-padded SRAM as an empty memory state. In the case of Pokémon Gen I games, this is much clearly the case, as these games feature a secret input for resetting the whole SRAM data to 0xFF, as TiKevin also mentioned.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
TiKevin83
He/Him
Ambassador, Moderator, Site Developer, Player (154)
Joined: 3/17/2018
Posts: 357
Location: Holland, MI
https://youtu.be/n7l_WCIBDj0 Verified to the extent currently possible. With the hard reset not being verifiable, each hard reset was verified separately.
Player (52)
Joined: 4/1/2016
Posts: 292
Location: Cornelia Castle
Why isn't it totally verifiable?
DJ Incendration Believe in Michael Girard and every speedrunner and TASer!
Post subject: Movie published
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15527
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [4288] GB Pokémon: Red Version "save glitch" by MrWint, Alyosha & CasualPokePlayer in 01:15.69