Here, have an infinite multiverse. I'm sure my RAM startup values are in there somewhere.
Don't be sure of anything, thanks to bit propagation there are more invalid states than there are valid ones (mathematical proof and elaboration). People seem to be utterly clueless on this point.
Okay, fair enough. Though to be pedantic, in an infinite multiverse, somewhere there's a console that had the right combination of ionizing radiation strikes to initialize the RAM to the desired pattern. This is so far beyond "astronomically unlikely" as to be a complete joke, but infinite multiverses are weird that way.
Derakon wrote:
How do you prove that a given state is valid?
Take apart the hardware and examine it.
So a validity proof requires achieving that state on hardware? That seems rather strict. What if you're reasonably confident that a state is possible, but it has low odds (like 1 in 10,000)? Do you have to keep power-cycling the console until you manage to get the state you want?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
This run avoids using resets for console verification purposes. If I am to understand this correctly, it's because the emulator rewrites RAM to its cleared state when resetting, and to console verify, one would have to put in the erase cart to clear RAM every time the game is reset, which takes time. (If there are other reasons resets are avoided, please let me know.)
My understanding agrees with yours. Without using a RAM clear cart or similar trick, RAM decay is nondeterministic, so games like FF1 that rely on initial RAM state would be impossible to console-verify.
This raises a few questions for me:
...
Assuming I'm correct on point 2 above, let's say the emulator is fixed so that it does not reset RAM on power cycle when recording. Would console verification without using the clear cart mid-run for power cycles then possibly work? If not, what else could an emulator do to make reset recording work for console verification (without erase carts or other time-consuming processed)?
This runs into the "RAM decay is not deterministic" issue I mentioned earlier. When you turn the console off, its RAM state should eventually hit zero across the board (ignoring random bitflips from ionizing radiation and the like, which do happen, albeit rarely). As I understand it, this decay is broadly like radioactive decay -- there's a half-life, so after T amount of time, half the bits will (on average) be zero, after 2T 3/4ths of them should be zero, etc. But there's no guarantee that they'll ever all be zero, let alone that certain ones will be zero.
Conversely, I don't know what the half-life of a bit in RAM is; I imagine it's pretty short. It's possible that even an extremely fast reset would still result in some of the RAM decaying. But I'm not an expert on this so I'll bow to people who actually know how the hardware behaves.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Put another way: if the only difference between difficulty levels is that you have to stop every once in awhile to slowly wear down the enemy, then that's not very interesting, is it? It'd be different if the enemies got new attacks, or even if they just dealt more damage and thus forced you to be more careful with your damage boosting. In this game basically all damage taken is from environmental factors though, which as far as I'm aware don't change with difficulty, so all we're missing from the lower difficulty is longer boss fights.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Yeah, if you make a game and then make an awesome TAS of it, I see no reason why that TAS shouldn't be accepted just because nobody's heard of the game before. Hell, that'd be a pretty interesting way to advertise your game. :)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Are we talking about the boss with the giant club? Klubba? Pretty sure Dixie hits him earlier because she holds barrels above her head, while Diddy holds them in front of himself; thus she can hit the boss while he's on the way down from a jump while Diddy has to wait until he's level with the boss. Dunno how much time it saves; probably on the order of 10-20 frames per cycle.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Here's hoping for an eventual Mega Man "No magnet beam" run.
Not even remotely enough to make a "clean" Mega Man run, given the NextDelay glitch, the ladder glitch to pick up the Magnet Beam on the first visit to ElecMan's stage, the pause glitch for fast boss fights, and presumably all kinds of other issues.
Plus frankly I expect that a "glitchless" Mega Man run would be pretty dull. Though that's just me.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Nice TAS! That boulder jump is really quite something, and the rest of the run looks very well-optimized to me.
What are your thoughts on the other two Super Star Wars games?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I've seen a few TASes made like this, such as this pretty awesome Binding of Isaac run
Link to video
How on earth did they do the RNG manipulation for this? The actual gameplay demonstrated wasn't all that great, but getting Mom's Knife/Polyphemus right off the bat and having every level be XL with the boss door right next to the entrance is inconceivable without savestates or direct memory modification.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I am not remotely a Sonic expert, but I dimly recall hearing that the games are very sync-stable, i.e. changes made in one level should have no impact on actions in a later level. So (assuming I remembered correctly) you shouldn't need to redo the entire run every time a level is fixed.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The desyncs could also be caused by changes in emulation. As a crude example, if an SNES9x operation results in a pixel position of 16.999 and the corresponding operation in lsnes gets a position of 17.000, then that could be enough for some other calculation (e.g. collision detection) to return a different result, which could easily cause a desync.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Another thing I've noticed is that RNG necessarily doesn't advance just once. Sometimes it advances up to five times at once, for example during certain screen transitions (which I haven't looked into why yet).
Presumably multiple random numbers are needed at times, e.g. when placing enemies on a new screen, or if multiple active enemies have to decide what to do on the same frame. And the RNG advances each time it's used.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Depends on the TV you're using though. A CRT renders images completely differently from an LCD. Hell, as I understand it different CRTs will have vastly different displays depending e.g. on how quickly their phosphors "decay".
Since there's no objectively right answer, I'm inclined to say that whoever's going to the effort of making the screenshot should use the approach that looks best to them, and if someone disagrees then the two of them can hash things out.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
