Difference between revisions of "FF7/WorldMap Module"
my_wiki>Cyberman (→Normal) |
my_wiki>Aali (→Preamble) |
||
Line 3: | Line 3: | ||
The following was originaly described by Tonberry, in qhimm's forum. It was | The following was originaly described by Tonberry, in qhimm's forum. It was | ||
completed by Ficedula sometimes later, who reversed texture data. | completed by Ficedula sometimes later, who reversed texture data. | ||
+ | |||
+ | Additions in ''italics'' by Aali | ||
=== Two formats === | === Two formats === | ||
Line 8: | Line 10: | ||
BOT and MAP files are similar; BOT files are redundant and look like | BOT and MAP files are similar; BOT files are redundant and look like | ||
optimized versions of the corresponding MAP files. | optimized versions of the corresponding MAP files. | ||
+ | |||
+ | ''MAP file follows the structure described below and is used to load single blocks on demand. BOT file also contains the same blocks but arranged to speed up initial load time by storing each block and 3 of its neighboring blocks together. For instance, the data stored for the first 2 blocks is (numbers refer to the MAP layout below): 0,1,9,10 1,2,10,11. This pattern repeats up to block #62. Replacement blocks 63-68 are divided in groups for each replacement, i.e. block 64 and 65 are part of the same group since they both belong to the Ultima Weapon crater. These groups are then stored using the same algorithm as above, each 4-block group containing a replaced block is written out again. 1-block replacements thus add 4*4 blocks to the .BOT file while 2-block replacements add 6*4 blocks. Replacements are to be made '''in order''', when writing the data for the Ultima Weapon crater the Temple of the Ancients should be gone and so on. All of this adds up to 63*4 + 4*4 + 6*4 + 4*4 + 6*4 = 332 blocks.'' | ||
=== Content === | === Content === |
Revision as of 07:19, 25 October 2010
Contents
Preamble
The following was originaly described by Tonberry, in qhimm's forum. It was completed by Ficedula sometimes later, who reversed texture data.
Additions in italics by Aali
Two formats
BOT and MAP files are similar; BOT files are redundant and look like optimized versions of the corresponding MAP files.
MAP file follows the structure described below and is used to load single blocks on demand. BOT file also contains the same blocks but arranged to speed up initial load time by storing each block and 3 of its neighboring blocks together. For instance, the data stored for the first 2 blocks is (numbers refer to the MAP layout below): 0,1,9,10 1,2,10,11. This pattern repeats up to block #62. Replacement blocks 63-68 are divided in groups for each replacement, i.e. block 64 and 65 are part of the same group since they both belong to the Ultima Weapon crater. These groups are then stored using the same algorithm as above, each 4-block group containing a replaced block is written out again. 1-block replacements thus add 4*4 blocks to the .BOT file while 2-block replacements add 6*4 blocks. Replacements are to be made in order, when writing the data for the Ultima Weapon crater the Temple of the Ancients should be gone and so on. All of this adds up to 63*4 + 4*4 + 6*4 + 4*4 + 6*4 = 332 blocks.
Content
- WM0 is the above water map.
- WM2 is the underwater (submarine) map.
- WM3 is the snowstorm map.
MAP Format
File Structure
A worldmap file is divided in sections of 0xB800 bytes, each section representing a square block of the map.
Map Block
Each block consists in 16 meshes, organized in a grid-like fashion:
0 | 1 | 2 | 3 |
4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 |
A block is recorded following the structure (all pointers are expressed in bytes relative to offset 0 of block):
For each m in 16 meshes:
size | description |
---|---|
4 bytes | Pointer to compressed data for mesh m |
Followed by, for each m in 16 meshes:
size | description |
---|---|
variable | Compressed data for mesh m |
The data for each mesh is independently compressed using LZSS, so the first 4 bytes are the size in bytes of the compressed data and the rest is the compressed data itself.
WM0.MAP
wm0.map contains 68 blocks. The first 63 of them are arranged in a grid-like fashion, made of 7 rows of 9 columns, like this:
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 |
36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 |
45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 |
54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 |
The last 5 meshes 63, 64, 65, 66, 67 and 68 replaces meshes 50, 41, 42, 60, 47 and 48 (respectively), according to the story of the game.
Mesh Structure
A worldmap mesh is recorded like this:
Header
size | description |
---|---|
2 bytes | Number of triangles |
2 bytes | Number of vertices |
typedef struct { uint16 NumberOfTriangles; uint16 NumberOfVertices; } WorldMeshHeader;
Triangle
size | description |
---|---|
1 byte | Index of vertex 0 of triangle t |
1 byte | Index of vertex 1 of triangle t |
1 byte | Index of vertex 2 of triangle t |
1 byte | Walkmap status of triangle t (see below) |
1 byte | Coordinate u in texture for vertex 0 |
1 byte | Coordinate v in texture for vertex 0 |
1 byte | Coordinate u in texture for vertex 1 |
1 byte | Coordinate v in texture for vertex 1 |
1 byte | Coordinate u in texture for vertex 2 |
1 byte | Coordinate v in texture for vertex 2 |
2 bytes | Texture (see below) |
typedef struct { uint8 Vertex0Index; uint8 Vertex1Index; uint8 Vertex2Index; uint8 WalkabilityInfo; uint8 uVertex0, vVertex0; uint8 uVertex1, vVertex1; uint8 uVertex2, vVertex2; uint16 TextureInfo; } WorldMeshTriangle;
Vertex
size | description |
---|---|
2 bytes | Coordinate x of vertex v (signed) |
2 bytes | Coordinate y of vertex v (signed) |
2 bytes | Coordinate z of vertex v (signed) |
2 bytes | (Unknown: Coordinate w of vertex v?) |
typedef struct { int16 X, Y, Z; uint16 Unused; // fill to fit structure to 32bit boundry } VertexType;
Normal
size | description |
---|---|
2 bytes | Coordinate x of normal for vertex v |
2 bytes | Coordinate y of normal for vertex v |
2 bytes | Coordinate z of normal for vertex v |
2 bytes | (Unknown: Coordinate w of normal for vertex v? "Always 0") |
typedef struct { int16 X, Y, Z; uint16 Unused; // fill to fit structure to 32bit boundry } NormalType;
structures added by Cyberman 13:43, 10 Jan 2007 (CST)
Walkmap
code | description |
---|---|
0x23 | Deep sea (can't land highwind, water spray when flying low) |
0x22 | No sea spray from highwind, can't land |
0x21 | No sea spray from highwind, can't land |
0x20 | No sea spray, can land and walk |
Observe that 0x21 and 0x22 describe the same status; it is thought that it may differentiate chocobos' behavior.
Texture
The lower 9 bits contain a texture number (0-511, but only 0-281 appear to be used). The text files in the Reeve download show how each number maps to one (or more) .TEX files within WORLD_US.LGP (see also LGP Archives). The upper bits have something to do with texture coordinate mapping.
BOT format
(FIXME)