Actions

SCHG

Sonic Colors

From Sonic Retro

SCHG: Sonic Colors
Main Article

This is the Sonic Community Hacking Guide for the Wii version of Sonic Colors.
No, you can't mod-out the wisps. :)

Tools

BrawlBox

BrawlBox is an open-source tool written in C# that allows users to modify files of various formats (such as .arc, .brres, or .brstm) used in various Wii titles (primarily Super Smash Bros. Brawl, hence the name), one of which just-so-happens to be Sonic Colors.

This tool is incredibly useful for Sonic Colors modding - you'll be using it for modifying everything from models/materials/textures, to spline/gizmo data (as these are stored in .arc archives), etc.

File/Format specifications

NOTE: The following is largely based on the HedgeLib Wiki pages on Colors formats, which were also written by myself.
NOTE: This section is still a huge work-in-progress! If you have anything useful to add, please add it!

BINA

The BINA format is a generic container format used by various titles in the Sonic franchise, including Sonic the Hedgehog (2006 game) and Sonic Colors! Sega apparently liked it so much they even used a revised version later on in Sonic Lost World and Sonic Forces.

The format, in essence, is structured as follows:

  • BINA Header
  • Data (Entirely based on the type of data the file contains)
  • BINA String Table
  • BINA Offset Table
  • (Optional) BINA "Footer" (?)

Each of the above components are detailed below:

Header

(Example)

class Header
{
    uint FileSize;
    uint OffsetTableOffset; // The non-absolute (relative to the start of the Data) offset to the BINA Offset Table explained below.
    uint OffsetTableLength;
    uint Unknown1 = 0; // Appears to just be padding.
    
    ushort UnknownFlag1;
    
    // Whether or not the BINA "Footer Magic" is present.
    // Appears to be a boolean padded out to 2 bytes for some reason.
    ushort IsFooterMagicPresent; // Might also be "footer node" count?
    char[2] Unknown2 = "\0\0"; // Reserved values? They might've meant this to make the version number like "001"?
    char VersionNumber = '1';
    char EndianFlag; // "B" if the file is big-endian, "L" if the file is little-endian. In Colors it's always big-endian.
    char[4] BINASignature = "BINA";
    uint Padding = 0; // Unused as far as we know.
}

String tables

(Example)

A BINA string table is literally just an array of null-terminated strings - and that's it! The only other thing to know about them is that the last value in the array must be padded to a 0x4 offset.

Offset tables

(Example)

Offset tables are the most complicated part of the BINA format by far - so brace yourselves!
In concept, these are actually quite simple - essentially this is just an array of offsets which point to all of the other offsets contained in the BINA file.

However, in execution, they're a little trickier than that. A BINA offset table is an array of values relative to one-another which point to other offsets in the file, starting from the end of the BINA Header (0x20 for Colors files) and continuing by the value in each offset.

For example, if you had an offset at 0x28, followed by an offset at 0x2C, the BINA offset table's first two values would be 8, followed by 4, since you start at 0x20 and add 8 to get to the first offset, then add 4 to that to get to the second offset, and so on.

Got all that so far? Good, 'cuz unfortunately it gets even more complicated.
Each of the values in the BINA offset table are stored as 2 bits which represent how many bits make-up the value, followed by the actual value (which has been bit-shifted to the right by 2) in the said amount of bits.

