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

[Maki]

[obsolete, of course!] :3

This is the only leftovers undocumented that are in battle.fs, after that we would 100% finish battle.fs

=MAG files=
So... Let's say something about MAG files. Those are chaotically managed files, can contain various extension and has no normal formula... I found TIM texture in file like mag115_h.13 and also in mag161_a.dat (See? Extension is not important here). Just recently when I began to looking at files I found QUAD model in one file:
mag094_b.1s0 (Uses the same QUAD format as Battle stages- identical)

also 16B pattern in:
mag094_b.2e0 (starting at 0x298c). There's probably 4B padding before that.
There is 2 149 such triangle-like things. (0xbbe4 a next the same pattern starts)

mag094 is Siren G.F. attack.

I know Kaspar was looking at G.Fs.



=r0win.dat=
This file is responsible for whole winning sequence. I found AKAO frames in it, probably camera movement and whole logic. Game runs into infinite loop when you delete file and win battle. Hud disappears, you can't do anything. Nothing happens. Battle music plays. Nothing.

=b0wave.dat=
I don't know completely what this file is.
When deleted and enters battle, the enemy nor player is loaded and even no battle logic. The stage just plays anim and nothing happens. So, this may be the route:
1.Engine loads stage+music
2.Stage plays opening camera animation
3.b0wave.dat is loading battle core data
4.When you win, r0win.dat handles what comes next

=a9btlfnt.bft=
As above. Nothing happens when deleted.

Feel free to write any notes you have.

@update to MAG:
I deleted mag094_b.2e0 and the game gets into infinite loop after the sea sinks the enemy. The sea is flowing thru enemy, camera is fixed, nothing happens. This means, that the MAG files are sequenced. One part of file is loaded after it passes another part of sequence is loaded. This way programmers probably saved some memory.

[kaspar01]

Saw this only now 

I'll search for info I found many time ago and post here as soon as possible (have to sleep now :p)

p.s.

I tried to scan mag094_b.1s0 whith your battle stage tool but found nothing 

The thing I'm most curious about are not GF itself but their scene/animation models (Cerberus gate, Shiva ice stuff , Ifrit magma ball, Siren's reef etc..)

[Maki]

@Update:
Okay. I found quad count.
0x234c (9036) in mag094_b.1s0 - 192
192*24=4608
And... There's 4608 of pattern-like bytes in this file. After that unknown data is represented. For 192 face indices, there has to be many vertices. The only "big" unknown data is before face indices.

0x12 represents 3423h which is 9012d. There are 9012 bytes of data and some padding before face indices. Does file store total bytes count instead of number of data? That's totally different. 9012/8 is leaving a floating point number. Divided by 6 is giving non-point value. I'll run a Point cloud visualization on given data. Keep updated.

#UPDATE: Point cloud represented plain surface with some glitched points.

#UPDATE2: Quads max face indice index is 211. That means, there must be atleast 211 vertices.

