CHOCOBO.WAT is a binary file. It contains two sets of data describing the track and events occuring during the chocobo racing mini-game. We first have the 'LONG' course then the 'SHORT' course.
They both have the same structure which is:
;----------
DW num_obj
[struct t_chocobo_unknown_18(size 0x18)] (num_obj times)
DB '{L|S}GUIDE'
[struct t_chocobo_data_GUIDE(size 8)] (num_obj times)
DB '{L|S}MAPPOINTE'
DW num_obj
[short(size 2)] (num_obj times)
DB '{L|S}MAPTABLE'
DW num_obj
[int(size 4)] (num_obj times)
DB '{L|S}DOMEG3'
DW num_obj
[struct t_chocobo_data_DOMEG3(size 0x24)] (num_obj times)
DB '{L|S}DG3'
DW num_obj
[struct t_chocobo_data_DG3(size 0x1c)] (num_obj times)
//LDG3 padded with EXE bits
DB '{L|S}DG4'
DW num_obj
[struct t_chocobo_data_DG4(size 0x28)] (num_obj times)
DB '{L|S}SPRITE'
DW num_obj
[struct t_chocobo_data_SPRITE(size 0x16)] (num_obj times)
[pad (0x28 - 0x16) * num_obj]
And then we have:
DB 'SHORT' ;if after the 'LONG' section
or
DB 'END' ;if after the 'SHORT' section
;----------
.{L|S} means the character 'L' or 'S' for Long and Short
.16-bit words are little endian
All words indicating the number of object of each section are ignored by FF7's main program: they are hard coded in the function that loads CHOCOBO.WAT.
- About the padding
The section 'LDG3' contains only 0x1eb0 objects that make sense(while there is space for 0x2e49).
The remaining memory is filled with 0s and then with data that seems to come directly from and executable's run-time memory. Section 'SDG3' doesn't have this problem.
The funny thing is, this data contains the following strings:
LGUIDE
LMAPPOINTER
LMAPTABLE
LDOMEG3
LDG3
LDG4
LSPRITE
SHORT
SGUIDE
SMAPPOINTER
SMAPTABLE
SDOMEG3
SDG3
SDG4
SSPRITE
END
My guess is that we are looking at parts from the conversion executable (the one that generates the CHOCOBO.WAT file).
.When writing the tag "MAPPOINTER" to the file, one character was omited so the tag became "MAPPOINTE".
.The section 'LDG3' was allocated less space in memory than what was written to disk. So the memory immediately following this section was written to the file, and it seems that this memory was a part of the exe's initialized segment.
.Concerning the section LSPRITE and SSPRITE, there seems to have been another error: in this case, while the memory contained objects of size 0x16, they where written to the file with a command taking them as 0x28 byte-long objects. That's why we found some bits of the EXE file at the end of these sections too.
When I have more time, I will try to be more specific about the content of the structures.
No comments:
Post a Comment