[FF8] .x battle fields

  • Thread starter Thread starter Halfer
  • Start date Start date
Status
Not open for further replies.
I just tried using some of the headers I found at a0stg105.x, to a0stg012, and... It doesn't work. So, it's compressed? Changing the parameter I had to show/hide objects is working here like a camera freeze... Ugh... I'm losing it... I'm off for today, maybe someone find something out. Could it be really gzip'ed with moved header? I don't know.

EDIT: Nope. I'm just tired and do mistakes. It works the same way as on other stages:
mqqfmnd4kcps.jpg

Also there's 1981 vertices, so it does look like it only hides the mesh or craps it's UV map. Or maybe it was 3000 vertices before ground dissapearal? Nah, I'll leave it for the next time... Too tired now.

Also thanks to.. rcxrdx, for patch, to display more debug strings for debugger.
 
Last edited:
That may be the case, I hope someone with lot of knowledge in compressions could have a look at this. I did find out that after the header in 0x3d90 the variables are for vertices/faces for the ground part.  However I thought about the structure for a long time but it just didn't make sense. Maybe more experiments would do the work but yeah.... Compression would still be a big limiting factor in cracking the format.
 
Used Hex2OBJ, to visualize point cloud, as I was refereed to on XentaX forum.


*This ARE in fact vertices starting at this 01 00 00 00 08 ...
0x3D90 - 119 vertices
Object 1:
fnotdtv3q1es.jpg
 
Last edited:
Yep. Two other objects are like spheres, but with some details. I'll take a photo of it tomorrow. Still searching for a faces info. I'm having a huge support on Xentax, so I think we'll find it eventually. I'll make you updated :)

Still however no one could identify this data from 0x0 to 0x5D4. On 5D4 is camera starting, but before that? Nothing. Completely nothing. If anyone of us could get the breakpoint when this portion of data is accessed would be awesome, as I'm having almost no experience in process debugging and etc.
 
Last edited:
That's the only possibility paul. This however doesn't make much sense. Every script is written right to enemy itself, or is scripted in engine. Maybe an animation? Diablos zone has animated background, also eight witches at time compression have deformation animation in it. I'll try to nullify those stages.

Probably found faces, but it's build is a little mess, so the software doesn't read it good. I'll need to manually delete this unwanted data and see what I get. I'm running out of time thou, as I do have a lot of work, so give me two days for update. After faces next step us UV. But I'm just aiming for this base mesh.

Mesh looks a bit more complicated than we though.
 
Last edited:
Okay, I probably found out how the ground is formed.

6d32c5427bd95158dc28c2c81b224cc6.png


I highlighted one unmodified section of mesh which seems to represent vertices. Each section at the header start (haven't checked much further) seems to contain 9 vertices which are connected to each other. The numbers colored with orange are nullified vertices and then I added hex number 01 to the possible Z-axis variable. This was the result:

8910e2fdd027b07744fe467bf8a0b25f.png


It seems to go a little over the ground which is expected with 01 value since it's the first bit to represent the shortest distance in this 3d dimension. Also the XY-axis seems to collide in the middle which is also expected since they are 00 00 both now.

Here's a little clarification how it may work:
Code: [Select]
Code: 
Offset: 0x3dd8B3 F3   B3 F3     00 00B3 F3   CD F7     00 00B3 F3   E7 FB     00 00 B3 F3   00 00     00 00B3 F3   1A 04     00 00 B3 F3   34 08     00 00B3 F3   4E 0C     00 00 B3 F3   68 10     00 00B3 F3   99 EF     00 00X-axis, Y-axis,    Z-axisX and Y axis may differ.
So to sum up it seems that each vertices has 6 bytes reserved where 2 bytes represents axis in XYZ-format. Hope this gives some insight for you MakiPL! :)

EDIT: I tested it with a0stg101.x and this is what I got (sorry for bad angle, maybe we can get better angles when we can alter the camera):
cc00d1bb0aea86ce4d0af9286ee0bd23.png


This is what i changed:
696b56d00f15128ebb28cd63c1bcfa98.png

