FF7 Crisis Core - File Format and Data Investigation

  • Thread starter Thread starter koral
  • Start date Start date
Status
Not open for further replies.
a collage to tease you some more:


Looking through the other [!] files I noticed a lot of them are almost fully intact, just like the barrel and that can (box) thing. Most machine monsters and machine bosses, small objects etc.

Characters are still iffy.
I managed to get rid of a lot of random vertices and things are looking better now, although still far from perfect:


more updates as they come  :wink:
 
Oh my godness!!!
I dont know how to say :touched:
Haizz, be ashame of being helpless to you guys
 
its cool, you don't need to feel ashamed :)

I haven't made much progress with the characters, but I have noticed a few things.

There are two types of Vertices:

- those grouped as 24-byte chunks (including tag)
- those not grouped as 24-byte chunks (ranging from 28 to 300 bytes)

What you see in the above screenshots are only those 24-byte vertices, so the only thing to figure out now is how those non-24-byte vertices are stored.

Now inside those non-24-byte-vertices there are also a handful of other "tags" of somesort, in varying order.

The ones I've spotted so far:
Code: [Select]
Code: 
- 9a 99 99 3e  [short: 3e99999a]- 33 33 33 3f  [short: 3f333333]- 66 66 66 3f  [short: 3f666666]- cd cc cc 3d  [short: 3dcccccd]
I have no idea what they are, possibly some kind of PSP op-codes?

I know there aren't any Normals present because in FF7-CC they haven't used any real lighting (for improved rendering speeds I would guess), but what other kind of additional data could possibly be squeezed within vertex-triangle-lists?
 :|
 
I found a thing maybe be important in RAM dumper os PSP
In MDL and others files and other things have a memory pointers, I don't know will help with info.

MDL
4D444C00 01000A00 0011E098 01000000 01000000 B03E1609
01000000 C83E1609 00000000 FFFFFFFF 27000000 00060A00
00000000 FFFFFFFF 31000000 103F1609


Like This
B03E1609 (09163EB0)
C83E1609 (09163EC8)
103F1609 (09163F10)

This is a RAM "alocker" Have a Lots of this.
With a RAM PSP have 24MB then dump the RAM and you will be this way

B03E1609 then 0x09163EB0 then

0x09163EB0 - 0x8800000 = 0x963EB0 (this will be offset real on the RAM in HexEditor)

With this info you can info you can found a way to dissasembly the files i thing with this.

---------------------------------------------------------------------------------
MDL
4D444C00 01000A00 0011E098 01000000
01000000 B03E1609 // This point Lead to A

01000000 C83E1609  //This lead to B

A
00000000 FFFFFFFF 27000000 00060A00 00000000 FFFFFFFF


B
31000000 103F1609


PS: Maybe I will be wrong, I Thing this system will be work only Spanish Dump and found in USA GAme too

 0x8800000  this will be a Initial RAM for PSP
----------------------------------------------------------------------------------------

In files don't have any pointer.
In RAM this pointers tranforms in this pointers RAM

http://www.megaupload.com/pt/?d=GMESQM3F

Link to the DUMP SPANISH and DUMP USA "(2)"
 
Last edited:
um, I'm not sure what you're talking about ignitz  :oops:

usually there are a bunch of offsets in the header (first 0x80 bytes or so) pointing to different places in the file. I've been using a hex-editor to see if which number point to another section in the file, and which are just plain numbers.

But I don't know much about MDL files though, so I will have a look at that ram-dump to see what its about  :wink:

I would be interested to hear how you managed to dump the ram in the first place, it might help to discover what gets executed when the game boots up, because there might be something todo with the debug-menu in there!


Nothing new with the [!] files sadly, I'm still struggling to understand the non-24-byte vertex chunks  :-(

I gave them names though  :-P
- Type-1 Vertex data = 24-bytes
- Type-2 Vertex data = more than 24-bytes

Type-2 vertex-chunks actually contain multiple Type-1 vertices inside them, but they seem to be randomly located within the chunks.
The "extended" tags (0x333333f, 0xcdcccc3d, etc) look like they're padding, or mark the beginning and end of padding-bytes in some way. I haven't been able to spot an obvious pattern though, because they get used diffferently in different files.

so close yet so far  :|
 
Hey why not use 3Dx ripper ??
Have you loojed at the Yazor models viewer ?
 
Will you pack it in triple posting?? It's really really annoying to us watching the topic to find your pointless posts.
 
sorry everyone, life finally caught up with me again and I haven't had a chance   :-(

