Actions

SCHG How-to Talk

Port Sonic 3's Sound Driver to Sonic 2

From Sonic Retro

Revision as of 16:41, 30 May 2014 by RetroUser (talk | contribs) (Wait, I'm wiping this out, since obviously I had accidentally cut myself off in the middle of a sentence, and it doesn't really belong here. *rolleyes*)

Yikes! Most of the guide's page-space being Sonic 2 code that we're directed to replace, what? Pre-assembled Z80 code in an AS macro assembler disassembly, the hell? "Optimised" SoundDriverLoad that isn't even as optimised as to break from the S3 norm and use Kosinski-compressed driver data, why? Hardcoded equates, huh? Outright instructing one to delete art BINCLUDEs and replace them instead of just detailing how to relocate them, ...? SMPS is intellectual property, *shrug*?

Call me spoiled, but [1] seems so much less hackish. Even if it uses a modified S&K driver, the use of a disassembled driver looks to make things so much easier, and that guide better fits the 'Sonic Team way' philosophy of the S1 guide, I can certainly tell you that S3 doesn't handle tempo-changing that way, having an exception programmed into PlayMusic. Clownacy 14:54, 25 May 2014 (UTC)

Hm, I think I agree, as I've tried out that driver, I like it, and it's not so arbitrary in the area of what music you can have. Trust me, I've ported Sonic 3's driver to Sonic 1, and I think that working with the music when using that driver can be a real pain. I mean, most of the time, porting music from Sonic 3D works without much work (mostly because it uses pretty much the same driver), but I HATE Sonic 3's way of sorting music, because you port a song, and your other songs turn into nothing but garbled trash. I'm pretty sure this happens because of Sonic 3's system of address pointers. -- RetroUser 17:21, 25 May 2014 (UTC)
Yeah, relative pointing, relative to the start of the sound bank, moving music around inside a bank will misalign them. That should also be a problem with Sonic 2's driver. Things like SMPS2ASM have the assembler fix the addresses for you on every build. Such logic also applys to the driver code. The branches themselves are pre-assembled, so if you tried adding code, you'd break them. Multiple bugs and redundancies have been found in the S&K driver code, and trying to apply the fixes to this would either be a huge pain, as you'd have to change multiple branches, or downright not possible for the user to do. Anyhow, I see a lot of changes on the Recent Changes page so I'll see what's new. Clownacy 14:38, 26 May 2014 (UTC)