Version 2021-02-12:
https://filebin.net/7spaiz2xfys6b2i1/SoM_Turbo.210212.zipAlternate Link:
https://www.sendspace.com/file/l0juwwChanges:
- Updated pre-release Reborn v1.10 (though don't have last night's corrections)
- Updated hmsong's Items\Stardust_Herb\Drop_And_Shop_Changes
- Rewrote Audio\Async_Music_Crossfade, explanation below
Technical Changes:
- Added bank 0x03 / $C3 unused space to Technical\Overwrite_Unused_Data
So the rewrite to Async_Music_Crossfade gets one of my SoM bucket list goals out of the way. This was the third full rewrite, and really like sixth revision, to get it working reasonably.
In vanilla, when the command is issued to start playing a song, it completely locks up the game while it completes. If it wants the previous song to fade out before starting / fading in the new song, the fade out process is also part of the wait. Before this version of Async_Music_Crossfade, I had made the previous song fade-out asynchronous, but starting the new song still had a (usually) long pause.
So how does it work now?
When a new song is set to play, if the currently playing song needs to fade out, that's dealt with first. A fade-out-song command is sent to the sound CPU, and game code checks every frame if the time for that has passed. Once it has (or if no fade out was requested), it then sends the command to play the new song. I added hooks to a bunch of steps in the communication routine between the SNES main CPU and its sound CPU so that I could defer until a later frame to give the game time to function in between more data transfers and synchronization signals. I force a deferment every 512 bytes of song sequence data, and 756 bytes of instrument data (instrument data can be many kilobytes), plus at some specific synchronization points in the communication protocol so that it doesn't impact framerate too drastically.
There's a trade off between making the process unnoticeable to a human (no meaningful slowdown) and how long it takes to start a song. I ultimately settled for medium slowdown, but so that you won't run half way across a map before a new song starts playing.
Now, there are of course limitations. If a sound needs to play, it cannot while a song is still being transfered, so a sound attempt during an asynchronous song transfer will cause the song loader to finish, locking the game up if necessary. Sounds include things like looping waterfall sounds, often played along with music on maps with waterfalls, so these areas will still have a hard pause when you enter. Some enemies make sounds as soon as you enter a map (snoring goblins, clapping embermen, knights, etc.), so they too can cause a song load to become synchronous, and then you get a basically vanilla-like pause. Normally, player running sounds would cause this synchronizing behavior as well, but I special cased those to be ignored (be silent) while a song is loading. Non-looping songs (victory music, got item music, cannon launch) are also played synchronously so that their timing with visuals is consistent.
And finally, there may be crazy bugs in this, and they would likely be real bad (freeze / hang). I tried to test all unique circumstances I could, but I need more eyeballs on this to shake out anything I missed. I also haven't tested with mixed MSU / SPC song behavior.
Memorex, thanks for those bug reports.
I don't think I've ever tried to sequence break in the imperial castle for whatever reason. I'm generally not against ignoring those types of issues as long as they don't prevent game completion, and can't be done accidentally, but I'll still go play with them and see how safe / unsafe it is.
Regarding the Pandoran Ruins, kethinov has made a
"No Glitching Into Pandora Ruins" hack, but I've not integrated it into Turbo yet.
Regarding the Tropics stove, that
might be a side effect of Quality_of_Life\Faster_Chest_Opening; the new animation added for chest opening might be affecting a stove animation. I need to go take a look. I'll fix it regardless, just mentioning in case anyone finds that info interesting.
hmsong, are the snake bosses' (and lich) deaths different than vanilla? I didn't think anything should be making those different than vanilla. As far as I recall when I checked in on the Great Viper, behavior was vanilla (even if arguably screwy there as well, but not dysfunctional), but I could be misremembering.
Hm, Bug_Fixes\Defeat_Waits_For_Events could be having some unexpected interaction? Needs confirmation that what occurs for those bosses is different than vanilla.