SCHG How-to Talk:Port Sonic 3's Sound Driver to Sonic 2

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)

Okay, this may seem out of place, but how do you get music ASM'd with SMPS2ASM to work with Sonic 1? Do you have to do more than simply including the _smps2asm_inc.asm file? Because when I do that, I get nothing but errors. The reason I brought this up here is because using SMPS2ASM stuff with these driver imports should certainly make life easier, but I tried Yeah, and I think that SMPS2ASM does go easy with those pointers because...I put Flamewing's S&K driver that's included with the tool into the GitHub Sonic 3K Disasm, I've been using all sorts of ASM'd music that came with the awesome ASM music archive, and I haven't gotten any garbled music...I agree with you about the whole problem with note-holding that the driver has, though, as I've heard it too. EDIT: Okay, about the smps2asm issue with Sonic 1, including the _smps2asm_inc.asm file seems to work with my S3 driver port disasm for S1, but I still get errors when including an asm music file. I wonder why... -- RetroUser 15:02, 26 May 2014 (UTC)