Seems to work how i described it. I'm tired now so going to sleep :/
 
Last edited:
Yep. Two other objects are like spheres, but with some details. I'll take a photo of it tomorrow. Still searching for a faces info. I'm having a huge support on Xentax, so I think we'll find it eventually. I'll make you updated :)

Still however no one could identify this data from 0x0 to 0x5D4. On 5D4 is camera starting, but before that? Nothing. Completely nothing. If anyone of us could get the breakpoint when this portion of data is accessed would be awesome, as I'm having almost no experience in process debugging and etc.
Click to expand...
Could that be the code for a different field?  Are all of the areas the same?  For example - do the planes operate the same way on the 'beach' battle field?  Or on the 'mountain' battle field?  Perhaps those codes are used for other scenes/functionality?  The only battle field I've seen you guys try to do is the forest.  I don't know a thing about the backend, though - so forgive my ignorance of the process :)
 
Too bad I don't have a copy of FF8 to dig in to the EXE :(

Looks like you're making good progress anyway :)
 
Too bad I don't have a copy of FF8 to dig in to the EXE :(

Looks like you're making good progress anyway :)
Click to expand...
You could be a help and try to find out in which freaking format the both event files are packed in the snowboard minigame of FF7. As long the files are unknown I   we can't replace the models there.
 
Exactly Halfer, vertex is 6 bytes. I pointed it out on XeNTaX forum, but forgot to do it here. :D Thanks to you, we know it's standard X Y Z.

Sometimes the stages has some weird parameters. For a0st105 it's plain square, but, and that's interesting:

-Even if set the vertex to be higher than 00, it does is covered by the forest model, and player/enemy. It's hard to describe, but let's say we just CAN'T make the ground get higher, so example Squall would have to run thru ground to attack the enemy. Why? Because of the rendering options. The other example of rendering is the example of ground highering you made a test on. The ground mesh is combined with some high points in the background, so the rendering option is set to be normal 3D model, not some "weird one".

A few problems are still appearing:

1. Is X Y Z of vertex reverse-bytes? example 00 05 is higher than 05 00?
2. Still finding the UV and face indices. shakotay2 on XeNTaX made a face test with the data he found, and also rejected my idea. However, the test failed, here's his screenshot:
vs04efnr1gvd.jpg

3. Where are the length bytes? Really. For a0stg105 probably, there're 152 vertices, so 152*6 bytes, still can't find that number, yet. How does the game know for how long it needs to read next bytes.

So, the vertices data is after header 01 00 00 08, and for a0stg105 is as I remember ~152. So After:
01 00 00 00     08 00 00 00     01 00 01 00, after this 152*6 bytes is whole ground vertices data.

If you find the data portion, where the texture is going crazy, and it's before .TIM, then you'll find UV, that could be useful also.

Also, a0stg160 looks great for reversing. It's a cube with UV layout + sky. So only two objects, low res texture, less data portion. I'll take a look there by HEX reversing, see if I could find the UV map, and see if I can find the entry point where vertices does start, and when it does end, to see if there's something characteristic. If so, then possibility of writing a software to rip this stages raise drastically.


Also, I cut from the file all three objects, from 01 00 00 00 08... to another this pattern, so I could test only one mesh, and less data I had to look at.

I'll take a closer look at a0stg101, and try using this HEX2OBJ software, to get the vertices of this ground, and see if it fits. I'm at school ATM, so I don't have that exact file, I'll do it at home.

We're making a nice progress here. :)


maybe we can alter camera
Click to expand...
Camera starts from 0x5da (a0stg105.x with header like 02 00 08 00 20 00...). Camera is dynamic, has pre-keyed prologue animation, miss animation, and camera locations for various enemies. It's hard to reverse camera data, if I have to work on random events. Oh...
 
Last edited:
Nice, May I ask what programs are you using in your picture and with the analyzing. Would also help me a lot to make faster analyzes.
 
Let's see. The expected length byte is 9B for a0stg101.x, so 155*6=930 bytes from 0x2b5e.
AND!!! YAY!!!!!!!!!!!!!! THAT'S IT! THAT'S IT!

