While Sonic disassemblies have, historically, been contained in a single ASM file (sometimes with a few smaller files for constants, macros, and the sound driver), this isn't a particularly good practice. Sonic 3 is the biggest offender of this, as sonic3k.asm has ~200,000 lines of assembly, making it a nightmare to find routines. Ideally, the code would be split into multiple smaller files.
The major problem with attempting a code-split is that a number of routines and objects had their code altered in Sonic & Knuckles, mainly adding in bug fixes or Sonic (3) & Knuckles-specific behavior. Additionally, since just about all code got shifted around, there is always the chance that address-based labels for separate routines could by identical.
There are a few possible solutions to this:
- Create separate ASM files for Sonic 3 and Sonic & Knuckles routines. This would prevent possible collisions between address-based labels (and be the cleanest in terms of 'content within files'), but would quickly bloat the disassembly since every routine got shifted around.
- Create a build flag to swap between Sonic 3 and Sonic & Knuckles code. While this could potentially get messy internally (and address-based labels would still be a problem), it would not suffer from the bloat problem.
- Split Sonic 3 and Sonic & Knuckles into different branches, similar to how Knuckles in Sonic 2 is handled.
While Sonic disassemblies have, historically, been contained in a single ASM file (sometimes with a few smaller files for constants, macros, and the sound driver), this isn't a particularly good practice. Sonic 3 is the biggest offender of this, as
sonic3k.asmhas ~200,000 lines of assembly, making it a nightmare to find routines. Ideally, the code would be split into multiple smaller files.The major problem with attempting a code-split is that a number of routines and objects had their code altered in Sonic & Knuckles, mainly adding in bug fixes or Sonic (3) & Knuckles-specific behavior. Additionally, since just about all code got shifted around, there is always the chance that address-based labels for separate routines could by identical.
There are a few possible solutions to this: