Again, I fail to understand. You're telling me that the developers never expected for players, playing their games, to ever push the reset button, or shut off their machines? The very idea of having saves argues otherwise.
Yeah, sure, that's exactly what I'm saying: All developers expected players to keep their game running 24/7, without ever turning off the console or changing to another game.
*sigh*
I don't even understand where you are getting that. It sounds like a straw man.
The reset button is not input to the game. Games cannot hook to the reset button. Pressing the reset button is not part of gameplay for that very reason. There's little difference between pressing the reset button and unplugging the power cord. And since we are abusing the hardware, what difference is there between unplugging the power cord in the middle of a game and eg. stabbing the console with a screwdriver? Both could equally cause eg. saved data to become corrupted. Not because of anything you did in the game, not because of exploiting any programming error in the game, but because of abusing the hardware.
There is a clear difference. If you can't see it, then I don't know how better to explain it.
Please forgive my awkward manner of discussing this but I am having trouble understanding what manner of policy you intend to promote. It rather sounds like you have been arguing that all uses of the reset button are illegitimate and I am curious to know from what premise you are coming from. If that's not what you're saying, then I apologize.
Now, you've conceded that developers intend for players to, at some point, reset or shut off their consoles. And yet, for whatever reason you seem to be arguing that this fairly routine operation is the equivalent of smashing the console with a hammer. I really hope you can see why this is a stumbling block for me. Please, do try to fine-tune your arguments so that I can better understand them; its rather difficult trying to hold a productive discussion without a well defined premise.
As I see it, gaming is something that happen when a ROM image interacts with a console's hardware and the player input processed by that hardware. Developers expect players to manipulate a control pad and they expect them to, at some point, reset or turn off their machines. The software for games with save date are programmed with the expectation that the player will save, turn off their machines, turn them back on sometime later and load the save data so that the game may continue. I cannot under any circumstance see why this routine action would qualify as "hardware abuse" equivalent to piercing the console with a screwdriver.
Furthermore, there is a significant difference between pressing the reset button (a soft reset) and shutting the power off and on (a hard reset); game data such as high scores may be carried over in the first case where they would be erased in the second. Ripping out the power supply probably would result in something like a hard reset unless it damaged the console or cart (Which would obviously be a disqualifying "modification"). Both reset and power buttons are an intended feature of the console designed to be used in conjunction with normal gameplay and which all developers must anticipate while programming their games. Throwing the console against a wall during gameplay is not an intended design feature; if anything, consoles are designed to resist damage, ie. modification. I'm no electrician, but if I might hazard a guess I'd suggest that for treating the console to any form of violence to have an effect on how the software is processed it would have to produce a temporary or permanent modification to the system or cart. The power and reset buttons do not modify the console because they are an intended feature installed with the universal expectation that a player will use them at some point while running the software.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Warp wrote:
The reset button is not input to the game. Games cannot hook to the reset button. Pressing the reset button is not part of gameplay for that very reason. There's little difference between pressing the reset button and unplugging the power cord. And since we are abusing the hardware, what difference is there between unplugging the power cord in the middle of a game and eg. stabbing the console with a screwdriver? Both could equally cause eg. saved data to become corrupted. Not because of anything you did in the game, not because of exploiting any programming error in the game, but because of abusing the hardware.
I think there's a very important point you're missing.
Games can't tell if you shut off the power in the middle what they were doing the last time you were playing them.
On the other hand, if you reset in the middle, they are able to detect that the game has begun from reset, and have a copy of whatever was in RAM prior to the reset. Using that, they could set the game to act like nothing has happened. They don't. We exploit that.
Edit:
Let me elaborate on that - most don't. We aim to exploit those where the programmers didn't care, or did a bad job.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
It rather sounds like you have been arguing that all uses of the reset button are illegitimate and I am curious to know from what premise you are coming from. If that's not what you're saying, then I apologize.
No, I'm arguing that corrupting the save data of the game by interfering with the hardware (rather than the game itself) is, in my opinion, dubious. The problem is that since this is happening outside the game's own code and logic, via an action which is not part of the game execution, it constitutes, in my opinion, altering the game data via (in this case emulated) hardware abuse.
I'm not arguing that having a reset button command in the emulator movie file should be forbidden. I'm saying that corrupting the save data via a reset is akin to corrupting the game code or its data by other means (which is forbidden by the site rules).
What is the difference between game data corruption using the reset button, and game data corruption via gameshark or gamegenie? They can be both done in the real console and in the emulator. An emulator could conceivably save these gamegenie codes in their movie file (if they don't already). Yet using gamegenie codes is forbidden because it's considered cheating.
So I ask: Why is altering the game data using an (emulated) gamegenie considered cheating, but altering the game data by abusing the reset button is not? What is the major difference? Personally I don't consider "a gamegenie device didn't come by default with consoles" a good-enough reason. (I wouldn't be surprised if there were pirate consoles with gamegenie devices built in.)
What's worse: Cheat codes supported by the game itself are generally forbidden by the site rules. Here we aren't even talking about hardware abuse or even data corruption. Just regular and normal gamepad keypresses. So why are cheat codes prohibited, but corrupting the game's data (ostensibly with similar results) allowed? What's the difference?
Now, you've conceded that developers intend for players to, at some point, reset or shut off their consoles. And yet, for whatever reason you seem to be arguing that this fairly routine operation is the equivalent of smashing the console with a hammer.
Nope. I don't consider pressing the reset button akin to smashing the console. I consider corrupting the game data with the reset button akin go corrupting it by smashing the console. There's a difference.
If some game requires a reset as part of normal gameplay as some kind of gimmick, that's fine. But that's completely different from actually corrupting the game data via a reset. You are not corrupting it by playing. You are corrupting it by telling the emulator to corrupt it. Again, I see little difference to a gamegenie.
Furthermore, there is a significant difference between pressing the reset button (a soft reset) and shutting the power off and on (a hard reset)
If corrupting the game by resetting is allowed, why shouldn't corrupting the game by shutting down the console be allowed? What's the difference?
And consequently: What other hardware abuse should be allowed? What's the defining limit when something becomes prohibited? "You must be able to do it with the real console" is clearly not such a limit. You can smash the console and in theory something funny might happen to the game.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Warp wrote:
If corrupting the game by resetting is allowed, why shouldn't corrupting the game by shutting down the console be allowed? What's the difference?
I don't think there is too much of a difference there.
But regardless, I'd allow both.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
If corrupting the game by resetting is allowed, why shouldn't corrupting the game by shutting down the console be allowed? What's the difference?
I don't think there is too much of a difference there.
But regardless, I'd allow both.
Btw, I'm honestly interested in knowing your (plural) opinion about the question I posted above: Why is using cheat codes supported by the game itself forbidden, but corrupting the game's save data via a reset allowed, even though they both could ostensibly give similar results? If you think about it, there's little practical difference between the two, IMO.
Just as a practical example: If a game had a cheat code which gives you 99 items, it would probably be forbidden to use it. But if you could get the same 99 items via save data corruption, it would be allowed. But why?
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Warp wrote:
Nach wrote:
Warp wrote:
If corrupting the game by resetting is allowed, why shouldn't corrupting the game by shutting down the console be allowed? What's the difference?
I don't think there is too much of a difference there.
But regardless, I'd allow both.
Btw, I'm honestly interested in knowing your (plural) opinion about the question I posted above: Why is using cheat codes supported by the game itself forbidden, but corrupting the game's save data via a reset allowed, even though they both could ostensibly give similar results? If you think about it, there's little practical difference between the two, IMO.
I remember us having some published movies which used a couple of cheat codes.
But the point with TASing is that we try to show playing the games as being as awesome as possible.
Think of the following motto: "We don't need no stinkin` cheat codes". We try to show our playthoughs as better than the average person. Cheat codes detracts from that.
Part of us destroying the game is exploiting flaws to proceed through the game faster, as well as just exploiting it for the sake of it to show how amazing we are.
For example, in SMB2, in 4-1, we throw that cloud guy near the end literally into the wall, not because it saves time, but because we can, and it shouldn't be allowed.
Warp wrote:
Just as a practical example: If a game had a cheat code which gives you 99 items, it would probably be forbidden to use it. But if you could get the same 99 items via save data corruption, it would be allowed. But why?
Because the former anyone can do. The latter can only be done by TASing.
However we reject TASs that are boring. If you have cheat code to skip to the last boss or a save corruption to skip straight to the last boss, and it's just a bore, neither of them would be published.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Think of the following motto: "We don't need no stinkin` cheat codes". We try to show our playthoughs as better than the average person. Cheat codes detracts from that.
I perfectly understand why cheat codes are not allowed, and fully agree with that. However, I was not asking that: I was asking that since using cheat codes is forbidden (for good reasons), why isn't save data corruption, which ostensibly achieves the same thing as cheat codes?
But thinking about it, I think I can answer that question myself: Because save data corruption is more akin to bug abuse (which is allowed) than to using cheat codes. Certainly if abusing some bug (which doesn't involve the reset button) allowed you to get the 99 items, it would be allowed (unless it makes the run outright boring, of course, but the point is that it's not forbidden by the basic rules).
Ok, I concede that point. I'm still a bit uncomfortable with the means by which this "bug abuse" is performed, though (ie. because I consider it hardware abuse).
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Yes, correct. I also agree this method of bug abuse can be a bit unsettling.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
As a relative layperson, I find save-game glitches rather awesome and impressive.
If there were a simple push-button cheat to skip to the final cutscene of the RPG that I already knew of, watching it being done frame-perfectly wouldn't impress me at all.
Ultimately, these runs are meant to be entertainment and I think that's the main reason to disallow most cheats - they generally reduce the entertainment potential.
I'm just some random guy. Don't let my words get you riled - I have my opinions but they're only mine.
Btw, I'm honestly interested in knowing your (plural) opinion
Would you generally forbid resetting the game to save warp?
I'm assuming that no, you wouldn't.
So resetting after saving is fine, right?
By resetting during saving, you can't modify the data to your own will. It's still the game that modifies the data. You just tell it to stop in the process of it. By neither using an external device, nor by modifying the console. You are merely pressing a button.
The game code does not react to that button, the hardware does, so yes, you have a point. There is a difference. That's why there are distinct categories for these runs.
But is it different from save warping? Why would pressing the reset button be regarded as any different just because it happens during the process of saving?
Also, consider this: When booting up again, the game reads data that has only been modified by its own code. You've just told it when to stop. It would have the means of checking if it has loading valid data, but most games don't use check sums to do this. So isn't it an intentional oversight? Similar to pressing left+right? "Well, hardly anyone will ever do that, so let's not care about what happens if they do." That fits the definition of a glitch, doesn't it?
So imo, save file corruption is basically just severe glitching that is impossible to follow without any kind of debugging tool, plus resetting the game combined. Whether resetting should be allowed is debatable. Whether severe glitching should be allowed also is. Both at once is twice the trouble. They take away entertainment in one way, but also add entertainment in another.
It is different from modifying a game's memory at will though. It is also different from modifying the hardware. But it's also different from playing through the game in normal TAS manner, so you have a point. Luckily, there already exist different categories for these types of runs though, so there's no need to worry. ;)
Would you generally forbid resetting the game to save warp?
I'm assuming that no, you wouldn't.
So resetting after saving is fine, right?
Let's say that it wouldn't bother me if resetting was not allowed at all. (It might make some runs slightly more repetitive because of the required backtracking, but hey, we didn't have recording support for resetting for years, and the runs were just fine. It's not like it's an essential feature to have.)
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Warp wrote:
we didn't have recording support for resetting for years, and the runs were just fine. It's not like it's an essential feature to have.)
Years? More like just a bit over 1. I had it as part of my initial design to update ZSNES for rerecording. I deemed it essential.
Here's when I official commited my idea for doing things in middle of a movie:
Thu Mar 31 10:31:40 +0000 2005
Here's when I added on the reset command:
Sat Apr 02 22:54:28 +0000 2005
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
If corrupting the game by resetting is allowed, why shouldn't corrupting the game by shutting down the console be allowed? What's the difference
I think both should be allowed, I just thought I'd point at that they do behave differently.
Btw, I'm honestly interested in knowing your (plural) opinion about the question I posted above: Why is using cheat codes supported by the game itself forbidden, but corrupting the game's save data via a reset allowed, even though they both could ostensibly give similar results? If you think about it, there's little practical difference between the two, IMO.
Personally, I can't imagine a lot of TASers needing to use cheat codes. What would they want 99 lives for? True, there are level select codes, but using something like that would be, by most standards, trivial and boring. Now, if such a code allowed the player to do something unique, interesting, or skillful (say, allowed them to play as a hidden character) I'd be happy to see it. Come to think of it, Inichi's Chrono Trigger run did use an in-game code to be able to load the corrupted save date in the first place...
Just as a practical example: If a game had a cheat code which gives you 99 items, it would probably be forbidden to use it. But if you could get the same 99 items via save data corruption, it would be allowed. But why?
If a save-corruption run gave itself 99 of every item, that probably would be boring. Getting 99 items of glitchy nonsense that allows you to access various memory address though, is priceless.
If corrupting the game by resetting is allowed, why shouldn't corrupting the game by shutting down the console be allowed?
This is a good question, although, I'm not sure that I agree with the use of a loaded term like "hardware abuse." In my opinion, an operation should be considered legal only so far as it can be considered use of an intentional feature of the console that a developer could reasonable anticipate a player using during normal game-play. By these standards, plugging or unplugging a gamepad or memory card from the console would be consider admissible whereas tilting the cartridge would not. Corrupting VROM data does sound like a gray area by this test, but as I see it, if both saving data and turning off power to the machine are to be considered legal operations then there should not be any restrictions on when they are used, no more than there are for left+right; that the data is corrupted is simply an unintended consequence of normal, legal actions being used to produce a creative result.
As for Game Genies, etc... To be honest, if somebody did use Game Genie codes to pull off a clever, interesting or artful TAS, I'd be happy to see it. I'm sure I've watched things like that on Youtube. All a Game Genie code really amounts to is a patch, and we do have hacks in the demo section, and I'm sure that if someone made something that everyone fell in love with it would appear in the demo section. The reason that convention prohibits such things is that we don't want a pile of incompetent amateurs submitting a slew of needlessly sharked TASs; and because the community typically expects to see TASs of unmodified games manipulated in a manner consistent with normal operation of the original console. Maybe things will change if a talented TASer approaches the task and we move beyond the era of common yokels on Youtube refering to TASs as "cheats," but even then, it will still be a categorically different way to do a TAS.
If corrupting the game by resetting is allowed, why shouldn't corrupting the game by shutting down the console be allowed? What's the difference
I think both should be allowed, I just thought I'd point at that they do behave differently.
Well, that's kind of my point: If that is also allowed, then what other forms of tampering with the hardware should be allowed as well? Where do we draw the line? How would you define what is acceptable and what isn't (and why)?
Personally, I can't imagine a lot of TASers needing to use cheat codes. What would they want 99 lives for?
For example invincibility could make some runs faster because taking-damage-as-shortcut wouldn't be limited to your life bar. In some games it may even mean that you can run straight through enemies without having to dodge or spend time killing them.
If a save-corruption run gave itself 99 of every item, that probably would be boring. Getting 99 items of glitchy nonsense that allows you to access various memory address though, is priceless.
You could achieve the same thing by tampering with the game's ROM using an (emulated) gamegenie device or whatever. Why wouldn't that be "priceless"? Why is that suddenly "cheating" and/or "boring"? What's the difference?
That's kind of my point.
As for Game Genies, etc... To be honest, if somebody did use Game Genie codes to pull off a clever, interesting or artful TAS, I'd be happy to see it. I'm sure I've watched things like that on Youtube. All a Game Genie code really amounts to is a patch, and we do have hacks in the demo section, and I'm sure that if someone made something that everyone fell in love with it would appear in the demo section.
Hacked ROMs are generally not accepted because they make little sense. You could eg. just hack the Super Mario Bros ROM so that you can complete the game in 30 seconds. However, that just becomes more or less a machinima video, not a tool-assisted speedrun.
Using gamegenie codes is not much better, which is why it's generally not allowed (something I personally agree with).
Well, that's kind of my point: If that is also allowed, then what other forms of tampering with the hardware should be allowed as well? Where do we draw the line? How would you define what is acceptable and what isn't (and why)?
I think I made clear the test by which I personally would draw that distinction in my previous post. Any operation that makes use of an intentionally designed feature of the console that a developer can reasonably be expected to anticipate should be considered legitimate. This would include gamepad input, the power and reset buttons and plugging or unplugging official hardware from ports for controllers and memory cards; a developer should be able to anticipate that any of these routine operations might occur during any point during gameplay. That such operations can be exploited in ways unintended by the developer, whether left+right or save-corruption, is perfectly legitimate. To rip the power supply out of the console while it is in play, or to do the same with a cartridge, or to tilt or jimmy it while it sits in the console, is illegitimate because it performs an operation that the system was not, at any point in time, designed to accommodate as an intentional feature offered to the player. This is my opinion.
For example invincibility could make some runs faster because taking-damage-as-shortcut wouldn't be limited to your life bar. In some games it may even mean that you can run straight through enemies without having to dodge or spend time killing them.
But would it be entertaining though? There are a lot of games without pacifist or no-hit runs specifically because such things are not necessarily fun to watch. I'm sure that this would fall under that category. Some tend to think of TASing as a sport in which all that matters is getting the lowest time possible frame for frame. I prefer to think of it as an art form by which emulation tools are used to produce creative and interesting gameplay. Speed optimization is important in the same way that perspective and proportion are important to an illustrator, but I don't see them as the be all and end all. The be all and end all is whether people enjoy watching the movie.
You could achieve the same thing by tampering with the game's ROM using an (emulated) gamegenie device or whatever. Why wouldn't that be "priceless"? Why is that suddenly "cheating" and/or "boring"? What's the difference?
That's kind of my point.
...
Hacked ROMs are generally not accepted because they make little sense. You could eg. just hack the Super Mario Bros ROM so that you can complete the game in 30 seconds. However, that just becomes more or less a machinima video, not a tool-assisted speedrun.
Using gamegenie codes is not much better, which is why it's generally not allowed (something I personally agree with).
Like I said above, in my opinion what really matters is that a run be interesting and creative, not that it completes the game as quickly as possible. That you could have a game display its ending sequence at startup might not be trivial, but it has no value as a TAS because if all you wanted was the ending you could just look it up on Youtube. What makes a TAS interesting is seeing how a clever manipulation of the operations available to the player can produce unexpected results. To me, seeing a player hack a game from within itself using a few frame perfect resets is entertaining. Knowing that game has been reprogrammed to display its ending sequence on start-up might earn a smirk, but that's about it, it's not much to watch.
What would make a Game Genie run interesting, in my opinion, is if it would show off some unique aspect of the game not apparent in normal gameplay; for instance, to show off debug rooms or prototype levels that didn't make it into the final game, or maybe just to show off the kind of strange game behavior that occurs when you start skipping ahead without the appropriate flags. There's also the possibility of showing off some particularly crazy iterations of actual gameplay, although that once again depends on the creativity of the TASer. The thing is that if Game Genie runs were allowed, we'd probably by spammed by kids submitting Super Mario Bros. 3 runs with permanent hammer bros. suits and infinite jumping and it would become a dreadful annoyance. I agree that Game Genie runs should not technically be allowed, but I do hope for the day that somebody gives us a good demo to prove why they should be.
As I see it the reset button is an input just like the controllers, the SRAM, the real-time-clock, etc. On most systems it just signals an interrupt and the game is free to respond however it wants. Exploiting the fact that the programmers didn't consider resetting mid-save and employ a checksum is not really any different than exploiting the fact that they didn't consider pressing left+right simultaneously and employ a speed limit.
Powering off is a trickier issue because, as Xkeeper mentioned earlier, you can't be sure what the result will be - as the chips power down they start behaving non-deterministically. NES games would tell you to hold reset, because that would stop the CPU - otherwise it would spaz out as its power supply slowly drains away and might chuck some garbage into your save file. Game Boy games use write-protected save RAM for the same reason. So you can't be certain that a hard power-off/on on a particular frame, or even a particular CPU cycle, will always do what you wanted.
That said, of course, if we assume the save RAM isn't damaged by this non-deterministic behaviour, and produce entertaining videos based on this assumption, I see no reason not to accept them. The power button is still an input to the CPU just like all the others, and developers should indeed be assuming the system will be shut down at any arbitrary time - how many people have had an electrical failure during a game?
Similarly, I see no reason to reject a run that uses a Game Genie code if the result is entertaining - no different than a ROM hack. Using a code to skip right to the end or remove all monsters isn't really entertaining, but maybe a code that makes your character run faster and jump higher might be amusing to watch. Of course you couldn't compare it to a run done without the code, but it might still make a fun video.
What bugs me about (S)RAM corruption videos is that a lot of emulators zero-fill memory at startup/reset, whereas on a real machine, the contents of memory on power-on or reset are going to be either be random, whatever was there before (possibly deteriorated), or for fresh SRAM potentially some data left there during manufacturing.
I'd be satisfied to know that emulators used in TAS videos initialize all memory to random noise on any power cycle, but if you want to really nitpick, I could stick Mario Kart in my N64, then quickly switch it off, replace it with another game, and switch it on again... the data takes more than a few seconds to deteriorate, so I could essentially control the initial contents of RAM that way... and of course uninitialized SRAM probably contains pieces of older save files... then I could make a run which "beats" a game by just tricking it to jump into some uninitialized memory where the previous game left a subroutine, which survived power cycle and conveniently jumps to this game's end sequence... or by hitting new game, saving, and quickly resetting after the game has written just enough data to mark the save file as valid, then loading a previously erased save in which the game is beaten...
but just how far down the rabbit hole do you want to go? ;)
[edit] formatting derp
I'd be satisfied to know that emulators used in TAS videos initialize all memory to random noise on any power cycle, but if you want to really nitpick, I could stick Mario Kart in my N64, then quickly switch it off, replace it with another game, and switch it on again... the data takes more than a few seconds to deteriorate, so I could essentially control the initial contents of RAM that way... and of course uninitialized SRAM probably contains pieces of older save files... then I could make a run which "beats" a game by just tricking it to jump into some uninitialized memory where the previous game left a subroutine, which survived power cycle and conveniently jumps to this game's end sequence... or by hitting new game, saving, and quickly resetting after the game has written just enough data to mark the save file as valid, then loading a previously erased save in which the game is beaten...
I wouldn't get too sad about it. Even with garbage in memory at startup -- if the game is properly written, it won't be affected by it. It might use the garbage in ram for its starting RNG seed, but you'll generally need a buffer overflow/out of bounds exploit to do anything else with it.
Well such an exploit is what I meant. If a glitch causes the game to use uninitialized memory, and the emulator doesn't random-fill it at startup/power cycle, the behaviour could be completely different. e.g. if RAM is initialized to all zeros, a glitch that cause the game to jump to some random place in memory might just lead it to execute a bunch of NOPs before finding its way to something executable, while on a real console the behaviour would be unpredictable.
Hitting the power switch is non deterministic on console, and will never be anything close to accurate. On real hardware you can cause a brownout by very rapidly toggling the power switch, and cause all manner of strange glitches that cannot possibly be replicated in an emulator. Electrical delays most likely render any possible results in an emulator impossible to replicate on console.
Grounding the reset line generally has well defined effects. Simply tripping an NMI has even more well defined effects.
So the reset button qualifies as input, but the power switch does not.
While the reset button in emulators doesn't have the precision, of it were pressed at the same time in real life,the same result should happen.
Hmm, but then, do the reset buttons suffer from contact bounce? ;)
It's true though, switching the power off is about analogous to taking a hammer to the CPU, as far as program state is concerned. The only difference being it doesn't physically destroy anything... You can't expect to emulate that accurately, unless you're emulating down to the subatomic level.
So the reset button qualifies as input, but the power switch does not.
Not to resurrect the old discussion on the subject, but my original point was not about determinism, but about what can be considered input to the game (rather than input to the CPU).
It might be a different story if the game could hook to the reset interrupt and eg. disable it during saves or do something else (such as jump to the main menu).
Well the fact is the reset input often CAN be hooked.
In fact i know of a few 8 bit computers that actually let you disable hardware resetting through software. This feature was put in as an aid to copy protection. And we all know that X-men on the genesis DOES happen to hook the reset button.
Just because games don't usually hook reset doesn't mean it's not possible for them to do so. While i can't say for sure that hooking reset is possible on all consoles and computers it's definitely possible on some.
This puts save corruption under the category of abuse of programming errors.
Also note that there is a long standing tradition of save corruption on real hardware in the case of pokemon games. It's been used many many times to cause glitches and clone pokemon.
Also not all consoles give the user access to the reset line by default (mostly portable consoles don't seem to have working reset buttons). Using buttons not available to the player does seem like cheating. In the case of pokemon RPGs, i think we can let this slide a bit though, as save corruption seems to be considered legit by the pokemon community, at least as a means of obtaining event only pokemon.
