Difference between revisions of "BOL (File Format)"
(Rotation vectors are all stored as integers. They seem to be more some kind of direction vector. I might add more details if I figure out more.) |
(Added information on how rotation vectors work and how to calculate an angle. Source: My own research. Sorry for editing twice...) |
||
Line 388: | Line 388: | ||
=== Section 10 === | === Section 10 === | ||
+ | |||
+ | == Rotation Vector == | ||
+ | |||
+ | The Mario Kart: Double Dash!! rotation vector consists of 3 Int32 values. The first two values form a two-dimensional direction vector with the first pointing in x-direction and the second pointing in z-direction. The third value represents the length of the vector (it is quite inaccurate, though). Its value is usually 0x27100000 (655360000 in base 10). Using trigonometry, the rotation angle around the y-axis can be calculated as follows: | ||
+ | |||
+ | angle (in degree) = sign(value1 + 0.5) * arccos(value2 / value3) * (180 / pi) | ||
[[Category: File Format]] | [[Category: File Format]] |
Revision as of 04:04, 15 November 2015
A BOL file contains information about a course's setup. A variant of the BOL format has been used in Mario Kart DS and Mario Kart Wii. This article describes the Mario Kart: Double Dash!! BOL format.
File Header
Offset | Size | Description |
---|---|---|
0x00 | 4 | File magic, always '0015' in ASCII |
0x1A | 2 | Number of Section 1 entries. |
0x1C | 2 | Number of Section 2 groups. |
0x1E | 2 | Number of Section 5 entries. |
0x20 | 2 | Number of Section 7 entries. |
0x22 | 2 | Number of Section 8 entries. |
0x24 | 2 | Number of Section 3 routes. |
0x40 | 4 | Start of the file, always 0x00. |
0x44 | 4 | Section 1 offset, always 0x7C. |
0x48 | 4 | Section 2 offset. |
0x4C | 4 | Section 3 offset. |
0x50 | 4 | Section 4 offset. |
0x54 | 4 | Section 5 offset. |
0x58 | 4 | Section 6 offset. |
0x5C | 4 | Section 7 offset. |
0x60 | 4 | Section 8 offset. |
0x64 | 4 | Section 9 offset. |
0x68 | 4 | Section 10 offset. |
0x6C | 4 | Length of the file in bytes. |
0x70 | 12 | Padding. |
0x7C | End of this file header |
Sections
The file consists of a series of sections, each describing a different aspect of the course setup:
Section 1
Section 1 describes enemy/item points; the routes of CPU racers and items such as red shells. The CPU racers and items attempt to follow the path described by each group of points. Each entry is a 0x20 byte structure as follows:
Offset | Size | Description |
---|---|---|
0x00 | float[3] | A 3D position vector of the position. |
0x0C | short | Point setting. |
0x0E | short | Link of current group if start of group.
Link to next group if end of group. Otherwise -1. |
0x10 | float | Scale. |
0x14 | short | Group setting if start of group. Otherwise 0.
|
0x16 | byte | Group. |
0x17 | byte | Point setting. |
0x18 | byte[8] | Padding. |
Section 2
The first part of Section 2 describes checkpoint grouping; how the routes of checkpoints link together. Each entry is a 0x14 byte structure as follows:
Offset | Size | Description |
---|---|---|
0x00 | short | Point length. The number of points in this group. |
0x02 | short | Group link. |
0x04 | short[4] | Previous group. The indices of up to 4 group links that follow to this one. Unneeded slots are set to value -1. |
0x0C | short[4] | Next group. The indices of up to 4 group links to follow after this one. Unneeded slots are set to value -1. |
The second part of Section 2 describes checkpoints; the routes players must follow to count laps. The racers must follow the path described by each group of points (as determined by the first part of Section 2). Each entry is a 0x1C byte structure as follows:
Offset | Size | Description |
---|---|---|
0x00 | float[3] | A 3D position vector of the start of the check point line. |
0x0C | float[3] | A 3D position vector of the end of check point line. |
0x18 | byte[4] | Padding. |
Section 3
Section 3 describes routes; these are routes for many things including cameras and objects. Each entry is a 0x10 byte structure as follows:
Offset | Size | Description |
---|---|---|
0x00 | short | Point length. The number of Section 4 entries in this group. |
0x02 | short | Point start. The index of the first Section 4 entry in this group. |
0x04 | byte[12] | Padding. |
Section 4
Section 4 describes route points. Each entry is a 0x20 byte structure as follows:
Offset | Size | Description |
---|---|---|
0x00 | float[3] | A 3D position vector of the route position. |
0x0C | byte[20] | Padding. |
Section 5
Section 5 decribes objects. Each entry is a 0x40 byte structure as follows:
Offset | Size | Description |
---|---|---|
0x00 | float[3] | A 3D position vector of the start position. |
0x0C | float[3] | A 3D scale vector of the start position. |
0x18 | int[3] | A 3D rotation vector of the start position? |
0x24 | short | Object ID |
0x26 | short | Route ID. Links to Section 3. 0xFFFF if no route is used. |
0x28 | byte[24] | Unknown. Probably object settings. |
Section 6
Section 6 describes kart points; the starting positions of racers. Each entry is a 0x28 byte structure as follows:
Offset | Size | Description |
---|---|---|
0x00 | float[3] | A 3D position vector of the start position. |
0x0C | float[3] | A 3D scale vector of the start position. |
0x18 | int[3] | A 3D rotation vector of the start position? |
0x24 | byte | 0: Pole position is left. 1: Pole position is right. |
0x25 | byte | Player ID. In courses with multiple start positions (such as battle courses), this determines which players start here. Otherwise set to 0xFF to set all players start positions to this point. |
0x26 | short | Padding. |
Section 7
Section 7 describes areas; used to determine for example which camera to use. Each entry is a 0x38 byte structure as follows:
Offset | Size | Description |
---|---|---|
0x00 | float[3] | A 3D vector of the area's position. |
0x0C | float[3] | A 3D vector of the area's scale. |
0x18 | int[3] | A 3D vector of the area's rotation. |
0x24 | short | Unknown. |
0x26 | short | Unknown. |
0x28 | byte[16] | Unknown. |
Section 8
Section 8 describes Cameras. Each entry is a 0x48 byte structure as follows:
Offset | Size | Description |
---|---|---|
0x00 | float[3] | A 3D position vector of the first view point |
0x0C | int[3] | A 3D rotation vector |
0x18 | float[3] | A 3D position vector of the second view point |
0x24 | float[3] | A 3D position vector of the third view point |
0x30 | byte | Unknown |
0x31 | byte | Camera Type |
0x32 | ushort | Start Zoom |
0x34 | short | Camera Duration (in 1/60 second units) |
0x36 | ushort | Unknown |
0x38 | ushort | Unknown |
0x3A | ushort | Unknown |
0x3C | short | Linked Route ID (-1 if none) |
0x3E | ushort | Route Speed? |
0x40 | ushort | End Zoom |
0x42 | short | Next Camera (-1 if none) |
0x44 | char[4] | Camera Name? (Most of the time "null" or "para") |
Section 9
Section 9 describes Jugem points; the respawn positions. Each entry is a 0x20 byte structure as follows:
Offset | Size | Description |
---|---|---|
0x00 | float[3] | A 3D position vector of the respawn position. |
0x0C | int[3] | A 3D rotation vector of the respawn position? |
0x18 | short | Respawn ID? |
0x1A | short | Unknown |
0x1C | short | Unknown |
0x1E | short | Unknown |
Section 10
Rotation Vector
The Mario Kart: Double Dash!! rotation vector consists of 3 Int32 values. The first two values form a two-dimensional direction vector with the first pointing in x-direction and the second pointing in z-direction. The third value represents the length of the vector (it is quite inaccurate, though). Its value is usually 0x27100000 (655360000 in base 10). Using trigonometry, the rotation angle around the y-axis can be calculated as follows:
angle (in degree) = sign(value1 + 0.5) * arccos(value2 / value3) * (180 / pi)