That's not what this sounds like: "We could have an entire program sitting in unitialized memory, and through memory corruption techniques maybe we could get the game to start executing at this point and completely take over the game"
Then I suggest you look at the rest of this post, and at the run that prompted this discussion (which was about initializing six bits of register), as well as the discussion right here where people point out that it's the runner's responsibility to explain how exactly their "trick" is possible in the first place.
Because this has every thing to do with speedrunning, and nothing with "designing your own ROM". Besides, by the current rules players can already design their own ROM, unless you'd wanted to claim that Battle Kid is somehow ineligible for TAS'ing?
This would be the closest we can get to hardware without sacrificing replayability on emulators. Syncing TASes will still be somewhat difficult on hardware, but that's going to be unavoidable.
No it's not. You could use a random ram state, and then save it to the movie file.
And then taking that state and writing it to the console RAM? That might work.
RachelB wrote:
Warp wrote:
Speedrunning is playing the game.
Usually the point of speedrunning is to avoid playing as much as possible.
Finishing in the fastest way is just to rate movies against each other. They would be pretty boring without entertainment.
arukAdo wrote:
Voting yes since this can improve tasing as a whole, improve current movies etc...
Because this has every thing to do with speedrunning, and nothing with "designing your own ROM".
I fail to see how setting RAM values even before the game has started constitutes speedrunning.
The difference between setting RAM values because they theoretically might be like that by chance, and setting them explicitly via external means while the game is running, is artificial at best. One is not any more "speedrunning" than the other, not even if we were to loosen up the definition and allow achieving some goal (other than getting to the end of the game) as fast as possible.
I would go so far as to say that "the console RAM must be set to all zeros (or whatever) before starting the run" is on par with "the run must start from powerup". (And, if it were up to me, also "resetting is not allowed.")
At least I want to see the game played with superhuman accuracy. Why would I want to see a different program being run?
Joined: 5/2/2006
Posts: 1020
Location: Boulder, CO
Warp wrote:
I would go so far as to say that "the console RAM must be set to all zeros (or whatever) before starting the run" is on par with "the run must start from powerup". (And, if it were up to me, also "resetting is not allowed.")
Why all zeros?
Why pick this initial state over another? What criteria should be used to determine if an initial state is a valid choice?
I only ask to point out that the choice is arbitrary. If the rule should be that the initial state should be close to what a real console might have, then that is reasonable. If the rule should be that you can do whatever you want, that is reasonable too. But choosing one in particular with no criteria at all is not a reasonable rule.
I think maybe Warp should re-read the thread, since he's retreading old ground. Specifically, the "zero out RAM" thing was debunked in adelikat's initial post (it causes some games to break!), and we've already had an extensive argument about what kinds of "set initial state" runs would be acceptable. Meanwhile it looks like there's going to be a project to actually read out what the NES's initial state tends to be, allowing us to have some idea of what setups are actually realistic.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
To get a better idea of what kind of impact this would have, I decided to look at a number of NES games and see which access uninitialized RAM.
I modified Bizhawk slightly to monitor the RAM usage. If the game read from a RAM address before it has written to it, I recorded that. I also recorded what addresses were written to.
I took a list of NES games that the site has movies for, ran them for 600 frames each in that modified Bizhawk, and then outputted the data collected. I then turned the data into images to make it easier to digest the information.
Here is the image set (warning: large/long images)
Each 8x8 pixel block represents a RAM address, starting at 0x0000 at the top left, and ending at 0x07FF at the bottom right. The colors mean the following:
Black - RAM was not read from or written to (still uninitialized)
Green - RAM was written to first
Red - RAM was read from before it was initialized, and still hasn't been written to (still uninitialized)
Orange - RAM was read from before it was initialized, but has since been written to
Keep in mind that this data is from only 600 frames of the game, and with no input. The results may change if input is given or the analysis is run for longer.
You can tell from the images that a large number of games access uninitialized memory, but I'm not sure what they are doing with it. As other people have said, some games start up in a different way depending on the initial state of the RAM. Being able to control this initial state might be beneficial to movie authors, but I'll leave that up to other users who know more about each game to determine. This data was simply to get an idea of how many games might be impacted by this new policy.
Also, if anyone is interested in seeing my changes to Bizhawk or the raw data I made the pictures from I'll be happy to post it.
I fail to see how setting RAM values even before the game has started constitutes speedrunning.
The difference between setting RAM values because they theoretically might be like that by chance, and setting them explicitly via external means while the game is running, is artificial at best. One is not any more "speedrunning" than the other, not even if we were to loosen up the definition and allow achieving some goal (other than getting to the end of the game) as fast as possible.
I would go so far as to say that "the console RAM must be set to all zeros (or whatever) before starting the run" is on par with "the run must start from powerup". (And, if it were up to me, also "resetting is not allowed.")
At least I want to see the game played with superhuman accuracy. Why would I want to see a different program being run?
You know what? It's way too similar to the attitude regular gamers sometimes have towards TASing. "Why overcome human skills in the first place? It's only interesting to see how a real human can handle that!" "Why overcome human skills to this exact extent? You must stick to only certain kinds of entertainment!"
And now it's this. "Okay, you are allowed to overcome certain aspects of human skills. But not that much, you intriguer!"
Warp, the ground that is now being discovered is expanding the very "overcome human skills to play a game" concept. If we are physically able to do trick A with assist of our tools (omnideveloped), then it is always exciting to try trick B, that we only could think of (arbitrary code on console), and then looking for some trick C that is not even known, but will open insane possibilities - that's what makes us evolve as a community!
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.
Why not?
The point is that the RAM state should be inconsequential and the same for all runs. Not meddling with the RAM prior to running the game should be regarded the same as not using a savestate to start the game, and using a cartridge with no savedata on it.
Of course I understand that I'm fighting windmills here, but that's my opinion, for what it's worth.
Emulator Coder, Site Developer, Site Owner, Expert player
(3598)
Joined: 11/3/2004
Posts: 4738
Location: Tennessee
Warp wrote:
Twelvepack wrote:
Why all zeros?
Why not?
As already mentioned, if it were all 0's on NES, some games would break. And as linked here, there's good evidence for what the SNES starts with (or most likely still start with) and the evidence is not leaning towards all 0's. In both of these consoles, it is a highly unlikely event (were aren't totally sure it is a possible event)
The point is that the RAM state should be inconsequential and the same for all runs.
I really like this wording, and the most usable for site policy I've heard so far (if we were going to strictly limit ram possibilities). All 0's is inconsequential, as is a pattern of 0x0000FFFF on NES. However, BOTH are inconsequential, so that still leaves us with the problem of picking just picking one out of many equally viable patterns, or someone allowing a tight range and deciding that range.
Of course I understand that I'm fighting windmills here
Well, the point here isn't the fight, nor winning it. It is about putting our collective brain to work. To that end, your (everyone's) contributions here are appreciated, regardless of outcome.
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
What would be the downside (aside from being difficult to verify on an actual console) of the TASer setting the initial RAM values to whatever they wanted?
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
Well,
as mentioned before, the distribution of 1s and 0s is clumpy (at least in an SNES in the WRAM), which means that some of these combinations may actually be physically impossible on an unmodded system, irrespective of how many times you power on.
(Things like areas of memory are all set or unset as a unit, or this area affecting that area, or a lowered voltage state during power on transition .)
If that is the case, that's interesting too, but much harder to constrain and validate, and it likely varies from console to console, so will there be a single "test" console? Or will we make a theoretical "best" console?
Ultimately, that's just too much complexity in my opinion. And considering that's for a self contained system, when in real life systems are not self contained, and that it's entirely possible that a group of rogue cosmic rays knock the values of ram states immediately after power on to the desired values, I think the best thing to do in this situation is allow TAS-specified initialization.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
What would be the downside (aside from being difficult to verify on an actual console) of the TASer setting the initial RAM values to whatever they wanted?
That isn't allowed, because it needs to be a valid RAM stat, which needs come from a list with those valid RAM stats from real hardware.
What would be the downside (aside from being difficult to verify on an actual console) of the TASer setting the initial RAM values to whatever they wanted?
For the overwhelming majority of games, this would either (1) make no difference whatsoever, or (2) only start the random number generator at a different value.
Actually an interesting test would be to take 100 runs from the site, reprogram BizHawk to start with the RAM filled with random numbers, and see if the movies still sync. I'd estimate that at least 95% of them still would.
Other things that could potentially affect the RAM state on powerup: temperature (and humidity?), proximity to speakers or a CRT (fluctuating magnetic fields), "cleanliness" of power (fluctuation of voltage source), time since last power on (and game played when last powered on)...uh, maybe solder whiskers on the card?
Hell, if you want to be really picky, it's possible for stray radiation from cosmic rays to flip bits in your RAM.
I would still like to see results from someone testing what power-on RAM looks like, as a matter of curiosity at the very least. And it's better to use a "verified" startup RAM state than a wholly-synthetic one. But I don't think we can assume that a single set of measurements from one console in one set of conditions will be representative of all consoles everywhere.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Just like most TASers/TASes won't need sub-frame resets, most won't need uninitialized RAM tinkering. But when it can be used to do something cool/needed for optimal RNG, it ought to be there and available.
If it's used for a really dodgy reason, e.g. to make a 1 in a billion chance really specifically picked set of RAM values that create code to execute or anything else odd like that, then the submission will be rejected for not being physically feasible, I'd think.
(Also, think of how cool uninitialized RAM changing april fools jokes could be!)
Movies are no longer directly comparable because the base system has been changed.
Ideally, the chain of emulation goes from real hardware → emulators → TAS. A TAS changing the emulated hardware goes the other way around (and those who want to verify those TASes must find ways to change real hardware before they can run them).
Okay, I'm curious, are there any games that would be faster to run in real time, than to tas using warp's rules (no initial ram state manipulation, and no resetting, are two he's said in this thread)?
I don't understand the desire to limit tases from doing things that could just as well be done by real time runners. I feel like that defeats the entire purpose of a tas.
For the overwhelming majority of games, this would either (1) make no difference whatsoever, or (2) only start the random number generator at a different value.
Actually an interesting test would be to take 100 runs from the site, reprogram BizHawk to start with the RAM filled with random numbers, and see if the movies still sync. I'd estimate that at least 95% of them still would.
How about extending that to any run that could sync on the current Bizhawk and see would they sync if the RAM was filled with random numbers?
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
creaothceann,
if the TAS was constantly modifying the RAM, (Game Genie/Game Shark/Action Reply) that would be against the rules.
If the TAS sets the RAM values at the start and did not change them after power-on, except by player input, would that be OK? SRAM is not something that the TAS should set on power-on (except for exceptional exceptions). The game is free to change those RAM values (if the game's code instructs it to). The player is also free to change the RAM values, so long as it's via input.
Another way I could say it is, "Set Console's RAM to get best RNG."
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
I don't understand the desire to limit tases from doing things that could just as well be done by real time runners. I feel like that defeats the entire purpose of a tas.
Real time runners can't change the state of RAM at power-on to anything they like. At best they could reset the console (when they see through the game's actions that a RAM cell didn't have the desired value at power-on) until they get the values they want. Also, this only works for certain patterns; you can't get all values for all RAM cells.
hegyak wrote:
If the TAS sets the RAM values at the start and did not change them after power-on, except by player input, would that be OK? [...] Another way I could say it is, "Set Console's RAM to get best RNG."
No, it wouldn't be OK imo. A TAS is a replacement for human input (where "human" is "godlike"), and input alone can't do that even before the first instruction is executed. It feels conceptually wrong.
I'd be OK with a modified ROM that sets the values before resuming its actual code, or a completely separate category.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
creaothceann wrote:
hegyak wrote:
If the TAS sets the RAM values at the start and did not change them after power-on, except by player input, would that be OK? [...] Another way I could say it is, "Set Console's RAM to get best RNG."
No, it wouldn't be OK imo. A TAS is a replacement for human input (where "human" is "godlike"), and input alone can't do that even before the first instruction is executed. It feels conceptually wrong.
I'd be OK with a modified ROM that sets the values before resuming its actual code, or a completely separate category.
In this case, the first input (although not obvious?) is the power-on action, if we handpick a valid state of "uninitialized" RAM, wouldn't that be equivalent to powering on the console at "the perfect moment"?
In this case, the first input (although not obvious?) is the power-on action, if we handpick a valid state of "uninitialized" RAM, wouldn't that be equivalent to powering on the console at "the perfect moment"?
You could see it that way, I guess, as long as the RAM state fits to what the real hardware does (patterns with a little bit of variation).
Personally, that still makes the TAS too different from authentic*, but I guess most people won't care much about that.
*There's the idea that you could take a TAS of one of the launch titles of a system (e.g. SMW or SM64), give it Data, who goes back in time to the launch event and completes the game in front of the audience. That wouldn't be possible with a TAS that requires specific RAM state.
In this case, the first input (although not obvious?) is the power-on action, if we handpick a valid state of "uninitialized" RAM, wouldn't that be equivalent to powering on the console at "the perfect moment"?
Depending on the exact RAM state wanted, this could range from "merely unlikely" (e.g. you need a single byte to have a specific value, at odds of 1 in 256) to "stretches credulity" (need multiple bytes at odds of 1 in 2^(8 * number of bytes)) to "unlikely to ever happen before the heat death of the universe" (RAM "naturally" contains a boot loader or other moderately complex program). It depends on a) what the RAM state tends to look like naturally, and b) how picky you're being.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Real time runners can't change the state of RAM at power-on to anything they like. At best they could reset the console (when they see through the game's actions that a RAM cell didn't have the desired value at power-on) until they get the values they want. Also, this only works for certain patterns; you can't get all values for all RAM cells.
Exactly. They can try again until they get the desired values. Why can't we do the same thing, just using tas tools?
*There's the idea that you could take a TAS of one of the launch titles of a system (e.g. SMW or SM64), give it Data, who goes back in time to the launch event and completes the game in front of the audience. That wouldn't be possible with a TAS that requires specific RAM state.
That doesn't make the tas unauthentic. Every single game that reads uninitialized ram and does something that could affect sync with it will desync when played back on console. There's nothing you can do about that. The game will run different every single time you start it.
