Difference between revisions of "FF8/FileFormat magfiles"

From Final Fantasy Inside
< FF8
Jump to navigation Jump to search
my_wiki>MaKiPL
(Created page with "By MaKiPL ---------- This is generic MAGfiles article. Use this to reffer if file is either .nn (where nn is digit/number) or .N.dat (where n is literal) and therefore you do...")
 
my_wiki>MaKiPL
(reworked)
Line 2: Line 2:
 
----------
 
----------
  
This is generic MAGfiles article. Use this to reffer if file is either .nn (where nn is digit/number) or .N.dat (where n is literal) and therefore you don't know if given file is mag_t, mag_s, mag_p or mag_r. You made need to use HEX editor.  
+
There is no unified format for MAG files. Every file has their own naming, even extension. You can't really distinguish them.  
  
== General info about MAG files ==
+
Files starting with 10 00 00 00 09 00 00 00 are obviously TIM texture. What we know so far is how to extract GF sequence and GF environment geometry (ifrit ball, Leviathan's rock, Cerberus gate...)
  
MAG files are complete sequences for magic and G.Fs. These files contain textures, geometry data, camera movement, special effects, script data and AKAO frames. Sometimes, the naming is correct, but in some files the naming is completely messed up (00,01,02... or a,b,c(...).dat. Use below samples to know which format is which file.
+
==G.F. Sequence==
 +
http://forums.qhimm.com/index.php?topic=15056.0
  
The engine loads files by sequences. Some magic files are just one sequence, but some (especially G.Fs) are multi sequenced files. The engine loads files by sequences. When one sequence is ending, the second one is loaded in the place of the first one (not really, the sizes are varied, and the addresses are not static). After G.F. is over, the latest sequence is still in memory. It's just overwritten when needed.
+
==Environment objects==
 +
First, recognize file:
 +
1.Header must be 8 bytes null!!
 +
2.Jump to pointer at 0xC [Global]
 +
3.This int indicates pointer count. Example: 10 00 00 00 is 16 pointers
 +
3a. If pointer is 00 00 00 00, just ignore it and move forward
 +
4.After noting all pointers that are not 00 00 00 00 (therefore inspecting Count*4 bytes) just jump to selected one [Relative jump from count int]
 +
5.See third int (8th byte) for UNKNOWN [Relative jump from 03 00 00 00]
 +
6.Read int at 20th byte for VERTICES offset [Relative jump from 03 00 00 00]
 +
7.Read int at 24th byte for VERTICES COUNT [Vertex is 8 bytes! X Z Y W, where W is probably weight byte [as in OBJ specification] and is normally unused (as usual, even in casual OBJ files)]
  
TODO
+
I'm aware it's chaotic, like no tables and etc. but it's up-to-date information and I'll update it after I crack the face indices (triangles/quads)

Revision as of 00:28, 29 May 2016

By MaKiPL


There is no unified format for MAG files. Every file has their own naming, even extension. You can't really distinguish them.

Files starting with 10 00 00 00 09 00 00 00 are obviously TIM texture. What we know so far is how to extract GF sequence and GF environment geometry (ifrit ball, Leviathan's rock, Cerberus gate...)

G.F. Sequence

http://forums.qhimm.com/index.php?topic=15056.0

Environment objects

First, recognize file: 1.Header must be 8 bytes null!! 2.Jump to pointer at 0xC [Global] 3.This int indicates pointer count. Example: 10 00 00 00 is 16 pointers

3a. If pointer is 00 00 00 00, just ignore it and move forward

4.After noting all pointers that are not 00 00 00 00 (therefore inspecting Count*4 bytes) just jump to selected one [Relative jump from count int] 5.See third int (8th byte) for UNKNOWN [Relative jump from 03 00 00 00] 6.Read int at 20th byte for VERTICES offset [Relative jump from 03 00 00 00] 7.Read int at 24th byte for VERTICES COUNT [Vertex is 8 bytes! X Z Y W, where W is probably weight byte [as in OBJ specification] and is normally unused (as usual, even in casual OBJ files)]

I'm aware it's chaotic, like no tables and etc. but it's up-to-date information and I'll update it after I crack the face indices (triangles/quads)