Chrono Cross exploration & file structure

  • Thread starter Thread starter ZeaLitY
  • Start date Start date
Status
Not open for further replies.
Ah, the Compendium is quickly migrating over here.

Yeah, it'd be interesting to get a hold of Yazoo and find out how he processed the original TOC/index file. Is this sort of dumper possible for every game CD, provided you know how to tailor the code to each game's individual file structure, I wonder?
 
The trick now is going to be getting these utilities to work:

http://chronofan.com/Black/Other/Chrono_Cross_-_Translation_tools.zip

They're Terminus Traduction's final set of utilities; most of the basic foundation was what Yazoo did in his CCTools.
Click to expand...
Honestly, if I had known about those, I would've saved myself the trouble of even looking at the source code of the previous program. It seems like all the work there is pretty much done, and all that's left is reading the instructions.

Now you guys can start looking for the model files and figuring out what format they're in.
 
The models are most likely going to be in a binary form of RSD/HRC. The same as FF7, because that was the native format used by Psy-Q
 
Halkun, I'm now aware of the following Qhimm wiki entries on RSD and HRC format:

http://wiki.qhimm.com/PSX/RSD
http://wiki.qhimm.com/PSX/HRC

Do you happen to know offhand if there's any more info on these formats, and do you have any tips on what these formats would look like in hexadecimal? Would they have a consistent file header, you think?

@Ramsus & Zeality: Whoa! I could have sworn I came across Yazoo's Translation Tools on the Compendium earlier, but I think they were uncompiled. These look great! Anyone know whether they should be run on the entire disc image or on the .OUT files instead? I'll try both.
 
The models are most likely going to be in a binary form of RSD/HRC. The same as FF7, because that was the native format used by Psy-Q
Click to expand...
FFVII and XENO format are not in RSD or HRC but in compiled format that almost ready to be sent to GPU. So it's better to read documentation about PSOne than RSD/RHC specification.
 
The models are most likely going to be in a binary form of RSD/HRC. The same as FF7, because that was the native format used by Psy-Q
Click to expand...
FFVII and XENO format are not in RSD or HRC but in compiled format that almost ready to be sent to GPU. So it's better to read documentation about PSOne than RSD/RHC specification.
Click to expand...
I believe that was what halkun meant by saying "binary".
 
Ironically I know a bit about the CC save state format.
However my time is still a bit stretched these days.
If you are going to keep the information you find public this is one of the games I wanted to migrate to Q-gears.
As I thought a fair bit of this stuff was available, I could be wrong.
I thought Chrono Cross was released about the same time as FF9?

Cyb
 
Thanx Halkun!

Yeah Cyb, FF9 and CC were both released in 2000 in the US. Maybe that means model formats and various other aspects of the games will be similar?

Not to get off topic, but how is Qhimm's FF9Viewer coming along? It's not available for download yet, is it? It looks to me that CC and FF9 game resources are pretty compatible from an aesthetic standpoint. I'm starting to get wild ideas. :evil:

Everything we're discovering over at the Compendium is publicly viewable, I think. It's just a matter of gathering all the utilities and notes into a single place, which is no small task now.

EDIT: We've freshly acquired battle model textures and files that *may* be main character battle models. I'm linking to a sample of three character data folders. The "5" files are definitely battle model textures, and there's eyeball TIMs in these folders as well. But what I'm really interested in are the "3" files. Can anyone give me an opinion as to whether there's model data in the "3"s?

http://rapidshare.com/files/64618291/MainCharFiles.rar.rar.html
 
Last edited:
Well the backgrounds used 16bit palletized TIMS that were loaded into the right section of the display memory (IE 320x240 == 16bit display leaving 704x 240 pixels to the right of the display to hold the background data in). The background format however is kind of unknown as I didn't get too far with it. However it looks like instead of the complicated system they used for FF7 they just stored the palettes and the background information (8bpp likely) all together and used quads to dump the background information to the display. I think they used the transparency bit for some of the transparent/walk behind parts of the palletized background.  However the backgrounds were pretty much one BIG TIM.

Cyb
 
When you say "background," Cyb, what do you mean exactly? I'm thinking pre-rendered backgrounds, that's not what you're referring to, is it?
 
When you say "background," Cyb, what do you mean exactly? I'm thinking pre-rendered backgrounds, that's not what you're referring to, is it?
Click to expand...
2D backgrounds is picture that you can see when looking at field. It tiled with 16x16 or 32x32 tiles. It depends on layer in FFVII. Data format of backgrounds in ffvii are like SPRITE packet to GPU without header. And there are 4 layers of background. 1 - always rendered at the bottlom, 2 - each tile has it's own depth (distance from screen) for correct sorting, 3 and 4 are dynamic layers that managing through script.

Look at http://q-gears.svn.sourceforge.net/...ii/field/DatFile.cpp?revision=177&view=markup for GetBackground().
 
Thanks Akari. Is QGears intended to dump files from games eventually, or is it an engine that plays the games from the disc?

And we've opened the files in the "rooms" directory finally at the Compendium. There's data in these that I'm told is 3D, which might be your walkmeshes - though I'm still not sure how to determine which files belong to which fields/dungeons/etc. in-game yet.
 