Okay. Naming cracked:
mag094_b.XyN
where:
X- Sequence number
y- Data type
N- ID number
Example:
mag094_b.2s2 is Sequence number two (read below about Siren's sequences), second geometry model (s2)

Siren sequences:
1- Sea is flooding enemy
2- Siren is playing on harp
3- "ending" point where there's effect of echo like rings on enemies.

MILESTONE! I got this. 1sN files are having header with offsets to data portions!

Case mag094_b.1s0:

Code: [Select]

offset point_offset         data
1 1 header?
4 13664 UNKNOWN
8 12 Probably vertices? (with weight)
12 9012 Just a bit before quad data

I tried memory hacking and wipping out mag094_b.2s3, I left only header (containing pointers) and null'ied everything else. NOTHING. But when I try to delete whole file (so in fact 12B header) the game doesn't hop to sequence 2 and stops in infinite loop at the latest keypoint in sequence 1. Mhm... ;/

Okay. I got this:
Okay, almost every time in naming XyN where y is 's' the file build is:

First 4 bytes: count of pointers
Next 4bytes*count_of_pointers = pointers (for 4 bytes)
INDEX is NOT zero! That means, if count_of_pointers = 01 00 00 00 then real count is ==1, 06 00 00 00 is 6 (six) pointers and 00 00 00 00 is zero pointers (in some cases in data 00 means 1, that's what I mean)

[kaspar01]

Okay. Naming cracked:
mag094_b.XyN
where:
X- Sequence number
y- Data type
N- ID number
Example:
mag094_b.2s2 is Sequence number two (read below about Siren's sequences), second geometry model (s2)

OMG! that was the meaning of those weird "extensions"! I would have never been able to figure it out XD

Siren sequences:
1- Sea is flooding enemy
2- Siren is playing on harp
3- "ending" point where there's effect of echo like rings on enemies.

MILESTONE! I got this. 1sN files are having header with offsets to data portions!

Case mag094_b.1s0:

Code: [Select]

offset point_offset         data
1 1 header?
4 13664 UNKNOWN
8 12 Probably vertices? (with weight)
12 9012 Just a bit before quad data

I tried memory hacking and wipping out mag094_b.2s3, I left only header (containing pointers) and null'ied everything else. NOTHING. But when I try to delete whole file (so in fact 12B header) the game doesn't hop to sequence 2 and stops in infinite loop at the latest keypoint in sequence 1. Mhm... ;/

Okay. I got this:
Okay, almost every time in naming XyN where y is 's' the file build is:

First 4 bytes: count of pointers
Next 4bytes*count_of_pointers = pointers (for 4 bytes)
INDEX is NOT zero! That means, if count_of_pointers = 01 00 00 00 then real count is ==1, 06 00 00 00 is 6 (six) pointers and 00 00 00 00 is zero pointers (in some cases in data 00 means 1, that's what I mean)

That's interesting!

I'm not at home now but I remember there was a method to understand "how big model was" and find them inside ff8.exe files (some GF are hidden there)

If you didn't yet I think you should read this topic here on Qhimm forum :

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

P.S.

you should have a PM

[halkun]

I just watched a whole bunch of FF8 summons and they all fit into this three-part "beat"

1) Appearance
2) Attack
3) Damage

Maybe something there?

[Halfer]

This was found in FF8.exe ASCII rip.



These files are listed right after all the battle.fs files. There are 349 of these entries and I think they contain the 3d properties of all the spells, summons, limit breaks and so on....

I'm not sure if they do really exist in FF8.exe or if they are left overs, hence can't really prove if these are files or just names left in the compiled version and never used.

[kaspar01]

I could be totally wrong but..

We actually know that there are some gf and other stuff (like grim reaper and baby-angels from final battle) that can be found only inside ff8.exe so what you're sayn' could make sense..

Moreover I would guess that those Mag###.X files could actually be "GF battle stages".. I mean places where GF are usually shown..for example the sea for siren , cemetery for cerberus and so on..

I'm sure  that ff8.exe file can reveal many secrets 

[Halfer]

I could be totally wrong but..

We actually know that there are some gf and other stuff that can be found only inside ff8.exe so what you're sayn' could make sense..

Moreover I would guess that those Mag###.X files could actually be "GF battle stages".. I mean places where GF are usually shown..for example the sea for siren , cemetery for cerberus and so on..

I'm sure  that ff8.exe file can reveal many secrets 

Not only GF environments I think. For example I have a pretty high suspect that Squall's blasting zone animation includes 3d geometry as well as Quezacotl's entry animation. That is based on the moving clouds which looks moving like the battle stage clouds, in circular rotation.

[kaspar01]

Not only GF environments I think. For example I have a pretty high suspect that Squall's blasting zone animation includes 3d geometry as well as Quezacotl's entry animation. That is based on the moving clouds which looks moving like the battle stage clouds, in circular rotation.

Yep!

I don't know how many .X file reference you found.. but since they have the same extension of battle stages I guessed that they could be the "environment" that sometimes game show during certain animations..it could make sense..

There could be many other file format in the exe (we already know it contains many .tim texture).

There should be many magic that clearly use 3D geometry (for example all the ice ones) but in most of case we have "somehow animated mesh" that we usually don't find elsewhere.

Another thing that has not been considered yet could be bone scaling.

I remember I read once here or on xentax that bone scaling is not used in this game but that's actually not entirely true..

I can think to only a sample of bone scaling but I'm actually sure it's used for GF Pandemona "tail" inflating animation..
Moreover there is Bomb/Piros "enraging animation".. even if that animation is not a bone scaling animation..more probably is scripted..

Many of magic geometry animation anyway could (probably) use bone scaling and I think we should keep that in mind

[Halfer]

Yep!

I don't know how many .X file reference you found.. but since they have the same extension of battle stages I guessed that they could be the "environment" that sometimes game show during certain animations..it could make sense..

There could be many other file format in the exe (we already know it contains many .tim texture).

There should be many magic that clearly use 3D geometry (for example all the ice ones) but in most of case we have "somehow animated mesh" that we usually don't find elsewhere.

Another thing that has not been considered yet could be bone scaling.

I remember I read once here or on xentax that bone scaling is not used in this game but that's actually not entirely true..

I can think to only a sample of bone scaling but I'm actually sure it's used for GF Pandemona "tail" inflating animation..
Moreover there is Bomb/Piros "enraging animation".. even if that animation is not a bone scaling animation..more probably is scripted..

Many of magic geometry animation anyway could (probably) use bone scaling and I think we should keep that in mind

There is 349 MAGxxx.X files referenced in executable.

I'm not sure about the animated meshes. For example the time compression where you fight multiple sorceress you can see the battlefield vertices falling to the ground. That however could be done with a script so they are probably just a0stgxxx.X battlefields.

[kaspar01]

There is 349 MAGxxx.X files referenced in executable.

I'm not sure about the animated meshes. For example the time compression where you fight multiple sorceress you can see the battlefield vertices falling to the ground. That however could be done with a script so they are probably just a0stgxxx.X battlefields.

that's a lot of files..
About the multiple sorceress battle I'm quite sure they used normal stage files since we have 2 edea's deling room in a0stgxxx.X battle stages: the one whith opened door (when you fight monsters attacking Rinoa ) and the one whith closed door (during the time compression).

[Halfer]

that's a lot of files..
About the multiple sorceress battle I'm quite sure they used normal stage files since we have 2 edea's deling room in a0stgxxx.X battle stages: the one whith opened door (when you fight monsters attacking Rinoa ) and the one whith closed door (during the time compression).

Yeah, there are also lots of spells with different background "filters" and I think the spells itself are formed in 3d meshes, atleast I cannot think a way how the bending of textures could be done without 3d meshes. Also including MAGxxx.X files in executable would reduce the lag and disk I/O improving performance during animations which could be reason why they are not separate from the .exe .

This could also mean nothing and they can just be old references never used, but let's see how it turns out.

[kaspar01]

I actually never looked at psx files but.. files that are in ff8.exe for pc version are supposed to be somewhere else in ps1 files..

[Maki]

Sorceress battles are my the most unknown. There are like ~12 enemies. This makes no sense to scene.out, also the stages are changing. I'm confused.

[Maki]

Aaaand. Together with Kaspar01, the sorceress battles is no more unknown.

Their battle thing IS NOT in their .DAT files neither in scene.out, that little devil is HARDCODED to game's EXE. The game code manages whole sorceress battle structure. The level structure is at 0BE00037 in memory of Steam edition, dumped and read as ASCII resolved this:

Code: [Select]

smPcRead::\ff8\data\eng\kernel.bin
smPcRead::\ff8\data\eng\sysfnt.tdw
smPcRead::\ff8\data\eng\icon.tim
smPcRead::\ff8\data\eng\namedic.bin
smPcRead::\ff8\data\eng\wm2field.tbl
smPcRead::\ff8\data\eng\menu\mngrphd.bin
smPcRead::CD:\DISK1
smPcRead::\ff8\data\eng\field\mapdata\maplist
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.mim
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.pmp
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.pvp
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.id
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.map
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.ca
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.inf
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.rat
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.mrt
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.msd
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.pmd
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.jsm
0 = ::FUNC_ISPARTY(0)
0 = ::FUNC_ISPARTY(0)
0 = ::FUNC_ISPARTY(0)
smPcRead::\ff8\data\eng\field\mapdata\te\test1\test1.pcb
smPcRead::\ff8\data\eng\battle\A0STG137.X
smPcRead::\ff8\data\eng\battle\B0WAVE.DAT
smPcRead::\ff8\data\eng\battle\C0M116.DAT
smPcRead::\ff8\data\eng\battle\D0C001.DAT
smPcRead::\ff8\data\eng\battle\D0W000.DAT
smPcRead::\ff8\data\eng\battle\A0STG018.X
smPcRead::\ff8\data\eng\battle\A8DEF.TIM
smPcRead::\ff8\data\eng\battle\A0STG107.X
smPcRead::\ff8\data\eng\battle\A8DEF.TIM
smPcRead::\ff8\data\eng\battle\A0STG057.X
smPcRead::\ff8\data\eng\battle\A8DEF.TIM
smPcRead::\ff8\data\eng\battle\A0STG012.X
smPcRead::\ff8\data\eng\battle\A8DEF.TIM
smPcRead::\ff8\data\eng\battle\A0STG106.X
smPcRead::\ff8\data\eng\battle\A8DEF.TIM
smPcRead::\ff8\data\eng\battle\A0STG007.X
                         
Thanks to kaspar01 for spending time on watching witches gameplay and providing complete list of stages. 100% match.

[JeMaCheHi]

Sorceress battles are my the most unknown. There are like ~12 enemies. This makes no sense to scene.out, also the stages are changing. I'm confused.

I was also very confused and intrigued about that battle. It's probably late to say that since you and kaspar found out that it's hardcoded on EXE (I take my hat off), but there's no 12 monsters, just 5. There's 2 of the first sorceres, 2 of the second one, and 1 of the wormlike. I spent some time digging on their AI scripts, and concluded that they was reviving all the time the same monsters. As far as I remember, they has a counter with a shared variable. It increments when a sorceress is killed (better said, when a sorceress is killed it will be revived and reloaded, and it's init code will be runned). If it's minor than 6, the game revives a 1st sorceress. If it's equal than 6, then it loads a 2nd sorceress. And the same is applied for the 2nd one.

Here's what I had on my notes about the first sorceress AI's Init code:

Code: [Select]

//Init Code:
02 60 C8 03 00 00 78 00 [ // if $60 != 0
13 60 01 // $60++
02 62 C8 00 00 00 06 00 [ // if $62 == 0
0F 62 01 // $62 = 1
23 03 00
]
{ // else
0F 62 02 // $62 = 2
}
04 C8 0C 01 // ability 0c01 on self (entrance animation)
02 60 C8 00 02 00 06 00 [ // if $60 == 2
0E DC 02 // DC = 2
23 00 00
]
02 60 C8 00 03 00 06 00 [   // if $60 == 3
0E DC 03 // set DC = 3
23 00 00
]
02 60 C8 00 04 00 06 00 [
0E DC 04
23 00 00
]
02 60 C8 00 05 00 06 00 [
0E DC 05
23 00 00
]
02 60 C8 00 06 00 06 00 [
0E DC 06
23 00 00
]
02 61 C8 00 03 00 09 00 [ // if $61 == 3
0F 61 00 // $61 = 0
0E DD 03 // $DD = 3
23 06 00
]
{
0F 61 00 // $61 = 0
0E DD 06 // $DD = 6
}
23 13 00
]{
13 60 01 // $60 + 1
0F 62 01 // $62 = 1
0F 63 00 // $63 = 0
0E DC 01 // DC = 1 -> DC is the number of witch
0E DD 03 // DD = 3
04 C8 0C 00 // ability 00: appear fading in.
}
00 00 00 00 00


[Maki]

Try to replace second witch with any other enemy. It appears invisible (casting potion will show them), and replicated by THREE. Works with any enemy. How the game know to replicate enemy by 3? What's hidden in this FF8!?



I monitored variables on sorceress battle. Here's what I got:

This opcode:

Code: [Select]

FF8_EN.exe+8870B - mov [eax],edx

Accesses:
Memory: FF8_EN.exe+1928DA4 [01D28DA4]  (Holds kill count of sorceress)
Memory: 01D28D98 (Holds whole count of sorceress, ex actual sorceress count, ex if you kill one, this raises, when second gets on stage, this count raises)

@UPDATE: Yes. Just tested. The game checks if 01D28D98 is 12, if yes, then next summon is witch_worm. Either the game gets in infinite loop if you either freeze 01D28D98 or NOP (90h) the FF8_EN.exe+1928DA4


Battle stages are divided to three segments:

1. Ground
2. Background
3. Sky sphere

The game takes one segments and deforms it. That's why only the objects deforms and not ground or sky. On final worm_witch, the engine loads shaking camera animation and moves segment 3 on X axis. Thanks to memory hack I forced game to fight with normal witch on final stage. I froze witch count to 1 and kept killing them. This way, the segment 3 was moving on all stages which was kinda funny. I recorder video. I'll upload this and update this post.

[JeMaCheHi]

Try to replace second witch with any other enemy. It appears invisible (casting potion will show them), and replicated by THREE. Works with any enemy. How the game know to replicate enemy by 3? What's hidden in this FF8!?



I monitored variables on sorceress battle. Here's what I got:

This opcode:

Code: [Select]

FF8_EN.exe+8870B - mov [eax],edx

Accesses:
Memory: FF8_EN.exe+1928DA4 [01D28DA4]  (Holds kill count of sorceress)
Memory: 01D28D98 (Holds whole count of sorceress, ex actual sorceress count, ex if you kill one, this raises, when second gets on stage, this count raises)

@UPDATE: Yes. Just tested. The game checks if 01D28D98 is 12, if yes, then next summon is witch_worm. Either the game gets in infinite loop if you either freeze 01D28D98 or NOP (90h) the FF8_EN.exe+1928DA4


Battle stages are divided to three segments:

1. Ground
2. Background
3. Sky sphere

The game takes one segments and deforms it. That's why only the objects deforms and not ground or sky. On final worm_witch, the engine loads shaking camera animation and moves segment 3 on X axis. Thanks to memory hack I forced game to fight with normal witch on final stage. I froze witch count to 1 and kept killing them. This way, the segment 3 was moving on all stages which was kinda funny. I recorder video. I'll upload this and update this post.

Wow Maki, you're a god of hacking man. The most strange thing (and the one that I'm most curious) is the fact that the scene is constantly changing (probably some pointer to several .x files will do the trick) and the deformation.
I tried replacing the 2nd witch as you said, but doesn't get replaced 3 times as you said but just once. Here's what I have on my notes about death code for 1st witch (it's executed when the witch is killed) on its AI script:

Code: [Select]

02 63 C8 05 09 00 07 00 [ // if ($63>=9)
   08                  // unknown OPCODE but almost sure it's a 1byte OPCODE
   33                  // the same as above
   1F 04               // LOAD enemy in slot 04, in that case wormlike witch.
   23 5D 00
]{
   02 62 C8 00 01 00 4E 00 [          //if ($62==1)
      0F 62 00                   //$62 = 0
      13 63 01                   //13 seem to be add operator so -> $13 = $13 + 1
      08                         
      02 DD C8 00 03 00 1A 00 [      //if $DD == 3
         02 60 C8 05 06 00 09 00 [      //if $60 >= 6 ($60 is where the game stores how many times you killed 1st witch(pink/purple one))
            0F 61 04                // $61 = 4
            33                      //
            1F 01                   // LOAD enemy on slot 1, the (red/yellow) 2nd witch in that case
            23 06 00
         ]{                        //ELSE
            0F 61 06                // $61 = 6
            33                      //
            1F 03                   //LOAD enemy on slot 3, in an unmodified scene.out, the 1st witch.
         }
         23 22 00
      ]{                        //ELSE
         02 DD C8 00 06 00 1A 00 [      //if ($DD = 6)
            02 60 C8 05 06 00 09 00 [      //if ($60>=6)
               0F 61 05                   // $61 = 5
               33                         
               1F 02                      //load the second witch from slot 02
               23 06 00   
            ]{                        //ELSE
               0F 61 03                   //$61 = 3
               33
               1F 00                      //LOAD 1st witch from slot 00
            }   
            23 00 00
         ]
      }   
      23 07 00
   ]
   0F 62 01                            //$62 = 01
   13 63 01                            //$63+1
   08
}
00 00 00 00

The game stores the 1st witch kill count on variable $60. Still doesn't know what is stored on $63 or why is checked if its mayor/equal than 9, maybe if I extract and analyze the 2nd witch code we'll know it, but all this is old stuff I had on my pc. I'll do it this night or tomorrow. $DD seem to store an identifier to know if the witch is the one from slot 0 or the one from slot 3, but not sure at 100%. I also have the turn code on a txt, but didn't paste it here since it hasn't much to do with the summoning control. Just ask for it and I'll paste it too.

EDIT:
Just extracted and formated the script for 2nd witch entrance and death. Also corrected some stuff on the 1st sorceress code. I located $60 on memory (FF8_ES.exe+192A1E0). That's what we have:

Code: [Select]

//Init code

13 60 01                // $60+1
02 62 C8 00 00 00 06 00[   // if ($62 == 0)
   0F 62 01                // $62 = 01
   23 03 00
]{                     // ELSE
   0F 62 02                // $62 = 02
}
04 C8 0C 01             // ability 010C on self (it's the entrance animation, no more, no less)
02 60 C8 00 07 00 06 00 [   // if ($60 == 7)
   0E DC 07                //DC = 7   
   23 00 00
]
02 60 C8 00 08 00 06 00 [   // if ($60 ==
   0E DC 08                // $DC = 8
   23 00 00
]
02 60 C8 00 09 00 06 00 [   // if ($60 == 9)
   0E DC 09                // $DC = 9
   23 00 00
]
02 60 C8 00 0A 00 06 00 [   // if ($60 == 0xA)
   0E DC 0A                // $DC = 0xA
   23 00 00
]
02 61 C8 00 04 00 09 00 [   // if ($61 == 4)
   0F 61 00                // $61 = 0
   0E DD 04                // $DD = 4
   23 06 00
]{                     //ELSE
   0F 61 00                // $61 = 0
   0E DD 05
}
00 00 00 00 00


//Death Code

02 63 C8 05 09 00 07 00 [   // if ($63 >= 9)
   08
   33
   1F 04                   //LOAD enemy 4 (wormlike sorceress)
   23 3D 00
]
02 62 C8 00 01 00 2E 00 [   // if ($62 == 1)
   0F 62 00                // $62 = 0
   13 63 01                // $63 + 1
   08
   02 DD C8 00 04 00 0A 00 [   // if (DD == 4)
      0F 61 05                // $61 = 5
      33
      1F 02                   // LOAD slot 2 (2nd witch)
      00
      23 12 00
   ]{
      02 DD C8 00 05 00 0A 00 [//ELSE
         0F 61 04             // $61 = 4
         33       
         1F 01                // LOAD slot 1 (2nd witch too)
         00
         23 00 00
      ]
   }
   23 07 00
]{                     //ELSE ($62 != 1)
   0F 62 01                // $62 = 1
   13 63 01                // $63 + 1
   08
}
00 00 00 00

The most important fact here is the ability they do when they become active (number 01) corresponding to ability 0x13F. I bet that it's the ability itself the one which deforms and changes the scenario. I also made a liitle experiment. I located $60 in memory (FF8_ES.exe+192A1E0) and edited it (when it was 5 I set it on 3) and so, I fought 2 extra pink sorceress. That way, I reached the worm sorceress scenario before fighting herself(still had to kill 2 extra red witches). The ground didn't shake as usual. When the next sorceress came in, the scenario changed again. I eventually fought the worm on Esthar area, and now the ground did shake, so we can assume that all effects are triggered with enemy abilities. Actually, the same happens with Ultimecia when she summons Griever, all the summoning and scenario change stuff are triggered by an ability (you can see it putting her in any encounter and killing her)

[Maki]

I totally forgot about my old video:

https://www.youtube.com/watch?v=DK1xyz5aAIU&feature=em-upload_owner

BTW>
I updated wiki on:
b0wave.dat: http://wiki.qhimm.com/view/FF8/FileFormat_b0wave
Also the time compression effect is started by map or by engine or I don't know now. I tried my best to analyze opcode to find how does the engine know where does the camera start, but I fail everytime. Every file in FF8 is divided to sectors or organized somewhat, but on battle stages there is weird data of length: 0x5d4 or 0x5d8 and rarely in 0xEDF and other. I'll try to search for pointers or anything that could point me to where is pointer to camera section. Also I cracked a bit G.F. environment geometry (Shiva cone, ifrit ball, cerberus cemetery level). There are at least THREE different polygon types and some which are just leftovers/untested/probably wrong (Noted with BAD?):

Code: [Select]

        private Dictionary<UInt16,int> PolygonType = new Dictionary<ushort, int>
        {
            { 0x7, 20},     //BAD?
            { 0x8, 20}, //OK
            { 0x9, 28}, //OK
            {0x10, 20},     //BAD?
            {0x12, 24}, //OK
            {0x13, 36}, //OK
            {0x18, 0x18}    //24 BAD?
        };
uint16 is how it's indicated in code and key value is how much bytes is this polygon. Vertices data is after all polygon data.
I'll begin to update wiki on Battle stage camera section and MAG files ASAP when I finish my code. I have completed algorithm on resolving vertices but only in code.
G.F. environment file structure shares structure with some magic files like blizzard. Some files use modified a bit structure, but some of them are completely different (or look like it). So, for now I think there are three different MAG geometry files and at least 4-5 different polygon types (Probably just like in FFIX [see wiki])


JeMaCheHi,
You could write a software for code(AI script) decompile. :3

[JeMaCheHi]

So glad my decompiled script was useful! It's remarkable the fact that the scenario stops deformation after worm sorceress appearance... at some point. Also, the background continues spinning on every other stage. So... we still don't know how the engine manages that ah?

JeMaCheHi,
You could write a software for code(AI script) decompile. :3

Yeah, that was my intention, but first I need to decypher every opcode used in scripts, since each one has a certain number of bytes after, and there are a bunch of them that are being specially hard to figure them out. However, now I started with school stuff and have not that much free time... Furthermore, I have no idea about how to do a compiler/decompiler. But it will be eventually done, ... maybe with a bit of teamwork it would be easier.

[Maki]

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]

12 00 00 01 24 00
12 00 01 01 25 00
is:
f 18 256 36
f 18 257 37

I took the smallest object I could find (Some leviathan rock or idk) and inspected it. See for yourself:

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]

