I know games like Chrono Trigger, Pokemon Red/Blue/Yellow, and Super Metroid can be completed faster by resetting the game during saving (save corruption), but why can't this strategy be extended to other games that save information, like Zelda or Kirby games or even Super Mario 64 ("Save and Continue")?
(I've never tried using save corruption and I don't think I'd be good at it, but my question is for those who know more about it than me.)
RAM Corruption is the only glitch I can't stand at all. I have never found it interesting or entertaining.
I'm pretty sure there are people that have tried on other games, though. Usually it involves setting up a situation that the game can't deal with and saving in that messed up state.
regarding ram corruption:
I always thought that RAM Corruption (and any abuse of information that cannot be seen real-time) is one of the most revolutional idea and technique to speed running in general (and mostly for TASing). I think more than the half of the TASes abuses programming errors, while memory corruption lies between "console programmers" and "game programmers" fault. I mean, there are many modern games where it's possible to abuse the gameplay in realtime because two different company made a game with the same engine and modified it to make it suitable for themselves. I think about the infamous glitches at Half-Life (Counter-Strike also) that resulted from changing core settings and functions from the Quake 2 engine (possibility to fall down from anywhere without loosing health, jumping much further by strafing in the air because there's no airfriction, running at 45° angle while pressing W and A (it's a bit complicated) etc etc etc etc etc). Also there are games where pressing U+D or L+R could corrupt memory (just like calculating direction with U=1, D=2, L=4, R=8... developers think you will press only 2 of them at a time (max value: 10) while you could press all of them (max value: 15)).
save game corruption:
Depends on how the game handles saving the game and loading the game. Using your examples, in Pokemon Red/Blue/Yellow you can corrupt your save game that erronously changes the number of pokemons to FF (IIRC) that way you can browse a certainly serious part of an actually big memory region. You can also decrease and increase they value. It's also easy because there's no detection implemented to filter out hacked values. While other games (IIRC Zelda) only store a very minimal things or not-so crucial datas that doesn't changes that huge like in other glitchy games. Also notice that in theory, the reset button is applicable at any low-level instruction, while the Pokémon Yellow current run only presses at a specific frame. This raises the question that is it possible to improve current TASes by editing the most precise time of resetting (and it's already proven at one of the Chrono Trigger game).
The first thing you should check is the actual code of the saving and loading functions. There's 3 type of saving/loading that I investigated through a hundred games:
- Saving the actual progress
This simply stores the value of current map/position, statistics (calculated or base values), random seed (if there's any) and some items (example (not the best): SNES Super Mario World).
Next time the game loads this, it's most likely to act as the developers thought. Also this kind of saving is automatic at most games.
- Saving current game state
The difference between this and the 1st type is the storing of possibly glitched/corrupted values (example (still not the best): DS Castlevania series).
Next time the game loads this, it's possible to load your custom values.
- Saving both (actual progress and game state)
Storing nearly everything, history and present. Games like this sometimes renders glitches to be inactive due to correct loading mechanic. Just like forcing levels of synergies to have the least ammount to get to the next level (I'm talking about PC Diablo 2).
I'm pretty sure there are TASes where this type of corruption could be useful or at least improve current runs.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Wow, so much hate! Memory corruption has led to many of my favorite runs on this site (Pokemon Yellow, Mario Land 2..) and I'm all for it. It also (usually? I think?) has the convenient property of being pretty cleanly separable from a non-corrupted run, so there is room for two goals where desired.
I'm intrigued by MESHUGGAH's point about the reset button not being a frame-aligned input. Is any work being done to emulate this? It's hard to even imagine how you would specify which instruction you want to trap from, and movie file formats would certainly have to change...
A warb degombs the brangy. Your gitch zanks and leils the warb.
It's hard to even imagine how you would specify which instruction you want to trap from, and movie file formats would certainly have to change...
From the movie file format point of view, I think the only modification that is needed is that an additional value is stored alongside the reset command: The amount of clock cycles (from the start of that frame) after which the reset signal is issued. (Since emulation is always 100% deterministic, even if in the real console it might not be, this should be completely unambiguous.)
This raises an interesting technical question: Since most, of not all, CPU opcodes take more than one clock cycle to execute (especially with older CPUs, such as those used in the 80's and early 90's), what happens if the reset signal is sent while an opcode is being interpreted by the CPU? Does the CPU immediately drop whatever it was doing and jump to the signal handler, or does it wait for the instruction to be completed before doing so? (Would that even make a difference in practice?)
This raises an interesting technical question: Since most, of not all, CPU opcodes take more than one clock cycle to execute (especially with older CPUs, such as those used in the 80's and early 90's), what happens if the reset signal is sent while an opcode is being interpreted by the CPU? Does the CPU immediately drop whatever it was doing and jump to the signal handler, or does it wait for the instruction to be completed before doing so? (Would that even make a difference in practice?)
Required reading:
http://en.wikipedia.org/wiki/Interrupt
The answer most likely depends on each individual CPU, as each one is going to handle its reset interrupt differently.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
This raises an interesting technical question: Since most, of not all, CPU opcodes take more than one clock cycle to execute (especially with older CPUs, such as those used in the 80's and early 90's), what happens if the reset signal is sent while an opcode is being interpreted by the CPU? Does the CPU immediately drop whatever it was doing and jump to the signal handler, or does it wait for the instruction to be completed before doing so? (Would that even make a difference in practice?)
Required reading:
http://en.wikipedia.org/wiki/Interrupt
The answer most likely depends on each individual CPU, as each one is going to handle its reset interrupt differently.
I love your posts cause I always learn the correct specific technical expression of various things like the word "schematic".
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
I lean on the side of opinion where save/RAM corruption due to mid-write resets is a bad technique. I would put crooking the cartridge in the same category.
In years past, when I played Super Mario Bros 3. on my NTDec, I sometimes crooked the cartridge a bit because this inhibited the CPU's access to some memory lanes of the cart, altering the graphical appearance of the game, and in particular, making secrets visible.
I would not like to see such thing, or a derivation thereof, in a TAS, just like I am not particularly interested of the save-damaging runs.
However, I do approve runs that damage saves or the RAM through game's _own_ glitches, such as the painting glitch of Relm in Final Fantasy VI.
Joined: 6/5/2006
Posts: 188
Location: Malmö, Sweden
I quite like the save corruption runs. It usually results in a pretty bizarre and (hopefully) short experience. And as mentioned, it's not that hard to separate runs using corruption from runs that don't.
Even the best player is limited by the speed of his fingers, or his mind's ability to control them. But what happens when speed is not a factor, when theory becomes reality?
Well, save corruption can still result in very interesting videos. Of course, playing through the game without abusing it is also entertaining (possibly). I don't see why save corruption is so hated. It makes short and interesting videos, and doesn't waste much time on the author's part, by default. Considering it as a different category would be for the best.
Now, I'm still curious as to how the corruption actually happens. Is there no place that explains exactly how games save which data at which moment, and how reseting at that time will mess the rest, and such?
I'm Espyo from the SRB2 Forums.
Current project: A Pikmin fan engine, Pikifen
In years past, when I played Super Mario Bros 3. on my NTDec, I sometimes crooked the cartridge a bit because this inhibited the CPU's access to some memory lanes of the cart, altering the graphical appearance of the game, and in particular, making secrets visible.
It wouldn't be affecting the CPU, otherwise you'd simply get a crash. The PPU has its own pins connecting to the graphics memory. For a game like SMB3, at the worst, you'd lose the status bar, but nothing else would affect the CPU side.
This has been discussed to death, so it's probably not a good idea to go over it again. But in summary, in my personal view, it's not so much about the save data corruption, but about how it's achieved, namely by interrupting the game with the reset button. (The question is whether resetting the console in the middle of saving can be considered legitimate input to the game or whether it's hardware abuse. In most consoles the game cannot disable or hook to the reset button, while in a few games resetting is actually used as a gameplay gimmick, although probably even those games don't survive a random reset unscathed, and are only able to manage it properly if you reset when the game expects it.)
Out of curiosity, Warp, how do you feel about L+R? Isn't that also not 'legitimate input to the game'?
Does pressing L+R send a hardware signal to the CPU that interrupts the game in the middle of doing things, without the game being able to disable, control or hook to it?
Reset legitimacy itself was widely discussed here and I see no need in repeating the same stuff here as well.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Yes, I suspected that this topic had been discussed in the past. But... what was the consensus? If no agreement was ever reached, maybe we'd need to figure this through again? I wasn't present for the original discussion, but I imagine it must've been hellish. Repeating it would be harsh, but sorta necessary...
In fact, as of now, what does happen when someone submits a run that uses save corruption? Do the judges just take the game and other factors into count, is another debate brought up, are they refused on sight, ...?
I'm Espyo from the SRB2 Forums.
Current project: A Pikmin fan engine, Pikifen
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
We should always continue to accept videos that use mid-write resets; just accept other runs that don't use them, too. TASVideos in general has a tendency to obsolete videos when it's not really necessary (such as obsoleting the 4 hour Chrono Trigger run in favor of the 26 minute glitched one--no reason why those can't coexist).
