CHRONO CROSS FILE EXPLORATION THREAD

[halkun]

Yup, those are bits. The GPU uses a 32-bit data latch so when a "row" of data is put into the GPU, you have to wait for GPU_READY singal for it to allow another "row" of data.

When using DMA transfers, this is taken care of by the DMA controller. When you manually place GPU packets into the GPU register, you have to wait and ask the GPU if it is ready to accept more data.

Direct GPU access is rarely used, DMA is an order of magnitude faster.

Oops, here is some vocabulary for you.

DMA == "Direct Memory Access"

DMA allows chips other than then CPU to have direct access to memory. This allows the chip to "suck" information down from memory without the CPU being involved, so the CPU can do more important tasks.

[yaz0r]

Don't forget that on PS1 hardware, the data isn't sent directly over the GPU, it is sent to the GTE that will perform all the math processing and finaly project the points in screenspace before sending them to the GPU for rasterization.
Therefor, you should look at the GTE documentation when it comes to vertex format.

It seems the GTE handle fixed-point data following this pattern:
1bit for sign
3bits for intergral part
12 bits for fractional part

I suppose all vertex data are in this format.

That said, I figured that it should be far easier to look into the weapon data than character data. Due to skinning, even if you display Serge's vertex array in 3d, it will not looks like Serge as the vertices will be lacking proper transformation by bones matrix.

Regarding the background data, it seems there is a bunch of DMA commands somewhere that just blit the background data to there correct position.

[FaustWolf]

Thanks again for all the help guys. Before I turn to weapon models personally, I'm going to try and map out the rest of Serge's, Kid's, and Guile's battle models and mess with the data as I've been doing, just to see what happens.

Weapon models are in the packs I attached earlier -- they're inside the "ModelMines" for those who want to look at them. I believe I've documented where they are inside the model mines, but of course all offsets are relative, so keep that in mind when you're looking for pointer tables and such:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg84377.html#msg84377

I'm also going to quote a post by Lupus from Qhimm. He had a look at Serge's ModelMine before I confirmed the 3D model data to myself, so that's why he refers to "unknown data." He comments about the weapon models as well:

I had a look at the "modelmine" file, I just noticed only now.
The file is nicely structured a header and relative offsets to subsections, and each subsection has a similar header. The only exception seems to be the (probable) model data starting at 9800, this may be hardcoded in the game code. Same for 14800 which is a header containig pointers to the other subsections until the end of the file.
Section 00009800 ~ 00014800:
the first $20 bytes are a header. The first value may be the number of sections, the others are relative the offsets (relative to the beginning of current section, that is). Some of the sections are similarly split in subsections. I have no clue what they may be
Section 14800 - end of file:
header as above; the "unknown" sections between weapon textures are certainly weapon models.
for example, the first is at 15dc8. From there:
    0-7 unknown
    8-11 offset to vertices section
    12-15 probably offset to unknown section (at 15df0)
        this seems to be made of groups of 4 bytes. I nocited some textures have weid coloring,
        maybe models are textured AND color shaded.  They could be RGB values. (but the 4th byte?)
    16-19 probably offset to unknown section (at 15ddc)
The vertices section is a Cyber said above: groups of 4 2-bytes values, the last is 00 00. Vagrant Story is like this both for characters and weapons, but your model data here seems different.
Note how the first value also is often 00 00 or little more, that's because of the flatness of weapon models. However the last value sometimes is 01 00 or 02 00   

[yaz0r]

Thanks again for all the help guys. Before I turn to weapon models personally, I'm going to try and map out the rest of Serge's, Kid's, and Guile's battle models and mess with the data as I've been doing, just to see what happens. 

Out of curiosity, how do you mess the data ? Do you rebuild and iso with modified data each time ?

[FaustWolf]

When I alter the model data, I perform whatever "surgery" I intend to do on a copy of Serge's battle model, then simply paste that altered copy over Serge's battle model on my 2048 byte/sector game image using Cygnus Hex Editor. I've got a pretty efficient system worked out, though I need to transfer Serge's model offsets from post-it notes stuck on my wall to the CC File Structure wiki sometime

I've not yet tried out the iso rebuilding capabilities in your Chrono Cross tools yet, yaz0r, or Nemesis' tools, I'm sorry to say.

I'll be happy to run experiments on weapon models if anyone thinks that would be useful in determining which sections in those might correspond to which types of data. Kid has one less weapon than Serge I think, so it's possible there should be a reference in the overall weapon models header to that number. I think it's 5 for Kid and 6 weapons for Serge IIRC.

