This topic is for the purpose of discussing #5883: Masterjun's SNES Super Mario World "sram game end glitch" in 00:11.13

It just so happens that our accepted SNES emulators fill the SRAM with the required byte. Yes vote.

Yes for the science Please yes for a new branch

Thanks for submitting this. I've been arguing for quite a while (over on the IRC channel) that depending on the values of uninitialized memory in a way that's meaningful to the run should be disallowed, and this movie is a great argument as to why. For people who haven't seen the argument before: one of my main concerns is that we measure runs by input length, as it's something that has a hard limit for optimization; the shorter the input, the less precise the instructions you can give to the game, and at some point you can't give instructions that lead to it being cleared. This makes speedrunning an inherently interesting goal for games. (Compare things like "max out the score counter" with no secondary goal like minimum time, or "play as long as possible"; unlike speedrunning games, these will frequently be uninteresting loops of doing the same action forever.) However, preinitializing uninitialized RAM/SRAM allows an end-run around the whole concept of optimizing for shortest input; the instructions you're giving to the game are now mostly not contained in controller input at all, but in the initial conditions. Claiming something like this as a speed record is misleading, because the amount of information given to the game is no longer reflected by the length of the input file. In particular, it makes optimization meaningless (apart from optimization of the portion of the game before the payload is read), as you can get more or less arbitrary effects without adding any additional input (up to the amount of uninitialized RAM/SRAM that exists in the console/cartridge at the time). (You can draw a parallel with code golf, a competition to write a program as short as possible, as opposed to beating a video game as fast as possible. Code golfing competitions disallow things like putting most of the code in the file name, so that it doesn't count against the file size. This is an entirely analogous loophole.)

However, RAM/SRAM has to be initialized to something. If even an arbitrarily chosen pattern can give an unexpected advantage to ACE TASes (for example a byte arbitrarily being 0xFF can be part of the payload), what solution could possibly be chosen? What if an RTA ACE run relies on a specific RAM/SRAM pattern? It would be weird if the TAS can't beat the real time speedrun.

yes vote

One possibility would be to add the tags "works for all SRAM", "works for likely SRAM", and "requires unlikely SRAM" for runs which are totally SRAM-agnostic, mirror RTA routes that require specific SRAM, and custom build their own SRAM, respectively. If two runs that make different choices are both interesting, they could be separate branches, but in most cases I would see this just being informational. SMW might be a good case for two branches, accepting this run as an obsoletion of the current run on the "requires unlikely SRAM" branch, and opening up space for a new "works for any SRAM" run (or I guess, giving that record back to whatever the last any% publication was before SRAM-specific glitches were added).

this is getting ridiculous... i love it. yes vote

i voted no this was not entertaining and did not get 99 lives

This should obsolete the 96 exits TAS.

Is it console verified?

Yes vote! Masterjun never ceases to amaze. As for the SRAM debate.. yeah, it's complicated :/ Whatever the decision, it seems to me it's important to at least inform the viewers about it when it's used. It's the same kind of reasoning behind why it's important to communicate that arbitrary code execution was used, or that tools were used at all for that matter (in contrast to RTAs). As for the risk that this may trivialize TASes to the point of making them uninteresting in the long run, or that banning it (requiring TASes to work on all SRAM, for instance) could lead to strange things like RTAs that are faster than TASes, why not let things run like they are for now and wait to see if they become real problems? It's not like these rules can't be changed retroactively in the future after all.

I think runs that abuse a particular design of an emulator rather than the console should be disallowed.

I think runs that abuse a particular design of an emulator rather than the console should be disallowed.

If I understand the submission description correctly, this run isn't abusing an emulator quirk. It's just that the method used to achieve arbitrary execution requires part of the save data to be in a certain state, in both the published run that does arbitrary execution and this submitted run. It just happens that the published run works correctly when the SRAM is clean. This submission reminds me of NG+ runs, like Chrono Trigger. For those to be accepted, a separate input file needed to be available to create the NG+ file. That way, judges could verify that the save SRAM can be generated by the game. I wonder if that could also be applied here.

We've had a similar debate in the RTA about what to do with dirty RAM/SRAM, and didn't quite settle it. I agree with Personman that here it makes sense to have labels/categories for "works for all SRAM", "works for likely SRAM", and "requires unlikely SRAM". For what it's worth, here's the SRAM I dumped from a SMW cartridge I bought off ebay, and it looks like most of the ununsed SRAM values were unmodified from the factory (TLDR: it's mostly filled with $54, with some other values appearing at semi-random locations): https://www.dropbox.com/s/xctc1p4g7pku8ti/SMWUntouched.srm?dl=0 Of course, with crashes it's easy to accidentally overwrite large swaths of SRAM.

April's 1st is over. I'd rather vote to purge the current record from this site instead of accepting this submission. As far as I know, the current ACE strat requires one single byte SRAM+101 to have certain values to work (not just $FF). lsnes has to have some default. The odds of having a payload in the SRAM from factory is negligible.

We do not allow save-anchored movies. We want a standard starting point for movies (power-on). Saves introduce an infinite amount of possible variation that may cause the game to behave differently compared to starting from power-on. They also can be hacked, allowing nearly transparent cheating.

April's 1st is over. I'd rather vote to purge the current record from this site instead of accepting this submission. As far as I know, the current ACE strat requires one single byte SRAM+101 to have certain values to work (not just $FF). lsnes has to have some default. The odds of having a payload in the SRAM from factory is negligible.

We do not allow save-anchored movies. We want a standard starting point for movies (power-on). Saves introduce an infinite amount of possible variation that may cause the game to behave differently compared to starting from power-on. They also can be hacked, allowing nearly transparent cheating.

So what would be the solution? Would using a somewhat more "valid"/real life/whatever SRAM pattern work, if it ended up "only" wasting a few frames according to the notes? (Actually, now I wonder what would happen if someone uploads a new run with a different, more "legit" SRAM pattern)

SethBling's SRAM stats (note: I don't know iif he is him nor it's a valid SRAM dump):

Code:     1 0x1 '
' Count: 34
Code:     2 0x2 '' Count: 22
Code:     3 0x3 '' Count: 9
Code:     4 0x4 '' Count: 5
Code:     6 0x6 '' Count: 8
Code:     7 0x7 '' Count: 4
Code:     8 0x8 '' Count: 7
Code:    15 0xF '' Count: 1
Code:    18 0x12 '' Count: 3
Code:    23 0x17 '' Count: 6
Code:    32 0x20 ' ' Count: 686 -- this is 0x00. There's no 0x20 in the dump
Code:    39 0x27 ''' Count: 2
Code:    41 0x29 ')' Count: 2
Code:    44 0x2C ',' Count: 2
Code:    48 0x30 '0' Count: 1
Code:    55 0x37 '7' Count: 2
Code:    57 0x39 '9' Count: 1
Code:    58 0x3A ':' Count: 2
Code:    59 0x3B ';' Count: 1
Code:    64 0x40 '@' Count: 2
Code:    65 0x41 'A' Count: 2
Code:    70 0x46 'F' Count: 2
Code:    73 0x49 'I' Count: 1
Code:    74 0x4A 'J' Count: 1
Code:    79 0x4F 'O' Count: 3
Code:    84 0x54 'T' Count: 1102 -- 53.8% of T
Code:    85 0x55 'U' Count: 4
Code:    86 0x56 'V' Count: 1
Code:    87 0x57 'W' Count: 1
Code:    88 0x58 'X' Count: 3
Code:    90 0x5A 'Z' Count: 1
Code:    91 0x5B '[' Count: 1
Code:   101 0x65 'e' Count: 2
Code:   104 0x68 'h' Count: 8
Code:   105 0x69 'i' Count: 2
Code:   118 0x76 'v' Count: 1
Code:   120 0x78 'x' Count: 8
Code:   125 0x7D '}' Count: 2
Code:   127 0x7F '' Count: 2
Code:   129 0x81 '' Count: 2
Code:   141 0x8D '' Count: 2
Code:   143 0x8F '' Count: 1
Code:   157 0x9D '' Count: 1
Code:   165 0xA5 '¥' Count: 1
Code:   168 0xA8 '¨' Count: 3
Code:   172 0xAC '¬' Count: 3
Code:   174 0xAE '®' Count: 1
Code:   184 0xB8 '¸' Count: 2
Code:   209 0xD1 'Ñ' Count: 1
Code:   231 0xE7 'ç' Count: 2
Code:   235 0xEB 'ë' Count: 1
Code:   238 0xEE 'î' Count: 1
Code:   240 0xF0 'ð' Count: 2
Code:   246 0xF6 'ö' Count: 1
Code:   249 0xF9 'ù' Count: 1
Code:   250 0xFA 'ú' Count: 3
Code:   252 0xFC 'ü' Count: 1
Code:   253 0xFD 'ý' Count: 6
Code:   255 0xFF 'ÿ' Count: 7
Code:   338 0x152 'Œ' Count: 14
Code:   352 0x160 'Š' Count: 3
Code:   381 0x17D 'Ž' Count: 4
Code:   402 0x192 'ƒ' Count: 13
Code:  8216 0x2018 '‘' Count: 1
Code:  8222 0x201E '„' Count: 2
Code:  8224 0x2020 '†' Count: 2
Code:  8225 0x2021 '‡' Count: 4
Code:  8230 0x2026 '…' Count: 6
Code:  8240 0x2030 '‰' Count: 7
Code:  8249 0x2039 '‹' Count: 2
Code:  8250 0x203A '›' Count: 1

So the fundamental problem here is that we require games to run from a blank cartridge (and a blank console, i.e. without pre-initialised RAM), but in practice the cartridge and console will have to have some values in their memory and SRAM, and it's unlikely that the game developers or console manufacturers took these into account when creating the game or console. There will always actually be values there, of course, but they might not be the same. Games are normally designed so that in normal gameplay, the values don't matter. (There are a few exceptions, e.g. some games might use the values to initialise an RNG.) However, it's possible to do glitches that make the values in question very relevant. Such glitches will not have deterministic results on a real-life console. On emulators, they will of course have deterministic results (because emulators are designed to be stable), but what those results are will be based on an arbitrary decision by the emulator designer. I can see a few options: a) Program emulators to use an "uninitialised memory" value for storing the content of uninitialised memory. If this is read at any point, halt and refuse to continue running the game. This would ensure that any emulator run will have the same result on a practical console. b) Work out what the most likely values to appear on a blank cartridge/turned-off console are, and set that as a set of fixed values which all emulators must use. This might or might not be 100% realistic. c) Work out the probability distribution of values to appear on a blank cartridge/turned-off console. Then for any run that relies on particular values appearing in particular places, calculate the probability that those values are there. Time a run as though it repeatedly resets until it gets the values it needs (as soon as the fact that they're incorrect becomes observable through, e.g., audio or video output), and an average number of tries is needed to get to the values.

Interesting, I guess with ever increasing technical prowess in researching games this was bound to come up eventually. My opinion would be that as long as the SRAM state needed can be constructively achieved without relying on anything uninitialized, then it’s fine. In this sense it’s similar to a NG+ run, where you still have a setup time but that time isn’t counted toward the run. In SMW you can obviously just get ACE and write whatever you want to SRAM, but generally i would say a set up file is required.

So... is anyone up for console-verifying this one? :)

Ais, your point about 'adjusting the time' to match what the net expected number of resets requires makes no sense to me from a TAS context. Luck manipulation is a big part, making unlikely things happen on command is huge. Personally, I think it would be simplest to require set parameters for a 'clean save', ie, specific RAM values. That way everyone knows what to expect and everyone has to play by the same rules.

om, nom, nom

I was waiting for an elaborated rejection regarding SRAM + uninit RAM rules territory. Okay... so... If the lsnes SRAM is valid, what other set of bytes can be valid? Or other words, if lsnes SRAM is known to be invalid, what should be valid? SethBling's 0x101 byte is 1. lsnes is 0. This TAS is FF. Also if Masterjun could make an ACE without relying on uninit RAM and SRAM modification, changing these two while making a verification movie, should he submit this movie again but without rejection? This also sounds.... educational. edit: AFAIK you can ACE on console without relying on SRAM and uninit RAM. Adding this text to avoid useless debates.