Tip: When making your overworld, mix the terrain up! Add decorations to the overworld. Don't leave large empty grass or sea regions. As an example, angled land and multiple colors look much more interesting than square land and flat, plain colors.
"I fear not the man who has practiced 10,000 kicks once, but I fear the man who runs randomly-generated ASM code."
- FireSeraphim's 0x00103A was changed to 0010310 when inserted into the decimal string.
As to be expected, the raw code is an instant, guaranteed crash. The offending lines of code are commented above in the raw code - While most are actual breaks, there is one line that doesn't crash the game but instantly results in a death. Boring!
So, after removing all the sources of an auto-crash and getting it to a state where the level can be played in some capacity, what is the result? Well...
As you can see the game is still very prone to crashing, with seemingly random movements causing a crash. If you can get past the first two screens without crashing then you're greeted with a screen of garbage tiles, with an invisible crash wall at the end. As far as I can tell there's no way to get past this barrier through normal gameplay, and even if it were possible, it would probably end up crashing anyway.
Yoshi's Island 2 is a slightly different matter though:
Shell-killing Koopas seems to cause a crash, but navigating the level is much easier and doesn't seem to be too much of a problem. Despite one odd ground tile being changed (in the gif it's a slope, in other tests it was a dirt tile), the rest of the level seems to be completely normal.
Well that was... underwhelming. Where's our flashing palettes, glitchy sprite graphics and cursed physics? Well our UberASM turned out pretty boring, but thankfully we have other types of asm to work with. What would happen if we ran our code as a block instead of UberASM?
Nothing particularly different, sadly. Placing a sprite on the block causes heavy lag. Despite inserting it with act as 25, it behaves as 125 due to our code messing up Y (hence the wings). After the code runs though, a crash quickly follows. This isn't really surprising, since when our block code runs it's doing the same stuff that it would in UberASM. Sometimes the specific point during the frame that code runs can have some different outcomes, but that doesn't seem to be the case here.
Maybe we'll have more luck running it as a sprite...?
Well things don't look too great. Perhaps our code isn't the problem though. Perhaps LoROM is too weak to handle the underappreciated genius of the code we have created? With the power of the SA-1 chip, will our code produce the wacky janky results we crave so badly?
No, uh... no, not really. But in the process of crashing the game we did produce two brand new players, M4rio and MLrio! Perhaps as you progress through the game with our code active you'll discover and unlock even more new characters!
So what did we learn?
Well... don't generate asm code randomly would be the main take-away. BRKs, stack fuckery and register/direct page fuckery are all very likely, and any JMP/JML/JSR/JSL is almost guaranteed to end up in a place that soon results in a BRK. Beyond that, predicting what exactly our code is doing/will do is very tricky. Our code had a pretty strong tendency to index addresses with X and Y, so without following those registers as the code runs and what their values are at each step, we have no idea what addresses our code is actually reading from or affecting.
Regardless, turning a user-generated string of numbers into code and seeing what it does was certainly fun, and thank you all for participating! Who knows, maybe I'll run this again next C3 and we can produce an entirely new cursed code!
This seems disappointing at a glance, but I honestly think the fact that all that monstrous amount of random code really did was make a slow motion block and change one letter in Mario's name is really funny. This was a good thread.