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, from Sonic the Hedgehog (2006 game), to Sonic and the Secret Rings, to Sonic and the Black Knight, all the way up to Sonic Colors! Sega apparently liked it so much they even used it later on in titles that came after Colors, such as in Sonic Lost World!

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 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 be 2 bytes for some reason.
	ushort isFooterMagicPresent;
	char[4] headerMagic = "\0\01B"; // I'm assuming the "1B" at the end is the version number and big/little endian flag?
	char[4] BINASignature = "BINA";
	uint unknown2 = 0; // Possibly a length for how much "additional data" there should be after the header?
}

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.

Footer

Hardly anything is known about the BINA footer - though it's 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.

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
Sonic Community Hacking Guide
General
Sonic Music Hacking Guide | SonED2 Manual
Game-Specific
Sonic the Hedgehog (16-bit) | Sonic the Hedgehog (8-bit) | Sonic Eraser | Sonic CD (prototype 510) | Sonic CD | Sonic CD (PC) | Sonic CD (2011) | Sonic 2 (Nick Arcade prototype) | Sonic 2 (Simon Wai prototype) | Sonic 2 (16-bit) | Sonic 2 (8-bit) | Sonic 2 & Knuckles | Dr. Robotnik's Mean Bean Machine | Sonic Triple Trouble | Sonic 3 | Sonic & Knuckles | Sonic 3 & Knuckles | Sonic & Knuckles Collection | Sonic Crackers | Sonic 3D: Flickies' Island | Chaotix | Sonic R PC | Sonic Jam 6 | Sonic Advance | Sonic Advance 2 | Sonic Advance 3 | Sonic Battle | 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 | Shadow the Hedgehog | Sonic Riders | Sonic the Hedgehog (2006) | Sonic & Sega All-Stars Racing | Sonic Unleashed (Xbox 360/PS3) | Sonic Generations
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 | Subroutine Equivalency List | 68000 Instruction Set | 68000 ASM-to-Hex Code Reference | VDP Documentation | Official Sega 32X Documentation | Official Mega-CD Documentation | Official Sega Mega Drive Documentation