the project will be continuing until I can get characters rendered properly.
Everything else like map-meshes, animations, monsters and all the other stuff, I don't know. Maybe I will, maybe I wont.

I should get some time over the weekend to try solve this stupid vertex stuff, fingers crossed
 
I guess I'll try and help out too :D
Thanks for your commitment to this koral!
 
Hey Koral

Good to see you doing a great job

Its almost there. Thumbs up mate :wink:
 
A little update of what I did over the weekend, and what I'm trying now

Things are almost falling into place:


Moogle-san's head now has all the correct vertices, but hundreds of new rogue vertices also seemed to get detected.
I have been working on a special sort of "data parser" to handle the Type-2 vertices, because there really isn't any logical way to find the Type-1 vertices without reading through and ignoring all the random padding "tags"

For example, here is the breakdown of the first Type-2 vertex in file 02373 [moogle]:
Code: [Select]
Code: 
  vertex 66, start: 0xd30,  end 0xdd0,   size: 0x100  0x00 00 00 80 3f *** TYPE-1 VERTEX tag 0x04   TYPE-1 VERTEX 0x18 01 00 0e 00 ? 24-byte padding start tag [2nd and 4th bytes always zero] 0x1c       20-byte padding 0x2c 54 00 00 00 ? 4-byte padding [2nd, 3rd and 4th bytes always zero] 0x30 66 66 66 3f   4-byte padding 0x34 cd cc cc 3d   4-byte padding 0x38   TYPE-1 VERTEX 0x4C 33 33 33 3f   4-byte padding 0x50 9a 99 99 3e   4-byte padding 0x54   TYPE-1 VERTEX 0x68 66 66 66 3f   4-byte padding 0x6c cd cc cc 3d   4-byte padding 0x70   TYPE-1 VERTEX  0x84 33 33 33 3f   4-byte padding 0x88 9a 99 99 3e   4-byte padding 0x8c   TYPE-1 VERTEX
There were 5 Type-1 vertices packed into this Type-2 chunk, and the number varies a lot.
The most difficult thing is trying to determine a UV-FLOAT (0-1) from either of 3 tag (padding) possibilities:

- 00 00 00 00 = pops up in a lot of other files, usually following other padding-tags
- 1st byte non-zero, 3rd byte non-zero, 2nd and 4th bytes zeros = 24-byte padding
- 1st byte non-zero, rest zeros = 4-byte padding

But its all most definitly based on 4-byte (2-SHORT, 1-FLOAT) reads, although not neccessarily after 20-byte chunks (size of Type-1 vertices).
Its a long haul and a tough cookie, but I wont give up until its over  :wink:
 
Indeed it is strange...
...Koral, how come the latest screenshot of the moogle appears to have a Completely messed up Body below the head, whereas the screenshot before that looks almost normal in terms of the body? In fixing the Head, have you somehow ruined the body? That's really quite weird.
 
sorry peeps, i'm still struggling for time

it looks ugly because all those random vertices are all from the Type-2 vertex chunks. I have not been able to find a way to cleanly get the correct vertices out of those chunks, because there are usually more fake vertices than real ones. Those fake vertices might be padding or maybe something else. But there just isn't a clear-cut way to tell which is which.

I didn't want to have to do this, but have a look at some of the characters as they look now, demonstrating what I mean:



Zack:


Reno:



there were hunderds of fake-vertices, and I have spent the past couple of weeks trying to decypher the "rules", to be able tell which vertices are fake and which aren't.
Some of those fake-vertices are still there, and in other cases, real vertices get mistaken for fake ones, causing the polygon indexing to mess up.

I have made a number of minor discoveries, but I wont spam this topic with useless bits of posts until I make a breakthrough.

I have also been given acess to the Quimm-Wiki, I just need to find the time to get on with it.
Sorry for not getting much done this month :oops:
 
It's ok Koral, at least your getting somewhere with it. They dont look that bad right there, just missing a few bits.
 
Koral, you haven't found any bone data yet have you? It's starting to look to me, that some of those fake verts may be bone joins and endpoints... namely the ones at the ends of Reno's hands there, they are in a conceivable place to be the ends of the wrist bones...

Another thing to note... Is it just me, or does that large cluster of crap under Zack not have a similar shape to the buster sword?

On a seconds inspection, the rod Reno uses is beneath him, so that must be the sword. Perhaps some of the fake verts are related to secondary textures required by the engine... It looks like the buster sword is using Zack's texture, rather than a new one.

I know you may have already noted much of what I've said, but in case you somehow missed it, I hope my ideas have helped somehow... On the other hand I could be completely wrong.
 
Status
Not open for further replies.
Back
Top