-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Leaving one parameter off the customizer causes crashes when custom music is used #83
Comments
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. |
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 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.
The text was updated successfully, but these errors were encountered: