CHRONO CROSS FILE EXPLORATION THREAD

[halkun]

Keep in mind, there isn't a steadfast rule that the opcodes will even be there. they happened to be in FF8. They might just be another vertex list. FF8 used both quads and triangles and the opcodes were  needed because 1) they flagged a difference between the following data. 2) it was one less byte they had to "prep" for the GPU.

If they went all quads or triangles, then the number of vetexes will be assumed.

[Luminaire85]

Note that Guile's section 1 subheader starts with the value 0x00000005 instead of 0x00000002 like Serge and Kid. If you read five 32-bit sections after that point in Guile's subheader, you reach the same sort of data as when you read two 32-bit sections after that point in Serge's and Kid's subheaders. So I think the subheader format is still consistent, but as yet don't know what the extra three numbers in Guile's subheader refer to.

[FaustWolf]

Halkun and Luminaire, thanks again!

As long as we're able to decode the file format bit by bit (literally, as we seem to be doing with the headers now ), I guess I won't worry about the GPU opcodes for the time being. If I'm unable to find them, perhaps the model format used in Cross really is significantly different than that used in FF8.

Luminaire, I see the subheader pattern now! The very beginning 4-byte set is sort of like a pointer itself, and tells where a certain section of data begins.

So in Serge's subheader, there are 2 4-byte sections between the first subheader section and what I like to call the "gobbledegook section", i.e., one that doesn't make any sense to me (yet). In Serge's subheader, that "gobbledegook section" reads 0x042B0205. Likewise, in Kid's subheader there's 2 4-byte sections between the beginning and the section that reads 0x040701D9. In Guile's, however, there are 5 4-byte sections filling the space between the subheader beginning and 0x049A034B.

The "gobbledegook sections" all seem to be similar in a way. Their values (in decimal notation) are:

Serge: 69,927,429
Kid: 67,568,089
Guile: 77,202,251

The fact that they're odd numbers is confounding; if they were divisible by 8, they might contain info on the number of vertices or something.

But the 0x02 and 0x05 don't point directly to the Gobbledegook Section; they point to the sections that read "0x0280" in Serge's subheader, "0x0238" in Kid's, and "0x025C" in Guile's. Is that what you had in mind, Luminaire?

Oh! And the second section of the subheader is a relative offset to the pointer table! In Serge's subheader, the pointer table begins at offset 34 (14+20), it's the same with Kid, and Guile's starts at offset 40 (20+20)!

If we can all agree on these observations, I'll add them to my map on the previous page. Our combined efforts are making this process go very smoothly! Thanks again everyone!!

Our analysis of the CC battle model format will be eventually be compiled into a page on the Compendium Encyclopedia no doubt. Halkun and Cyb, would Qhimm like this info too for the wiki over there?

As for next steps...

The section to which the 0x02 and 0x05 point could constitute a relative offset to some type of data further on in the first section. I wonder what? Could there be even more subsections hiding in the first section?

Once we determine the total number of subsections, I'll mess with them one by one so we can make observations on the type of data affected with visual Youtube evidence.

[Luminaire85]

I think the 0x02 and 0x05 represent the number of 32-bit sequences to read before you will get to the "gobbledygook" 32-bit section.

I am wondering if that "gobbledygook" is meant to be read as two 16-bit values or four 8-bit values or some combination of those. The values that result don't have immediate significance to me, but maybe they will later.

I have had no luck finding the opcodes either.

[FaustWolf]

Okay, thanks Luminaire. Yes, I think the "Gobbledegook Sections" may have to be split to make sense of them. I'm updating my subheader anatomy map to reflect the knowledge we've gained today, then I'll get back to trial-and-error experimentation with each subsection over the coming days. I still worry that the first subsection may in fact be several subsections, and if that turns out to be the case, I'll go back and mess with those individually.

[Luminaire85]

Is this where we stand on the structure of the first section? I'm using offsets from the very beginning of the model data, and specifically for the Serge battle model for now:

Range	Length (bytes)	Contents
0x0020-0x0047	40	Header - two pointer tables separated by "gobbledygook"
0x0048-0x029F	600	Unknown
0x02A0-0x0357	184	Unknown
0x0358-0x28E7	9616	Unknown
0x28E8-0x4247	6496	Possibly vertex data
0x4248-0x4EF7	3248	Unknown - pattern is xx yy zz 00

I'm not sure yet that 0x0228 represents a break between sections - it's hard to see a difference in the hex code around that point. Also, I had the thought that the 0x4248-0x4EF7 section could be some sort of color data, only because 8 bits each for red, green, and blue and 8 bits of buffer fits with the pattern and since there are 812 such points and 812 vertices. Just a random thought though.

Would it be worthwhile to be keeping track of our current map of the battle model format on a Compendium encyclopedia page? I would certainly be willing to help update it as we figure things out.

EDIT: Arg, looks like I've been looking at hex code too long. Fixed an error.

[FaustWolf]

