TASVideos

Tool-assisted game movies
When human skills are just not enough

Submission #6907: MrWint, Alyosha & CasualPokePlayer's GBC Pokémon: Red Version "save glitch" in 01:15.62

Console: Game Boy Color
Game name: Pokémon: Red Version
Game version: USA/Europe
ROM filename: pokered.gbc
Branch: save glitch
Emulator: Bizhawk 2.5.1
Movie length: 01:15.62
FrameCount: 4520
Re-record count: 818
Author's real name: Christian Koch, David M & Wesley B.
Author's nickname: MrWint, Alyosha & CasualPokePlayer
Submitter: CasualPokePlayer
Submitted at: 2020-10-11 10:20:05
Text last edited at: 2020-10-11 18:45:24
Text last edited by: CasualPokePlayer
Download: Download (2506 bytes)
Status: judging underway
Submission instructions
Discuss this submission (also rating / voting)
List all submissions by this submitter
List pages on this site that refer to this submission
View submission text history
Back to the submission list
Author's comments and explanations:

(Link to video)

So after making my Silver collision movie, I ended up thinking of an idea I had some time ago: can the Red Any% TAS be improved with checksum collision?

Turns out, yes it can. By 4 frames.

There are some technical points I need to clarify with this though. For one, there's quite a bit of data I need to save so the game doesn't end up softlocking when the the save file is loaded. And past that, there's other data I would want to save, like the Pokedex flag (so 4 frames isn't lost due to having the Pokedex), and surprisingly, sprite data. It so happens the game will save sprite data around the end of the save routine, and one of the IDs for the sprites happens to cause around 7 frames of lag (when all are FF anyways). Once all that is accounted for, I then have to figure out how to collide the checksums. Turns out Gen 1's checksum system is even worse than Gen 2's. While Gen 2 was just the sum of all the bytes stored in 2 bytes, Gen 1 instead just uses the complement of the sum of all the bytes... stored in 1 byte. And since all of SRAM is filled with FFs and most of the data being written in there is 00s, it really just becomes a simple game of math to figure out which byte you want to reset in.

Also, I ended up using 0x64C2 instead of 0x64C1 for the TID in this TAS, as the higher byte lets me reset 1 byte/52 cycles earlier. To note, manipulating for 0x64C6 takes 740 more cycles, and it would only save on 4 bytes being written/208 cycles, so it isn't worth it to manipulate that TID.

Unrelated to collision, another minor improvement I found was that taking the 1 step down before the save/quit happens to be 55 cycles faster. Who knew?

EDIT: Ok the 1 step down was actually somewhat relevant to collision, although it happens that collision with the old 1 step down after s/q would lose an additional 64906 cycles, past the inherit cycle loss anyways.


ThunderAxe31: Judging.


Similar submissions (by title and categories where applicable):