[FF8] battle.fs/MAG files, r0win, b0wave and a9btlfnt.bft

  • Thread starter Thread starter makipl
  • Start date Start date
Status
Not open for further replies.
Okay. This is interesting. I came back to GFs to finish old stuff.
I got the all vertices working [Can't really show the image, as 500 dots on still image doesn't show anything, but it's working alright, trust me]
and started to inspect the polygon data. As I wrote above, there are some data types. Example: 09 00 4c 01 is 4c01 polygons of type 0x09.
Problem is there's no normal/casual face indices data. For example battle stages have it like it should be normally:
00 00 01 00 02 00 which is: 1 2 3
Therefore example:
Code: [Select]
Code:
12 00 00 01 24 0012 00 01 01 25 00is:f 18 256 36f 18 257 37
I took the smallest object I could find (Some leviathan rock or idk) and inspected it. See for yourself:
test.jpg

Polygon makes no sense. There's no raising byte pattern. I couldn't understand. The only portion of data that used shared bytes is the one selected on blue. We know there's 12 vertices, so the face can only refference from 1 to 12 [0 to 11 for battle stages]. What do we see here? Nothing like this, only some  08,10,18,30. I put everything to Excel, sorted out and deleted repeating numbers. I got this:
Code: [Select]
Code:
1 02 83 104 185 206 287 308 389 4010 4811 5012 58
Exactly 12 different bytes. This is something I see for first time, but I gave it a try. Manually rewritten the faces to OBJ file, so the final file from the binary one is:
Code: [Select]
Code:
v 0 0.506 0v -0.5445 0.016 0.177v -0.215 0.183 -0.296v 0 0.191 0.463v 0.305 0.355 0.0975v 0.3365 -0.1285 -0.463v -0.5445 -0.286 -0.177v 0 -0.286 -0.5725v -0.058 -0.286 0.754v 0.3365 -0.286 0.754v 0.463 -0.286 -0.177v 0 -0.2995 0f 1 2 3f 1 4 3 f 1 5 4f 1 6 5f 1 3 6f 7 8 3f 7 3 2f 9 7 2f 9 2 4f 10 9 4f 10 4 5f 11 10 5f 11 5 6f 8 11 6f 8 6 3f 12 8 7f 12 7 9f 12 9 10f 12 10 11f 12 11 8
Saved and put into 3DS Max:
test.jpg

Working mesh (with a hole in the back, probably mistake, I did it manually]
I don't think this is bitfield, because the hierarchy is:
0, 8, 10, 18:
00000000
00001000
00010000
00011000

Has anyone seen something like this?

EDIT> Oh! I see now! It's based on 8! Every next number is +8, so:
0x48= 72/8= 9+1= f 10
So, the maximum possible face count is: 8192
That's all for Polygon type 9...

EDIT2-
the background continues spinning on every other stage. So... we still don't know how the engine manages that ah?
Now we know, there's global byte that controls stage spinning and bitfield variable that controls battle stage effect. Everything is coded. I'll make sure to publish all my notes next month.
 
Last edited:
You can get encodings where certain areas store different things, so it might be that the 3 least significant bits are used for something else.
e.g. 8-bit RGB colour is encoded in a byte as follows:
Code: [Select]
Code:
Bit    7  6  5  4  3  2  1  0Data   R  R  R  G  G  G  B  B
Also that hole might not be a mistake, it's quite common to not include faces that will not be seen in a model.
For example, if that side was touching the floor, it wouldn't be visible and it wouldn't need to be included in the model.
 
Last edited:
gf_environment.jpg

I'm implementing more and more polygon types. The many polygon types is a real thing.
Quads needs fixing order, probably the same as Battle stages wing order, so it's not a big deal.
Anyway majority of magic files is the same structure:
0x8 = texture palette only pointer (only 512 palettes, one by one)
0xC = model pointer
0x14 - texture pointer (main texture data pointer, again no header, nothing. By the bytes-per-palette I assume it's 16BPP texture)

All polygon data needs to be divided by 8 and +1 (because Wavefront OBJ needs so). Anyway:
Vertex:
ushort x,
ushort y * -1 (because models are upside down) ,
ushort z
ushort unused (probably so-called "W" weight. That's the only explanation of null 4th ushort)

Polygon:
PolygonHeader
PolygonData
---Repeat reading till FF FF FF FF (therefore one object/segment can have many polygons. Just like BattleStages has triangles and quads on one offset, GFs environment files can have even 4-5... )

Polygon 0x8:
ushort 0xA - A
ushort 0xC - B
ushort 0xF - C

Polygon 0x9:
ushort 18 - A
ushort 20 - B
ushort 22 - C

Polygon 0x12: (ABDC is not a mistake)
ushort 12 - A
ushort 14 - B
ushort 16 - D
ushort 18 - C

UPDATE: Checked my wiki article for BattleStages and quads fix is ABCD->ABDC. It's the same for GFs enviro. See here:
gf_environment.jpg


and... as far as the environment textures ARE inside the same file as geometry...  8)


UPDATE2:
Polygon 12 (0xC): (quad)
20 - A
22 - B
24 - D
26 - C

UPDATE3:
Damn yes!
gf_environment.jpg


UPDATE4:
Okay. Everything done! :3 Now the UVs... ?
 
Last edited:
Status
Not open for further replies.
Back
Top