Sonic Rush BAC format

The format was actually cracked as part of a collaborative effort between myself, Lightning, and Justin Aquadero (AKA Retriever II, admin of MFGG, cracked the formats used in Paper Mario and Paper Mario: The Thousand Year Door). Justin did a lot of the technical legwork, and asked me to post his findings on his behalf here.

Some info about dimensions: "I finally figured the bugger out. It doesn't use conventional dimentions. Instead it has a hotspot, and negative/positive offsets from that hotspot to define the frame edges. Images also can be broken into multiple parts (as a clever way of not storing excessive empty space). These parts are placed on the frame according to a coordinate offset from the left and top frame edges. I believe dimentions of these parts are derived from their placement on the frame and with each other, because I can't find anything else specific to image parts that I could pass off as either a width or height. I've also managed to flesh out a few other parts.

I'm providing my "study" file which has dac_animal01.bac and ene_falco.bac's blocks 1-4 laid out in an easily understandable format. Great for analysis. It's possible in some of the monster files my theories will fall apart, but it's still a step closer."

BAC Format specs
Study file

Discuss.

 

See my avatar. It's ripped directly from the Sonic Rush ROM, from the BAC format.

 

Yep, good ol' Egg Pawn. =]

 

Not yet. There is a duplicate file for springs (ac_gmk_bane and ac_gmk_spring) but anyone can see that.

Also, word to the wise: some data is LZSS compressed. Use gbalzss to get some results. To tell if the frame is LZSS compressed, check the start of the data block:
00 = Uncompressed (raw)
10 = Compressed (LZSS)

 

FYI, the spec sheet was updated to be more organized, and...
"I had a revelation looking at Block 3. I havn't confirmed it, but I think all the unknown values are ID/length pairs, and that all the useful data in Block 3 is actually a collection of smaller modules. These smaller modules are what allow multiple image parts to be present, and for those unknown bits with negative values to be present. This provides a crystal clear explaination of how those unknown parts can be present sometimes and absent other times, without throwing any calculations off. However, this is still just an educated guess on my part. I've updated the spec to reflect it anyhow, with a note."
BAC Format Specs

 

Got another update on the format from Justin:
"I went though about 70% of the files and they all fit that ID/sub-module theory like a glove. In a couple files which I made note of, some of the palette or data regions were missing, which just reinforces that theory. I didn't find any other sub-module types, although they probably do exist in sega's specs.

I have a possible guess as to what mysterious "region 07" is that appears in some files. It might define alternate boundaries on the image, possibly for purposes of collision masking or detection. I've seen anywhere from 1 to 3 07 regions appear in a single frame. Since the negative words followed by the possitive words closely resembles the frame construction in the next box, I think they may very well be coordinates relative to the hotspot. If that's the case, that just leaves one unknown dword before the coordinates, which I marked as index for now, and it may actually be IDs that could be used to reference the alternate boundaries/masks/whatever.

Which means I'm done playing with Block 3."