Open joshjaysalazar opened 2 years ago
It was just pointed out to me that when it crashes, the Varia tracker's autotracking stops at loading room data. Based on the fact that the game crashes right as the room should start lighting up, I'm guessing the next room loads just fine, but when it's meant to go back to game code, that's when it gets thrown to a very wrong memory address, or to corrupted memory.
thank you for your report, crashes have indeed been reported with custom music. we'll try to investigate this customize everything except one thing, but it doesn't seem intuitive.
Absolutely agree it doesn't seem intuitive. Perhaps a pointer is being set somewhere expecting all parameters to be customized, and not accounting for the missing data that comes with leaving a parameter out? Or maybe an extra stack push or pull is happening? I'm grasping at straws here, but those are my guesses as an outsider looking in.
I've added some checks when the customizer writes data, with custom music, custom sprite and custom palettes:
In section custom_music.ips there 151 addresses In section fusion_green_varia.ips there 260856 addresses In section palette there 22218 addresses In section music there 488795 addresses No intersection found between custom_music.ips and fusion_green_varia.ips No intersection found between custom_music.ips and palette WARNING: intersection found between custom_music.ips and music -> updates a song table WARNING: intersection found between fusion_green_varia.ips and palette -> updates colors in custom sprite and gunship No intersection found between fusion_green_varia.ips and music No intersection found between palette and music
the custom music section doesn't intersect with other customizer updates in the ROM.
When using the customizer, if you go with all random colors, sprites, and use custom music, the game runs fine. But, if you do that but leave just one custom option off (such as the Samus color randomization off, or choosing to not to use a custom sprite for Samus, etc.), but keep the custom music, crashes can happen on door transitions. Have a look at this video:
https://youtu.be/D2oxeMFonuw?t=138
The crashes happen in emulators, too, but this real hardware test (thanks to someone in my community) shows it's not an emu problem. The crash happens at 2:21. The monitor shows where it thinks the crashed happened at 2:29. The monitor isn't pointing to anything interesting in memory, as you'll see, but that turns out to be part of the problem: looks like something somewhere is pointing the execution to a very wrong memory address. Either that or the data that's supposed to be there has all just been written as 0xA5. Whatever the case, the processor is suddenly trying to execute nonexistent code.
This exact same seed uncustomized or customized with every single option used does not crash. Only if you choose to not customize one thing about colors or sprites, and also have custom music on, does the game crash. The crash point does not seem consistent, except that it always falls on a door transition.
In our testing, we've also found that sometimes saving and restarting will allow us to get through the broken transition, as well as picking up an item. These are not consistent workarounds, though.