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.
It's not like I'm thrilled to see resetting used in real-time runs either...
It's ok to demonstrate some interesting glitch, such as triggering the different kinds of inventory bugs that can be achieved even on the real console via resetting in the pokemon games, but I don't think it should be constitute the "official" speedrunning record (if there's such a thing.) At most a sub-category (but not the "main" one.) But again, just my personal opinion.
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.
It's not like I'm thrilled to see resetting used in real-time runs either...
If to get the WR in a real time run you must get a good RNG on the first stage, then runners will reset until they get that good RNG, uninitialized RAM or no uninitialized RAM.
If to get the WR in a real time run you must get a good RNG on the first stage, then runners will reset until they get that good RNG, uninitialized RAM or no uninitialized RAM.
So (in this particular case) they are not really using resetting to glitch savedata or otherwise glitch the game. They are simply restarting the game until they get a favorable RNG. Resetting is simply the easiest way to start over. (Ostensibly the favorable RNG doesn't come from the fact that they pushed the reset button, but simply because of different timing and actions they do on each run.)
That's not the kind of "reset abuse" I was referring to.
As a case for perspective:
The Final Fantasy 1 console runner Feasel has been dealing with this. In between runs he must let RAM decay for about 10 minutes before booting the game back up or the RNG does not clear correctly. I think he leaves the console powered on but not plugged in to do this, but I am not sure.
In this sense it may be beneficial for him to find a different game that can leave ideal values in the RNG spots (probably 2 addresses) in RAM to set up extremely good RNG. He would then power off that game, pop in Final Fantasy 1, and start with whatever RNG he wanted (I think). He has been using the "cleared" state up until now.
There may be desire to have the "pull the NES out of the box and play it" state, and there could also be desire to have the "This NES was just played 10 minutes ago with a different game with strategically manipulated RAM" state. Personally I don't really see the reason to exclude the latter case.
(If I misstated anything, please correct me. This is my current best understanding of the topic.)
As a follow-up question, could someone explain how 0000 0000 0000 0000 would break a game? I would speculate this is what you get when you first plug the console in. Does that get modified at all by providing a power source?
As a follow-up question, could someone explain how 0000 0000 0000 0000 would break a game? I would speculate this is what you get when you first plug the console in. Does that get modified at all by providing a power source?
See the two links to byuu's forum I posted earlier.
As a follow-up question, could someone explain how 0000 0000 0000 0000 would break a game? I would speculate this is what you get when you first plug the console in. Does that get modified at all by providing a power source?
See the two links to byuu's forum I posted earlier.
So are we going to say that a nuclear bomb detonated near the NES console and by chance the radiation made all the bits change to the proper value for the credits to run?
Or that the electrons in the NES all randomly quantum tunneled so that they form a desired state?
A TAS should abuse the software, but not the hardware in my opinion.
So are we going to say that a nuclear bomb detonated near the NES console and by chance the radiation made all the bits change to the proper value for the credits to run?
Or that the electrons in the NES all randomly quantum tunneled so that they form a desired state?
A TAS should abuse the software, but not the hardware in my opinion.
So, do you think that your NES boots up with a perfect 0000FFFF0000FFFF... uninitialized RAM pattern? That's just as unlikely, yet we accept it out of tradition.
So are we going to say that a nuclear bomb detonated near the NES console and by chance the radiation made all the bits change to the proper value for the credits to run?
Or that the electrons in the NES all randomly quantum tunneled so that they form a desired state?
A TAS should abuse the software, but not the hardware in my opinion.
That IS abusing the software. The software is what is reading uninitialized ram.
Wait....does that apply exactly the same even for the NES? What about other consoles? If it does, to what extent? Because like for some games, there are runs that may never encounter such emulation problems since it's route doesn't involve any use of glitches/tricks that may utilize said problem.
For example, I'm sure if the any% SMW was improved, the error seen in the glitched run would not cause issues in console verification.
Wait....does that apply exactly the same even for the NES? What about other consoles? If it does, to what extent? Because like for some games, there are runs that may never encounter such emulation problems since it's route doesn't involve any use of glitches/tricks that may utilize said problem.
It will not apply to most consoles that use bootloaders or BIOS as they often initialize the RAM to a specific value at start-up.
So, do you think that your NES boots up with a perfect 0000FFFF0000FFFF... uninitialized RAM pattern? That's just as unlikely, yet we accept it out of tradition.
I think it should be the "intended state", if there is such a thing. If there isn't, it should be the most likely one, if that can be determined.
RachelB wrote:
That IS abusing the software. The software is what is reading uninitialized ram.
The hardware is what makes the uninitialized RAM non-deterministic.
Wait....does that apply exactly the same even for the NES? What about other consoles? If it does, to what extent? Because like for some games, there are runs that may never encounter such emulation problems since it's route doesn't involve any use of glitches/tricks that may utilize said problem.
NES and other consoles is likely similar for the parts of RAM that uses similar chips, though I'd trust only actual hardware tests.
And as Warepire said, those with BIOSes that initialize RAM won't be affected by this topic at all.
I think creaothceann and Derakon bring up some good points here. If I have to choose between allowing and not allowing this, then I would prefer to not allow it. The starting RAM values should be the maximum likelihood values as determined through adelikat's suggested test.
While I agree that it techincally makes sense to treat any variable that affects sync as input in the movie file (i.e. the movie + emulator should completely specify the system), I think an arbitrary limit must be placed at some point. As Derakon mentioned, we can make exactly the same argument with regards to cosmic ray bit-flips as for initial ram state: Cosmic rays can flip any bit at any time, and arrive completely randomly (but rarely). If the emulator were to emulate this, then it would sacrifice sync-robustness. One can either arbitrarily choose a fixed cosmic ray pattern (such as no rays), or let the user specify them in the movie. But in the latter case, the TASer would be able to manipulate any ram value at will (i.e. as if he had a game genie or similar). That case is more extreme than the one we're talking about now, but they are otherwise very similar.
But in situations like these, I think the best choice isn't to choose between allowing or not allowing, but to choose both, and place them in separate categories. The normal any% category should not allow it, but the "any%, prepared ram" category would allow it. In general, I think pretty much anything should be admissible as long as it is clearly labeled.
I'd still be very surprised if the poweron state of a console were anything like random. I can believe that some bit patterns cannot come up at all, unless they were previously left in memory by a different game.
"maximum likelihood values as determined through adelikat's suggested test" means "closest to hardware".
And tasvideos does prefer accurate emulation, clean ROMs, etc.
Emulator Coder, Site Developer, Site Owner, Expert player
(3598)
Joined: 11/3/2004
Posts: 4738
Location: Tennessee
creaothceann wrote:
"maximum likelihood values as determined through adelikat's suggested test" means "closest to hardware".
I have to disagree with this. Anything that CAN happen is equally "closest to hardware" in terms of accurate emulation. If something can be proven to be more likely, maybe that is a good pattern to be the default. However, restricting the emulator to that one possibility when others are possible does not make an emulator more accurate
So, do you think that your NES boots up with a perfect 0000FFFF0000FFFF... uninitialized RAM pattern? That's just as unlikely, yet we accept it out of tradition.
I think it should be the "intended state", if there is such a thing. If there isn't, it should be the most likely one, if that can be determined.
I believe the following to be true:
1) There is no intended state (as in, the creators of the NES did not guarantee or expect uninitialized RAM to be in any particular state, because it would be foolish to rely upon anyway).
2) Each NES has a different 'most likely state' (due to manufacturing differences, etc).
This makes what you are proposing difficult.
While I agree that it techincally makes sense to treat any variable that affects sync as input in the movie file (i.e. the movie + emulator should completely specify the system), I think an arbitrary limit must be placed at some point. As Derakon mentioned, we can make exactly the same argument with regards to cosmic ray bit-flips as for initial ram state: Cosmic rays can flip any bit at any time, and arrive completely randomly (but rarely). If the emulator were to emulate this, then it would sacrifice sync-robustness. One can either arbitrarily choose a fixed cosmic ray pattern (such as no rays), or let the user specify them in the movie. But in the latter case, the TASer would be able to manipulate any ram value at will (i.e. as if he had a game genie or similar). That case is more extreme than the one we're talking about now, but they are otherwise very similar.
This is a nice argument, but I think you are overlooking a fatal flaw: it's not about what actually might happen during real use at all. If that were the case, we would be discussing allowing emulation of things like the half-inserted cartridges that resulted in Geddan. What we care about is the specification. The state of RAM during play is fully specified by the NES hardware design. The state of RAM at power-on is specified to be undefined - this is a common concept in both hardware and software programming; C compilers for instance rely heavily on specified undefined behavior to optimize code.
In light of this, I actually think it's pretty silly to go by "most likely hardware configuration", since that is a) going to vary by model and even individual device to drastic degrees (it was unspecified and thus not a target of factory testing), and b) going to result in some games randomly getting advantages and others not, in a very unsatisfying way.
I know it's not a very intuitive result, and thus unpalatable to many people, but I think that full control of power-on ram (unless there ARE specifications I'm unaware of that declare certain states impossible) should be the default. I don't think TOO many movies will be affected by this, and we can always have a "doesn't initialize RAM" branch for those that are.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Looks like people are not okay with merging 2 concepts into 1: they want "arbitrary RAM" runs be separate from "untouched RAM" ones. Which introduces a problem with categorization.
If some games allow to abuse RAM being uninitialized, there will be a wide range of results of that. Some runs may be improved by just several frames due to better luck abuse, some may be improved by minutes due to heavy glitching. Some of them are Moons content, which means only what people like will be done (acceptance wise and obsoletion wise), so not to worry too much, but others are in Vault, where it may become an issue: messing around with RAM gives kind of advantage over the runs that were not intending to do it, but would that mean they are obsolete?
Having a special tag is obvious, but what about tiers and obsoletions?
To me it looks a bit similar to "when to end the movie". It ended up putting all the responsibility on the author. So that tweaking the ending won't count as improvement. And thus, cutting out artistic choice won't obsolete the current movie where it was used.
What if Vault keeps accepting "anything goes", including "preset RAM", and for Moons it must be decided case by case? Because if someone dislikes the abused possibility, there might always be a movie with more strict goals in Moons, if it deserves it. If not, be my guest in Vault, where "anything goes" and we can't demand from movies to be of what we like. Speed by any cost.
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.
What if Vault keeps accepting "anything goes", including "preset RAM", and for Moons it must be decided case by case? Because if someone dislikes the abused possibility, there might always be a movie with more strict goals in Moons, if it deserves it. If not, be my guest in Vault, where "anything goes" and we can't demand from movies to be of what we like. Speed by any cost.
