CHRONO CROSS FILE EXPLORATION THREAD

[ZeaLitY]

Something ominous...the videos produced by Yazoo's tools seem to cut out one second before they should. For instance, in the Dragon Tear scene, the Time Crash explosion doesn't reach its full breadth before the video stops.

Can anyone extract the videos with Nemesis's tools and see if this also happens?

Because...it might just be PSXTulz. But I don't really have a standard of comparison here.

[FaustWolf]

I can squeeze in a few minutes to investigate. Which video is the dragon tear scene again?

[ZeaLitY]

5605.

[FaustWolf]

I wouldn't worry about it. #5605 checks out when I do a hex comparison between the 600+MB iso and the ripped .OUT file. It's exactly what's in the CD image; same file length and same content too, judging from a few offsets sampled at random.

My PSXMediaPlayer doesn't seem to have a functional "scan file" feature; if it did, I'd sic it on the .OUT file and we'd be able to tell for sure. But for now, I'd ascribe the fault to PSXTulz and not Yazoo's tools.

[FaustWolf]

I'll not be around for the next few days, but I wanted to attach some potentially new stuff I received from Sephiroth 1311 at sadnescity.it. Zeality, you should already have these I think.

Contained within is a version of roomdecompress2 source code, written in C++ (the version Ramsus compiled previously was written in plain C, contrary to any false indications I gave before due to my lack of programming knowledge). There's also an alternate roomdecompress.exe that goes up to room 536 before it quits. It's possible that roomdecompress.exe was compiled from roomdecompress2.cpp, but I'm unsure.

With so many different versions of stuff floating around now, perhaps I can sift through everything when I get back and make a list of a.) what's out there and b.) what works best.

[attachment deleted by admin]

[Ramsus]

I'll not be around for the next few days, but I wanted to attach some potentially new stuff I received from Sephiroth 1311 at sadnescity.it. Zeality, you should already have these I think.

Contained within is a version of roomdecompress2 source code, written in C++ (the version Ramsus compiled previously was written in plain C, contrary to any false indications I gave before due to my lack of programming knowledge). There's also an alternate roomdecompress.exe that goes up to room 536 before it quits. It's possible that roomdecompress.exe was compiled from roomdecompress2.cpp, but I'm unsure.

With so many different versions of stuff floating around now, perhaps I can sift through everything when I get back and make a list of a.) what's out there and b.) what works best.

Don't get your hopes up too much. It's the same exact source. It's the same exact file. And it's still really just C. In fact, every "version" of it I've seen is exactly the same.

So far I've only seen two different programs/groups of source code. The Yazoo/chronotools stuff, which is all exactly the same, and the Terminus Traduction tool, which was posted both as isolated source code and as part of some big Chrono Cross translation tools package.

Also, the other roomdecompress.exe was probably just built with a different compiler, which is why it behaves slightly differently. However, the program is hardcoded to only go up to 536, so if it's not crashing at the end, then it's running properly.

That my version crashes early suggests that there's a bug that only appears when the code is built with certain compilers (i.e. there's a real bug, but under the right conditions nothing happens because of it), but I haven't tried reproducing the crash under a debugger yet.

[Ramsus]

Also, here's why it's only going up to "Room" 536. There's out files 0356.out to 1966.out. That's 1310 .out files. However, they come in groups of three per room, so 0356.out is the files that get dumped into the room's "code" file, 0357.out is what goes in the "unknown" folder, and 0358.out is what goes into the "GFX" folder. Then it repeats with the next three. 0359 is code, 0360 is unknown, and 0361 is GFX.

So don't freak out that it's not going past "Room" 536, because that's all there is apparently.

[FaustWolf]

Thanks again, Ramsus. That clears lots of things up for me. Strangely, it appears we've picked up about 1MB of data with the roomdecompress.exe (approx. 214MB for the folders as opposed to approx 213MB for the raw .OUT files in the Rooms\ directory). I'm not sure why that would be; perhaps one of the filetypes contained within the .OUTs was decompressed? I should be able to figure that out on my own when I get a chance to do some in-depth hex viewing.

[ZeaLitY]

This started as a PM to FaustWolf, but it's too important:

Radical_R recalls seeing a note on Gamefaqs long ago suggesting that the Hydra Marshes location I found really is a bona fide debug room. What perplexes me about this is that it seems wiser to have that debug menu available to every location and not just that room, since it contains commands for modifying model sizes.