[ZeaLitY]

Fortune smiles tonight. Some random guy hacked the debug menu 6 months ago, and published it on Youtube. Only 2,433 views have registered, so it didn't get much exposure. But while searching クロノ for more concert footage (god I hate that page), I found this:

http://www.youtube.com/watch?v=MWLDwjfiNHY

Debug menu (press L2 and push 1x R1)
8006B456 0101

So NOW we can mess with the debug menu's model options in whatever emulator [PEC] is compatible with. Or the PEC plugin, I guess.

Edit: Damn, this is just the map menu. Exit/return should take you to the main debug menu, but here it just cancels you back out to the game. Oh well; at least it's a start.

[FaustWolf]

ePSXe works well with PEC (PSX Emulation Cheater), I think. What kind of model options did you expect to find, Zeality? Is there more to the debug menu than just model size adjustments?

On another note, I'm detecting only 18 or so instances each of 0x24, 0x2C, 0x34, and 0x3C (possible beginnings for GPU command strings) in Section 1-2 of Serge's model data. I would expect one opcode per "face" on the model, so 18 instances is too few for this section to be representing UV map data -- I think. Furthermore, many of the instances are spaced far too close together for a GPU command to fit in between. But is it possible that a model format would contain commands for multiple types of faces, i.e., is it possible it would use both 3-point and 4-point textured polygons, shaded and unshaded?

And would it be prudent to look for GTE commands within a model file? yaz0r and Halkun have already explained some aspects of the nature of GTE vertex data and commands, though rest assured I'll have more questions about those when I begin investigating this particular matter in depth.

[ZeaLitY]

Just those commands.

[halkun]

Look for 7F...

Just for fun

[yaz0r]

When I alter the model data, I perform whatever "surgery" I intend to do on a copy of Serge's battle model, then simply paste that altered copy over Serge's battle model on my 2048 byte/sector game image using Cygnus Hex Editor. I've got a pretty efficient system worked out, though I need to transfer Serge's model offsets from post-it notes stuck on my wall to the CC File Structure wiki sometime

I know of an alternate way that may interest you. I abused it back in the days I was hacking PSX stuff. The main idea is that you can just patch the emulator memory. In Epsxe, make a savestate and rename the savestate file in .tar.gz and use winrar du decompress it. You can now just search the data you wanna hack in the save state file and modify it.
The nice thing is that epsxe is able to load a uncompressed save state. Most of the time, I just had the game running in Epsxe and at the same time the save state open in an hex editor. I would modify a byte, save, and it the reload savestate key in epsxe to see the immedate result.

[Sora]

tl;dr.

did we win yet?

[FaustWolf]

Thanks yaz0r. Yeah, Halkun suggested the savestate-alteration method earlier, but I've had a heck of a time getting my ePSXe to run my 2048 byte/sector iso for some reason. It runs my 2352 byte/sector bin file just fine IIRC, but I have this (probably unfounded) fear that the applicable data will appear differently than the model files I extracted from my 2048 byte/sector iso. I'll give it a go with my .bin file sometime, though, and see what I come up with.

@Halkun: There's about 50 instances of 0x7F in Section 1-2 of Serge's model. They are spaced at widely varying intervals (anywhere from 8 ~ 100+ bytes apart). What else should I look for that could go along with 0x7F? Is it an opcode of some sort?

@Sora: "tl;dr" isn't a clue regarding opcodes or anything, is it? To my still-untrained eyes, that looks an assembly language command, so I have to ask.

[ZeaLitY]

Oops, the original code was right. My Hydra marshes experiences just led me to make the wrong assumption about the debug menu's structure.

Okay, here's GIANT KID and mirror-world Kid (setting y and z rotation values to max). Nothing really important here after all, unless the GIANT thing can somehow be tracked to its target model data.

Still no idea what "set rect" does.

[attachment deleted by admin]

[FaustWolf]

Attack of the 50 Foot Woman! That's actually pretty amazing, because it shows how detailed the textures are on the character overworld models even - unless that's a battle model you got onto the overworld? Are there any problems getting the oversize characters through narrow passages? That might tell us something about how collision detection is handled.

[ZeaLitY]

The changes don't carry map to map, and so far I've been able to access any exit. Kid can't run any faster than her counterparts; it's like picking up the weights at Greco's.