Last edited:
Pre rendered backgrounds indeed was what I was referring too. :D
Maybe I should add TCL or python scripting to my PS1 ISO viewer to make it easy to make data viewers for various games quickly.
The interesting thing about said idea is that even though each game has unique data access attributes and unique structures etc. They all use the same hardware.
I was perusing my Medievil game and noticed that this game had similar uses of data as all the other games.
If one is going to do TCL or python or any script engine to render content from games, the end method of rendering the data is mostly similar so such a methodology is not a waste of time.

3d data should be in several sets IE vertex pools (sets of 3d data ) etc. They are likely ALL 32bit aligned (3 vertices's and one dummy 16bit signed for example).  Keep this in mind and the format will be easier to decipher.  If you looked at the FF7 battle format information (I think I put most of that in, it's been a while), you'll notice the structures follow this explicitly.  Since a walk mesh for example is not visible 3d data but more a collision surface (IE gravity collision) it will be arranged whatever is convenient for the GTE to process and not the GPU. My guess is whatever arrangement was most convenient.

Q-gears is to play the data from the games.  Since the versions for the PC of FF7 and FF8 are buggy and are difficult to get to work on said platforms, and playing FF9 xenogears Vagrant Story etc. require an emulator.  This is a good alternative, as content distribution is verboten (IE textures and stuff being ripped from the game) it is a good idea to keep this in mind. As I've noticed a lot of people getting C&D'd projects because of this.  Lawyers will follow if you distribute anything that is from a copyrighted work.

As for enhancements that has been a difficult thing to contemplate.  As to remain legally safe it can only be done in vitro. New background content could be a problem.  Of course there is duke nukem 3d (eduke) with the 3d models instead of sprites.  I think it's possible to make a method to facilitate the content but not distribute it with Q-gears (as this might bring up trademark and copyright issues again).

Cyb
 
Quick and silly question for you Cyb, or anyone else who can answer - is the PSX battle model format wiki describing what the data looks like when it's uncompressed? Meaning I'd have to take suspected model data from Chrono Cross and run it through an LZS decompressor (assuming that's the compression scheme CC uses, of course) to be able to compare to what's in the wiki?

http://wiki.qhimm.com/FF7/Battle_model_format_(PSX)
 
Last edited:
Quick and silly question for you Cyb, or anyone else who can answer - is the PSX battle model format wiki describing what the data looks like when it's uncompressed? Meaning I'd have to take suspected model data from Chrono Cross and run it through an LZS decompressor (assuming that's the compression scheme CC uses, of course) to be able to compare to what's in the wiki?

http://wiki.qhimm.com/FF7/Battle_model_format_(PSX)
Click to expand...
The FF7 model data is compressed as a complete set. However I believe CC is uncompressed data.  It is likely similar to FF9's model format. You should look for a SECTOR that contains a TIM unaligned to the sector boundry. That will be a clue that it's either background data or model data. If you inspect the TIM and it appears to be skin data then THAT is your model.  In FF8 there was an 128 byte header and then a TIM or two. FF9 is similar. Although I don't know the specifics for the FF9 model data.

Cyb
 
Ah, THANK YOU once again Cyb. So the character model textures are typically stored right along with the models then? I'm currently mining for model data in a section of the CD image that contains the character battle model textures, weapon model textures, and unknown data sandwiched in between that I suspect might be character and weapon models.

When you speak of TIM textures unaligned with the sector boundary, you mean that the TIM begins at some point after a new sector, correct? Would 00 "buffer" bytes fill the space in between the sector start and the TIM then? And are we talking about 2048-byte sectors or 2352-byte sectors? I'm working with a CD image that has 2048 bytes per sector I think; not sure if that changes things any.

And I know now that sound data is certainly stored similarly in FF9 and Chrono Cross as well (both sound file formats start with AKAO in ASCII). I'm starting to wonder just how closely the file formats in Chrono Cross resemble those in FF9. Is it possible that Qhimm's FF9Viewer program would be able to detect Chrono Cross data as well?

EDIT: By the way, I don't think I've mentioned it above, but Ramsus and Zeality figured out Chrono Cross' pre-rendered background format (at least as it pertains to the visible 2D stuff) over at the Compendium. There's not much documentation on it yet, but I can relay what we know so far here if anyone is interested.
 
Last edited:
I can add it to the wiki here or someone else can depends on how much time I can find.
Model data is likely in Mode 1 sectors so that would be 2048 sized.
The space between the sector beginning and the TIM is likely to be offsets to the TIM and model data.  It's very efficient to load everything that way so that the TIM files are loaded from memory straight into the GPU VRAM. Generally they've used a table of offsets to point to data later in the file.  So each DWORD sized value is very likely the OFFSET into the actual data.  The total file size is already known so ... :)  What's likely to follow the TIM is the bone data however there is no certainty of that.

Cyb
 
If you find data that repeats that has the GPU quad opcode in it, follow the data and see if it traces out a UV map on the TIM. That's how I found the texture maps in FF8.

Remember, the PSX can do Quads "out of the box" and does not need to be broken down into triangles.
 
Status
Not open for further replies.
Back
Top