But the real implication here is that the debug menu's internal map selector and the Gameshark room modifier code may be mutually exclusively ("maps" versus "rooms"). I'm not really buying it, because up to what I've done so far, the maps match (although the room modifier crashes more than the map selector). What I can't figure out is how Nemesis numbered his rooms in the script...

~

Disregard all that. They match up. Nemesis starts 001 at the title / ending screens, which is like 009 or something with Cross's internal selector. Let's get down to inquiries:

• There are two distinct script files. One is smaller, and contains what I'm guessing Nemesis pegged as scenes or something? The entire Dead Sea is in there, and other stuff, but there are also "scenes" (you know, as opposed to normal places with NPCs) in the other, bigger script file. Why the division? I guess I could e-mail Nemesis.
• Why would the room modifier code take me to an empty Hydra Marshes with a debug menu and the map selector take me to a version with loaded NPCs intended for the demo scene (its true purpose)? I guess more than just "room X" instructions are sent when Cross loads a map. That explains why what should be the title screen in the room modifier code digits crashes, while the corresponding map select digit actually loads the titles. Still, it irks me that there's a strange difference here...

[Ramsus]

Thanks again, Ramsus. That clears lots of things up for me. Strangely, it appears we've picked up about 1MB of data with the roomdecompress.exe (approx. 214MB for the folders as opposed to approx 213MB for the raw .OUT files in the Rooms\ directory). I'm not sure why that would be; perhaps one of the filetypes contained within the .OUTs was decompressed? I should be able to figure that out on my own when I get a chance to do some in-depth hex viewing.

If you're comparing file sizes, remember that the room file extractor doesn't just split up the files and output them. It also generates all the ACT files from the CLUT information from the 1palette files. You have to delete all of those before you try doing any file size comparison, because they aren't part of the original data.

Other than that though, the program isn't generating any new data or modifying anything other than the palettes. So trust me, there's no decompression going on.

[FaustWolf]

It also generates all the ACT files from the CLUT information from the 1palette files.

That'll do it. Makes perfect sense now.

Darnit, I need to get some time to take a look at all this debug room stuff! Zeality, is there any kind of function in there that lets you see dungeon/in-battle character models for all the characters and enemies?

[ZeaLitY]

Nah, just lets you change model size or something. And since the location I got the debug room menu in didn't load any models, I couldn't really test it out.

So, once we get Yazoo's output mapped, we can rip the assets?

[FaustWolf]

Yeah, I imagine we can just rip anything Yazoo's tools aren't giving us with a hex editor (someone let me know if I'm wrong on that - I think a simple copy+paste of the raw data should do, though viewing will be slightly problematic until we can figure out what format the missing files are in). I think only 5MB or so is missing from the Yazoo tools dumps when compared with the 600+MB iso image. It's entirely possible that we've already got everything and that the "missing" 5Mb is just filler 00 bytes - essentially buffers between files that Yazoo's tools avoid.

Mapping the output of the Ramsus/Yazoo dumper looks fairly easy so far. Hopefully I can add the dumped directory starting & ending offsets to the wiki this weekend. Only the MISC folder will prove problematic, as I'm not sure that stuff's arranged in game CD order.

[ZeaLitY]

I've checked out folder BF, which has files containing all the battle field TIMs. I extracted the TIMs from a sample and compared file sizes, and there's definitely something other than textures in there. I mean, that's obvious, of course, but...

Anyway, I've searched the TIMs inside the sample OUT and removed them. Before each TIM is some kind of label. Bah, I accidentally did something I didn't want to...I'll have to resume tomorrow.

We can probably make some kind of qualitative judgment based on these tags. They include stuff like "deg", "degu", "gk"...and they each preface a few TIM files in sequence. In fact, all the textures are lined up in one part of the file.

[FaustWolf]

Ooh, good find Zeality! Maybe the other data is battlefield model data, perhaps.

Can you describe the label that precedes the TIMs in the BF directory? I'm seeing a <...h label in ASCII just before the battle model textures located in MISC\OUTs 3055-3707.

I'm going to link to some suspected battle model data here and at Qhimm once I get it isolated, which will occur sometime this week. Within the range of the CD image that corresponds to MISC\OUTs 3055-3707, I've stumbled upon an area that's structured as follows:

Character Battle Texture <---> Character Weapon 1 Texture <---> Character Weapon 2 Texture...

Where the "<--->" is unknown data sandwiched between the textures. Might be models, hopefully. Perhaps the BF OUTs are structured in a similar fashion?