The first 2 bits can be any of the following:

  • 00 (You've reached the end of the offset table, stop reading)
  • 01 (The next 6 bits in the file are the value)
  • 10 (The next 14 bits in the file are the value)
  • 11 (The next 30 bits in the file are the value)

SO with all of that in-mind, in the example linked above, the first two bits are "01", so, as indicated in the list above, this means the next 6 bits (000011, or "3") are the value of the offset! All that's left is to bit-shift it to the left by two to counter-act the value being bit-shifted to the right by two as mentioned above, making it 001100 (or "12"). Done! Just rinse and repeat until you reach the end of the offset table, adding each value you end up with to a value that starts at 0x20 as mentioned earlier. Keep in mind that the bit-shifting disallows certain lengths, since the last two bits are always 0.

Footer

The BINA Footer appears in the .orc files within the set folder. Hardly anything is known about it, including its purpose, though its basic structure seems to go as follows:

class Footer
{
    uint Unknown1 = 0x10;
    uint Unknown2 = 0; // Probably just padding.
    char[4] FooterMagic = "bvh\0";
}

.orc

The .orc extension is almost like this game's version of .bin; it's essentially just a generic extension the developers slapped onto the end of files when they were too lazy to think of an actual extension that matches the format. (I think it stands for "Object ResourCe"?)

As such, this section will detail each of the various formats that can be contained within .orc files individually.

SOBJ

The SOBJ format is used for defining object layout data (or "set data" as I'll be calling it from now on). As such, you'll rather fittingly find the .orc files which contain data in this format under the "cpk_root/sets" directory with names like "stg110_obj_00.orc".

Believe it or not, the files aren't just split into different .orc files per-stage for no reason - they're actually quite nicely organized! The numbers at the end of the filenames represent which "layer" the objects defined in that file should be placed on, with the possible layers being as follows:

  • 0 = Normal Layer - used for most objects.
  • 1 = "User" Layer - intended use unknown.
  • 2 = "User 0" Layer - intended use unknown.
  • 3 = "User 1" Layer - intended use unknown.
  • 4 = Gizmo Layer - used for stage-specific "gizmo" objects (benches in Tropical Resort, for example).
  • 5 = Design Layer - used for objects that enhance the level's appearance, such as particle setters.
  • 6 = Sound Layer - used for objects that trigger sounds.
  • 7 = Navigator Layer - used for objects that will only appear if the "navigator" was enabled when the save file currently being used was created (hint rings, for example).

The actual format works as follows:

// TODO: Add a specification for the SOBJ format

References


Sonic Community Hacking Guide
General
SonED2 Manual | Subroutine Equivalency List
Game-Specific
Sonic the Hedgehog (16-bit) | Sonic the Hedgehog (8-bit) | Sonic CD (prototype 510) | Sonic CD | Sonic CD (PC) | Sonic CD (2011) | Sonic 2 (Simon Wai prototype) | Sonic 2 (16-bit) | Sonic 2 (Master System) | Sonic 3 | Sonic 3 & Knuckles | Chaotix | Sonic Jam | Sonic Jam 6 | Sonic Adventure | Sonic Adventure DX: Director's Cut | Sonic Adventure DX: PC | Sonic Adventure (2010) | Sonic Adventure 2 | Sonic Adventure 2: Battle | Sonic Adventure 2 (PC) | Sonic Heroes | Sonic Riders | Sonic the Hedgehog (2006) | Sonic & Sega All-Stars Racing | Sonic Unleashed (Xbox 360/PS3) | Sonic Colours | Sonic Generations | Sonic Forces
Technical information
Sonic Eraser | Sonic 2 (Nick Arcade prototype) | Sonic CD (prototype; 1992-12-04) | Dr. Robotnik's Mean Bean Machine | Sonic Triple Trouble | Tails Adventures | Sonic Crackers | Sonic 3D: Flickies' Island | Sonic & Knuckles Collection | Sonic R | Sonic Shuffle | Sonic Advance | Sonic Advance 3 | Sonic Battle | Shadow the Hedgehog | Sonic Rush | Sonic Classic Collection | Sonic Free Riders | Sonic Lost World
Legacy Guides
The Nemesis Hacking Guides The Esrael Hacking Guides
ROM: Sonic 1 | Sonic 2 | Sonic 2 Beta | Sonic 3

Savestate: Sonic 1 | Sonic 2 Beta/Final | Sonic 3

Sonic 1 (English / Portuguese) | Sonic 2 Beta (English / Portuguese) | Sonic 2 and Knuckles (English / Portuguese)
Move to Sega Retro
Number Systems (or scrap) | Assembly Hacking Guide | 68000 Instruction Set | 68000 ASM-to-Hex Code Reference | SMPS Music Hacking Guide | Mega Drive technical information