Difference between revisions of "Monochrome map (Worms 2)"

From Worms Knowledge Base

Jump to: navigation, search
(Expanded more on how the file is actually stored.)
 
(19 intermediate revisions by 2 users 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). After a header containing the map parameters, the map data follows as a 1-bit-per-pixel bitmap. This will convert the data into .bmps: http://dump.thecybershadow.net/6c2fbb5e21fd07834c9ed7dd839fe9e8/draw.dpr
+
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:
  
−
0x00 and 0x01 are both 0x01 if open, and 0x02 if cavern. If it is set to <random>, it goes 0x00 0x01.
+
{| class="wikitable"
 +
|-
 +
! 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
 +
| [http://en.wikipedia.org/wiki/String_(computer_science)#Representations 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
 +
| [http://en.wikipedia.org/wiki/String_(computer_science)#Representations 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
 +
| [http://en.wikipedia.org/wiki/String_(computer_science)#Representations 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
 +
| [http://en.wikipedia.org/wiki/String_(computer_science)#Representations 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
 +
| [http://en.wikipedia.org/wiki/String_(computer_science)#Representations 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
 +
|}
  
−
Next four bytes (0x02 to 0x05) are unknown, probably the terrain generation seed in hex, little-endian.
+
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).
−
0x06 to 0x09 is the object generation seed in hex, little-endian (so if the code in game is 05437645, this will read 45764305)
+
* 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).
−
0x0A to 0x11 are unknown, but at least 0x0E appears to change, and 0x0A might. The rest appear to just be 0x00
+
* 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.
−
0x12 is the object count, a value from 0x00 (min) to 0x64 (max)
+
*** 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.
−
0x13 to 0x15 are unknown, presumed always 0x00
+
** 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.
−
There are 5 slots for Pascal-style ASCII (TODO: Find out which type) strings (length first, then the string). The first one starts at 0x16. After the 3rd one, there is an 0x01 (?, more investigation required). After the 5th one, there is an 0x80 0x07 0xB8 0x02 (again, more investigation required).
+
−
 
+
−
The string slots go as follows:
+
−
 
+
−
Unknown (probably the terrain seed)
+
−
 
+
−
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.
+
−
 
+
−
Name of level. In most cases, this will be the same as the filename but without the .lev suffix. Next comes 0x01, as mentioned above.
+
−
 
+
−
The name of the level style. As displayed in the drop-down
+
−
 
+
−
The name of the water colour, with an initial captital letter, and the rest lower case. They can be: Red, Blue, Green, Purple, Yellow.
+
−
 
+
−
And those "magic bytes" above.
+
−
 
+
−
Then the data.
+
−
 
+
−
If the terrain is purely seeded, then after the last string, there is a lot more data, and there isn't the last 4 magic bytes before the data. Also, the byte after the 3rd string is 0x00, not 0x01. What the rest of the data is is unknown.
+
  
 
{{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.


WKB stub  This article is a stub. You can help the Worms Knowledge Base by expanding it.
Retrieved from "https://worms2d.info/?title=Monochrome_map_(Worms_2)&oldid=21873"
Personal tools