Difference between revisions of "BATTLE.BIN Model Data"

From Final Fantasy Hacktics Wiki
Jump to navigation Jump to search
m
Line 1: Line 1:
There is secondary effect data that seems to be structured as if it were an external file, but is baked into the BATTLE.BIN file.
+
There is secondary effect data that seems to be structured as if it were an external file, but is baked into the BATTLE.BIN file. seems to be for constructing models out of polygons?
 
==Section 1==
 
==Section 1==
 
  the first section is dedicated to address pointers? may be split into 2 sections? using the first table as an example:
 
  the first section is dedicated to address pointers? may be split into 2 sections? using the first table as an example:
Line 9: Line 9:
 
  0000000c: 01 e8 00 00|13 00 00 00|80 02 00 00|13 00 00 00|1c 00 00 00|11 00 00 00|00 00 00 00
 
  0000000c: 01 e8 00 00|13 00 00 00|80 02 00 00|13 00 00 00|1c 00 00 00|11 00 00 00|00 00 00 00
 
*DD:
 
*DD:
  Used as a pointer relative to 0x0000000c. points to a table of XY and Z0 vectors, that is EE long.
+
  Used as a pointer relative to 0x0000000c. points to a table of raw vectors EE entries long.
 
*FF:
 
*FF:
 
  Used as a pointer relative to 0x0000000c. unsure where it points, but I can guess the data is GG table entries long.
 
  Used as a pointer relative to 0x0000000c. unsure where it points, but I can guess the data is GG table entries long.
 
*HH:
 
*HH:
  Used as a pointer relative to 0x0000000c. points to the first table after this set of pointer data, that is II long. contains values relevant to vector data?
+
  Used as a pointer relative to 0x0000000c. points to palette data per polygon, that is II entries long.
 
*JJ  
 
*JJ  
 
  does not seem to be used?
 
  does not seem to be used?
Line 27: Line 27:
 
  finally, it is cross multiplied by the camera rotation matrix, and translated by the camera translation matrix.
 
  finally, it is cross multiplied by the camera rotation matrix, and translated by the camera translation matrix.
 
  {R4 x VE + T5} x {1/4096 * [R6 x V7]} x RC + TC
 
  {R4 x VE + T5} x {1/4096 * [R6 x V7]} x RC + TC
  It is essentially the raw vector matrices of the effect.
+
  It is essentially the raw points of the model.
  
 
==Section HH==
 
==Section HH==
 
  a Table related to vector data that is, admittedly, yet to be tracked down; HH points to this table. the following can be said about it though:
 
  a Table related to vector data that is, admittedly, yet to be tracked down; HH points to this table. the following can be said about it though:
           AA BB CC DD|Vector 1? |Vector 2? |Vector 3? |Vector 4? |Vector pointers?      |AA BB CC DD|
+
           AA BB CC DD|Palette 1  |Palette 2  |Palette 3  |Palette 4  |Vector pointers?      |AA BB CC DD|
 
  HH:      08 06 01 39|56 56 56 39|bd bd c1 00|3e 3e 3e 00|a1 a1 a6 00|00 00 01 00 03 00 02 00|08 06 01 39|...
 
  HH:      08 06 01 39|56 56 56 39|bd bd c1 00|3e 3e 3e 00|a1 a1 a6 00|00 00 01 00 03 00 02 00|08 06 01 39|...
 
  AA BB CC are unknown.
 
  AA BB CC are unknown.
 
*DD
 