1.Length byte is two bytes. In this case 9B 00 (Big endian). So 9B= 155, and when made a point cloud from it look what an crystal view appeared:

kgpvbmm4jcfw.jpg
. And even bigger awesome news! The verices after 930 bytes ends with series of 00 and then another section also with (I'm ATM sure of 80%) header length appears. It's a much bigger amount of data, and guess what, the length byte is also bigger and made from two bytes. I'll test it as faces.

STRUCTURE:
95ulprpvb7b6.jpg
 
Last edited:
Great find! I wonder why it is showing as ellipse. Also the placement of vertices looks very odd in order to make a proper face with uv's
 
This ellipse as I remember is from Tonberry fight zone (So it has to be ellipse) or a0stg101, then it could be weird. But, to make you sure that it's 100% vertices data and it's structure is right here's the cake:

sruvs9nc36sh.jpg


Straight from Ifrit's level. Also, that Code: [Select]
Code: 
01 00 00 00 08 00
thing only appears with FIRST object, on second and third instance you'll have to find this header object, but then pass at least 20 bytes, to find nearest Code: [Select]
Code: 
 01 00 01 00 ** 00 XX XX XX
Where:
**- Would be length header
XX - Vertices info

This applies also for first instance, but for first one this appears just after this header, for second/third object as I wrote it's divided by some bytes, even 160!
See here:
2b3279f6bb.png
. Yellow selected area is the bytes, that you have to ommit from 01 00 00 00 08 header, to get to byte length.

Do this ALWAYS!. Do NOT start to get vertices info just after header as I wrote some days ago, but after the length byte, that is ALWAYS after 01 00 01 00 **HERE**.


Also, for the SCRIPT section from start up to camera section (header 02 00 08...). It's almost the same on every map, BUT! The maps having animated texture like Ifrit's level, are having completely different this section. So it's 60% texture animation section. Still someone of us will need to null'ify this section up to texture and see what'll happen to lava. The thing game doesn't care for NULL'yfing (probably wrote it bad) 0x0-0x5D4 on forest level is that, there's nothing to animate on forest level...

Halfer, looks like .X file is breaking upon us. :))

EDIT2: Just checked the point cloud with a better shot of Ifrit's stage. It's 100% the same. Yep, we made it! I'm so happy. There's still two things to do:
1) Face indices
2) UV Map

EDIT3: Hey, remember the "opted battle stage" you posted in my topic of unused VIII's BG? I think I've seen a stage like this there. When we finish, I'll totally get a trip thru every stage in this game! Maybe it's just some simple meshes with details, but it's so exciting to look at it.
 
Last edited:
Face indices are 24 bytes, and also have byte length, for faces they're REVERSE byte, so big-indian... Stay tuned!

Vertices byte length is two bytes long, and is also read reverse. Just after length, pass Length*6 bytes, and you can meet 00 00 00 00, thing, after that there's another length byte hidden in four bytes portion. Length * 24 bytes. After that, you'll pass to next object. Where's the UV?

I'll keep you updated.

UPDATE 15:50 - Looks like after vertices, there is 6 bytes of zero'es, then there's 4 bytes of:

1.Face indices byte length (2B) Yep, always 20.
2.UV (2B) always 24

Don't know which one is which.
 
Last edited:
Maki you are making amazing progress, even though I know very little about hex editing, I tried using reverse bytes to help you find UV/face vertices for a0stg101 do these pictures mean I'm near the UV since you said the texture data goes crazy or is that something else? 

YagHbtt.png


w8URPwC.png
 
Yagami, this one is interesting, and really, I don't know why is it happening. In your image, the only thing with messed UV is enemy and player, which in fact are completely other files. This is strange. Also, I already found UV, and length byte in my latest post here (ignoring this one). See:

41uqnpe9o2gf.jpg
. After I do some testing I'll end up with UV structure. Still, the face indices are our problem. They're 20 bytes per one.
 
Status
Not open for further replies.
Back
Top