1 0
2 8
3 10
4 18
5 20
6 28
7 30
8 38
9 40
10 48
11 50
12 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]

v 0 0.506 0
v -0.5445 0.016 0.177
v -0.215 0.183 -0.296
v 0 0.191 0.463
v 0.305 0.355 0.0975
v 0.3365 -0.1285 -0.463
v -0.5445 -0.286 -0.177
v 0 -0.286 -0.5725
v -0.058 -0.286 0.754
v 0.3365 -0.286 0.754
v 0.463 -0.286 -0.177
v 0 -0.2995 0
f 1 2 3
f 1 4 3
f 1 5 4
f 1 6 5
f 1 3 6
f 7 8 3
f 7 3 2
f 9 7 2
f 9 2 4
f 10 9 4
f 10 4 5
f 11 10 5
f 11 5 6
f 8 11 6
f 8 6 3
f 12 8 7
f 12 7 9
f 12 9 10
f 12 10 11
f 12 11 8
Saved and put into 3DS Max:

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.

[JWP]

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]

Bit    7  6  5  4  3  2  1  0
Data   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.

[Maki]

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:


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


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

UPDATE3:
Damn yes!


UPDATE4:
Okay. Everything done! :3 Now the UVs... ?

[kaspar01]

Oh my Gold Maki.. do you even know how sexy you are? XD