*DD
  dictates how many vectors (?) should have their data loaded, and dictates the length of the table entry (0x39 has 4 vectors, and is 7 words long. 0x31 has 3 vectors, and is only 6 words long, 0x37 is 9 words, but seems to be a unique case.
+
  dictates No. corners of polygon, and hence the length of the table entry (0x39 has 4 points, and is 7 words long. 0x31 has 3 points, and is only 6 words long, 0x37 is 9 words, but seems to be a unique case.
  note: all this seems to be rather stupidly hard coded, reflect is the only effect with BB = 2, and also the only effect code with any compatibility with DD = 0x37. it also only uses 1 z0 vector to load some associated data. not sure why.
+
  note: all this seems to be rather stupidly hard coded, reflect is the only effect with BB = 2, and also the only effect code with any compatibility with DD = 0x37. it also only loads 1 palette from vram.
 
  also, BB = 0 is the only effect that has support for both 0x39 and 0x31, and BB = 1 only has support for 0x31. why even have this distinction here with such weird numbers?
 
  also, BB = 0 is the only effect that has support for both 0x39 and 0x31, and BB = 1 only has support for 0x31. why even have this distinction here with such weird numbers?
 
  it's like they wanted to do so much more.
 
  it's like they wanted to do so much more.
*Vectors
+
*Palettes
  Unsure exactly. the duplicate DD may only serve to preserve the intended effect in later routines, as AA BB CC DD is not stored in the finalization of [[Arrow, Throw stone, Reflect Vector-Matrix calculation]].
+
  seems to be VRAM palette IDs per corner of the polygon.
 
*Vector Pointers
 
*Vector Pointers
  Point to x0, y0 and z0 vectors in section DD. each vector is 1 word, and each set of vectors is 3 words long.
+
  point to the points in xyz space that make up the polygon with the selected palettes?

Revision as of 10:13, 4 November 2022

There is secondary effect data that seems to be structured as if it were an external file, but is baked into the BATTLE.BIN file. seems to be for constructing models out of polygons?

Section 1

the first section is dedicated to address pointers? may be split into 2 sections? using the first table as an example:
          AA AA AA AA|BB BB BB BB|CC CC CC CC
00000000: 41 00 00 00|00 00 00 00|01 00 00 00

I cannot be sure these 3 are pointers, because they aren't treated that way? unsure what their purpose is yet.

Section 1.5?
          DD DD DD DD|EE EE EE EE|FF FF FF FF|GG GG GG GG|HH HH HH HH|II II II II|JJ JJ JJ JJ
0000000c: 01 e8 00 00|13 00 00 00|80 02 00 00|13 00 00 00|1c 00 00 00|11 00 00 00|00 00 00 00
  • DD:
Used as a pointer relative to 0x0000000c. points to a table of raw vectors EE entries long.
  • FF:
Used as a pointer relative to 0x0000000c. unsure where it points, but I can guess the data is GG table entries long.
  • HH:
Used as a pointer relative to 0x0000000c. points to palette data per polygon, that is II entries long.
  • JJ
does not seem to be used?
Sections DD, FF, and HH may not be in sequential order in the file; in this case, HH is first.

Section DD

Contains exclusively vector data
         XX XX YY YY|ZZ ZZ 00 00|
DD:      32 00 32 00|00 00 00 00|...
these vectors are left cross multiplied by an input pre-calculation rotation matrix, then translated by an input pre-calculation translation matrix.
then they are right cross multiplied by another input rotation matrix scaled to another input vector matrix in x y and z.
finally, it is cross multiplied by the camera rotation matrix, and translated by the camera translation matrix.
{R4 x VE + T5} x {1/4096 * [R6 x V7]} x RC + TC
It is essentially the raw points of the model.

Section HH

a Table related to vector data that is, admittedly, yet to be tracked down; HH points to this table. the following can be said about it though:
         AA BB CC DD|Palette 1  |Palette 2  |Palette 3  |Palette 4  |Vector pointers?       |AA BB CC DD|
HH:      08 06 01 39|56 56 56 39|bd bd c1 00|3e 3e 3e 00|a1 a1 a6 00|00 00 01 00 03 00 02 00|08 06 01 39|...
AA BB CC are unknown.
  • DD
dictates No. corners of polygon, and hence the length of the table entry (0x39 has 4 points, and is 7 words long. 0x31 has 3 points, and is only 6 words long, 0x37 is 9 words, but seems to be a unique case.
note: all this seems to be rather stupidly hard coded, reflect is the only effect with BB = 2, and also the only effect code with any compatibility with DD = 0x37. it also only loads 1 palette from vram.
also, BB = 0 is the only effect that has support for both 0x39 and 0x31, and BB = 1 only has support for 0x31. why even have this distinction here with such weird numbers?
it's like they wanted to do so much more.
  • Palettes
seems to be VRAM palette IDs per corner of the polygon.
  • Vector Pointers
point to the points in xyz space that make up the polygon with the selected palettes?