Difference between revisions of "Monochrome map (Worms 2)"
From Worms Knowledge Base
(Supposition for what the seeded terrain data might be, with a note that testing is required.) |
(Expanded more on how the file is actually stored.) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{ParentArticle|[[File formats]]}} | {{ParentArticle|[[File formats]]}} | ||
| − | Worms 2 maps (monochrome maps) are [[w:Gzip|gzip]]ped binary files, in most cases with invalid CRCs (so gzip itself cannot be used to extract them), apart from purely-seeded terrains. After a header containing the map parameters, the map data follows as a 1-bit-per-pixel bitmap. This will convert the data into a .bmp: http://tim32.org/~muzer/Delphi.dpr (made by CyberShadow) | + | Worms 2 maps (monochrome maps) are [[w:Gzip|gzip]]ped binary files, in most cases with invalid CRCs (so gzip itself cannot be used to extract them), apart from purely-seeded terrains. After a header containing the map parameters, the map data follows as a 1-bit-per-pixel bitmap, with the most significant byte being the leftmost pixel, and moving left-to-right, top-to-bottom. This will convert the data into a .bmp: http://tim32.org/~muzer/Delphi.dpr (made by CyberShadow) |
The header has been partially reversed. This has not been tested on too many levels, so it should be taken with a pinch of salt: | The header has been partially reversed. This has not been tested on too many levels, so it should be taken with a pinch of salt: | ||
| Line 25: | Line 25: | ||
| 0x0A | | 0x0A | ||
| 4 | | 4 | ||
| − | | | + | | The map complexity #1, from 0x00 (min) to 0x64 (max). This cannot be user-edited (without hexediting the file) but values appear to be in this range for generated maps. Represented as a 32-bit little-endian integer. |
|- | |- | ||
| 0x0E | | 0x0E | ||
| 4 | | 4 | ||
| − | | | + | | The map complexity #2, from 0x00 (min) to 0x64 (max). This cannot be user-edited (without hexediting the file) but values appear to be in this range for generated maps. Represented as a 32-bit little-endian integer. |
|- | |- | ||
| 0x12 | | 0x12 | ||
| Line 72: | Line 72: | ||
|} | |} | ||
| − | If the terrain is purely seeded, then other than what was mentioned above, after the last string, there is a lot more data, | + | If the terrain is purely seeded, then other than what was mentioned above, after the last string, there is a lot more data. This data is: |
| + | * 4 bytes (32-bit, little-endian integer) describing the size of the remaining portion of the file (NOT including this integer). | ||
| + | * 4 bytes (32-bit, little-endian integer) describing the size of the remaining portion of the file (NOT including this or the next integer - WTF?). | ||
| + | * 4 bytes (32-bit, little-endian integer) describing the uncompressed size of the remaining portion of the file (NOT including this integer). | ||
| + | * A thumbnail for the map file using run-length encoding in the following format, going from left-to-right, top-to-bottom, in one bit-per-pixel format (with bit order being the most significant bit represents the leftmost pixel): | ||
| + | ** Firstly is a byte specifying how the next bytes are to be interpreted. | ||
| + | *** If the byte is under 0x80, the number given will be the number of bytes interpreted. These will be used to draw the map. | ||
| + | *** If the byte is over 0x80, the number given - 0x80 will be the number of times the next one byte is repeated. | ||
| + | ** Then come the data bytes, as required. | ||
| + | ** This is repeated until the whole map is drawn. If the map is over- or under-drawn (ie too many or too few bytes), Worms 2 will crash. | ||
{{stub}} | {{stub}} | ||
Latest revision as of 13:56, 13 October 2012
(Up to File formats)
Worms 2 maps (monochrome maps) are gzipped binary files, in most cases with invalid CRCs (so gzip itself cannot be used to extract them), apart from purely-seeded terrains. After a header containing the map parameters, the map data follows as a 1-bit-per-pixel bitmap, with the most significant byte being the leftmost pixel, and moving left-to-right, top-to-bottom. This will convert the data into a .bmp: http://tim32.org/~muzer/Delphi.dpr (made by CyberShadow)
The header has been partially reversed. This has not been tested on too many levels, so it should be taken with a pinch of salt:
| Offset | Length | Description |
|---|---|---|
| 0x00 | 2 | 0x01 0x01 if the terrain is open, 0x02 0x02 if the terrain is cavern, 0x00 0x01 if the terrain is <Random> (chooses randomly between them when the game starts, IIRC). |
| 0x02 | 4 | Similar to below but with the terrain generation seed, not the object seed. If the seed cannot be represented like this, see the first string slot. |
| 0x06 | 4 | The object generation seed in hex, little-endian (so if the code in game is 05437645, this will read 45764305). If the seed cannot be represented like this, see the first string slot. |
| 0x0A | 4 | The map complexity #1, from 0x00 (min) to 0x64 (max). This cannot be user-edited (without hexediting the file) but values appear to be in this range for generated maps. Represented as a 32-bit little-endian integer. |
| 0x0E | 4 | The map complexity #2, from 0x00 (min) to 0x64 (max). This cannot be user-edited (without hexediting the file) but values appear to be in this range for generated maps. Represented as a 32-bit little-endian integer. |
| 0x12 | 4 | The object count, from 0x00 (min) to 0x64 (max), represented as a 32-bit little-endian integer (presumably), which is odd since only the first byte is required. |
| 0x16 | Varies | Pascal-style string with the terrain seed. (I assume the specifics of when and when not this exists is similar to below, but since the game does not generate seeds for its own hex format, it's hard to judge whether or not this is the case) |
| Varies | Varies | Pascal-style string with the object generation seed, if it cannot be represented in 4 hex bytes. If it can be represented in 4 hex bytes, this is empty (length byte is 0x00 and it goes straight onto the next string). It is unknown whether this is converted into the hex using some algorithm, or if the hex is completely ignored if this is present, though I suspect it is the former, since the hex changes. |
| Varies | Varies | Pascal-style string with the name of level. In most cases, this will be the same as the filename but without the .lev suffix. |
| Varies | 1 | 0x01 if the terrain is edited, 0x00 if seeded and not edited |
| Varies | Varies | Pascal-style string with the name of the level style. Exactly as displayed in the drop-down. For the benefit of those without Worms 2, they can be: ART CHEESE CONSTRUCTION GULF HELL MANHATTAN MEDIEVAL PIRATE SNOW SPORTS TIME and, with the OSSETT cheat (which gives extra levels from the original Worms), you can also have -BEACH -DESERT -FARM -FOREST -HELL (note the hyphens) |
| Varies | Varies | Pascal-style string with the name of the water colour, with an initial captital letter, and the rest lower case. They can be: Red Blue Green Purple Yellow . |
| Varies | 2 | 0x80 0x07 - map width in pixels, little-endian (1920 = 0x780) |
| Varies | 2 | 0xB8 0x02 - map height in pixels, little-endian (696 = 0x2B8) |
| Varies | 167040 | Data |
If the terrain is purely seeded, then other than what was mentioned above, after the last string, there is a lot more data. This data is:
- 4 bytes (32-bit, little-endian integer) describing the size of the remaining portion of the file (NOT including this integer).
- 4 bytes (32-bit, little-endian integer) describing the size of the remaining portion of the file (NOT including this or the next integer - WTF?).
- 4 bytes (32-bit, little-endian integer) describing the uncompressed size of the remaining portion of the file (NOT including this integer).
- A thumbnail for the map file using run-length encoding in the following format, going from left-to-right, top-to-bottom, in one bit-per-pixel format (with bit order being the most significant bit represents the leftmost pixel):
- Firstly is a byte specifying how the next bytes are to be interpreted.
- If the byte is under 0x80, the number given will be the number of bytes interpreted. These will be used to draw the map.
- If the byte is over 0x80, the number given - 0x80 will be the number of times the next one byte is repeated.
- Then come the data bytes, as required.
- This is repeated until the whole map is drawn. If the map is over- or under-drawn (ie too many or too few bytes), Worms 2 will crash.
- Firstly is a byte specifying how the next bytes are to be interpreted.