The header ending at 0x0047 looks good. I'll re-up Guile's header with an extra row in my previous map post based on that observation, because that'll push the end of his subheader into the 0x50 range.

Nothing wrong with starting an encyclopedia page at this point -- it would help to have something stationary we could access and alter easily. Our maps keep getting lost as we continue posting away. I'll see if I can get a page going this weekend. Do you have access to the wiki creation area, Luminaire? If not, PM Zeality and he can probably get you set up.

The color idea for 0x4248~0x4EF7 is a better theory than anything I've come up with. I wonder if it has to do with shading of the model? In any case, I can easily test the color theory by overwriting that section of Serge's data with another character's.

[Cyberman]

Just in case you folks are utterly bored (not likely but .. hey). The weapon models in FF7 apparently are separate. They have a separate set of animation.  They are just lumped together with the battle model.  It's likely CC does the same thing (as it would be annoying to load each separately along with a single set of animations).
I'll point you to someplace things will be explained perhaps more clearly.  Go here to read. Erstwhile if the weapons are separate, it's not likely they created new animations for each weapon (that would be insanely expensive to do).  So some of what you folks might be calling junk might be useful information.  Namely you might want to find the EXACT number of battle models and look for that number inside the header.
An aside animations are SMALL chunks of data if they are deltas (likely) the format used in FF7 is a bit complicated.  In any case the animations are likely compressed (as they consume a lot of space otherwise). So look for a list of pointers to data that has short increments (IE 8 to 500 bytes), and a lot of them as well.  These are likely your battle animations. The weapon likely has it's own set of animations as well. So it's very likely there is a large set of animations for those as well (they apply to all weapons more than likely).

Cyb

[justin3009]

I've been waiting for them to kinda mess with that.  It'd be kinda funny to see serge doing a Swallow stance for daggers >_>..

[FaustWolf]

Updates will begin to flow forth once we've got the Encyclopedia entry for Chrono Cross battle models up; check the CC File Structure Page tomorrow for that. I'll link when it's ready for those who haven't seen the various file structure maps Luminaire and I have buried throughout this thread.

Thanks for the weapon model animation tips, Cyb! I'm going to be messing with character battle model data subsection-by-subsection over the next few weeks probably, so that should help us determine where the weapon animations are stored. I do know how many weapons each character has, so I'll keep on the lookout for header values that correspond to those numbers.

[ZeaLitY]

I was poking around the outputted Nemesis data while checking to see if the debug menu text is in the scripts today and found the rooms folder. Not that it matters, but as expected, there are three files per room: two CPT files (images, script) and one DRP file ('other').

At any rate, we have Nemesis's real e-mail, so his schedule providing we can ask him some short questions if needed.

Anyway, looks like the debug menu text doesn't get dumped, which may have interesting ramifications for this entire debug thing.

[FaustWolf]

WOW Zeality, you figured out how to use Nemesis' tools successfully? DAMN my effort to formulate a months-early Xenogears April Fools joke, I should have been spending my ounce of free time at the Compendium! Can you fill us in on how you got Nemesis' utilities to work?

[ZeaLitY]

Oh jeez, I'm having a hard time remembering, and I can't exactly try again right now. But it's important to remember that Nemesis's tools don't dump the rest of the assets. I guess they dump the rooms in case translators need to change graphical text. So we're still better with Yazoo's for the 3D.

\CD1\10_Image_Avant

I stuck the ISO in there and named it CC_CD1.iso. Then I opened Chrono_Cross.exe and executed "Dump_Main". I think that's it. Naming CC_CD1.iso was the only iffy part, and Sephiroth gave me the correct file name.

[FaustWolf]

Aha, thanks Zeality. I'll try again with Nemesis' utility later, since I'm intensely interested in the LZSS decompress function it contains IIRC. I wonder which files are compressed?

And getting away from model data for a second, do you happen to know which OUT files contain game script (as in dialogue) data? That'll be crucially important for text hacks, and I suspect the dialogue and accent files are compressed since I'm not seeing a hint of game text in the ASCII section of my hex viewer.

[ZeaLitY]

If the room thing under Nemesis's structure is right (as in, if it uses Yazoo's basic setup), then the first of each set of three OUT files per room (compressed) should contain it.

Uncompressed, it looks like 8script is it under the \code folder.

I opened up a command line and ran the script-dec program in Yazoo's tools. Now, a bunch of new files have appeared in the \code folder, including "outscript.txt", which apparently contains the final result. Yep, and there's the dialogue. But would you look at that...the debug menu text is in EVERY location! I guess Nemesis's tool automatically nullifies it since it's so redundant. But hey, this is great, since it confirms that the debug menu is independent of the map I accidentally found it on.

Who knows what the script's compression type is, though? It's probably in Nemesis's user guide for his tools. Sephiroth can probably even tell us right off.

As a byproduct of this research into the mapping system, I can now deduce the location of the unplaced text in the Chrono Cross script. That'll be a great coup for the Compendium.