ModdingWiki - Recent changes [en-gb]

HeroQuest EXE File

Theruler — Fri, 26 Jun 2026 17:15:37 GMT

Various

← Older revision		Revision as of 17:15, 26 June 2026
(2 intermediate revisions by the same user not shown)
Line 1,109:		Line 1,109:
	0x00DCC9: 4 words for sprite direction codification FF00=South ecc..		0x00DCC9: 4 words for sprite direction codification FF00=South ecc..
	0x00DF95: Sequence of 11 groups of 4 bytes used for teleportation in "castle of mistery" quest (Room, X, Y, door direction that could be 00,01,1A)		0x00DF95: Sequence of 11 groups of 4 bytes used for teleportation in "castle of mistery" quest (Room, X, Y, door direction that could be 00,01,1A)
	0x00DFDC: Sequence of 21 groups of 6 words used to define furniture (first word: X,Y dimension of the frame - second word: Y,X offset in pixels from the origin tile - third word: offset of the frame in FURN.VGA)		0x00DFDC: Sequence of 21 groups of 3 words used to define furniture (first word: X,Y dimension of the frame - second word: Y,X offset in pixels from the origin tile - third word: offset of the frame in FURN.VGA)
	0x00E05B: Group of 4 offsets for the walls graphics in graphics.vga (2 wariations of the left wall and 2 of the right wall).		0x00E05B: Group of 4 offsets for the walls graphics in graphics.vga (2 wariations of the left wall and 2 of the right wall).
	0x00E062: 26 bytes (00 or 01) used for wall variations based on ROOM tile position number (see diamond scheme above). Basically each position has its own fixed wall texture that is displayed only if a wall is present.		0x00E062: 26 bytes (00 or 01) used for wall variations based on ROOM tile position number (see diamond scheme above). Basically each position has its own fixed wall texture that is displayed only if a wall is present.
Line 1,139:		Line 1,139:
	0x00E536: Sequence of 30h index in maps.vga that assign names of the object (01=fallen rock, 00=all traps or hidden objects with no name, 03=Stairs) in OBJECT BLOCK order.		0x00E536: Sequence of 30h index in maps.vga that assign names of the object (01=fallen rock, 00=all traps or hidden objects with no name, 03=Stairs) in OBJECT BLOCK order.
	0x00E566: 23h bitmasks that define which object is passable by projectiles		0x00E566: 23h bitmasks that define which object is passable by projectiles
	0x00EE2D: Offsets (12) sequence of object icons in maps.vga (from ID 30 to 3B, 00D1 = fallen rock~~, goblin~~) ~~00D1~~		0x00EE2D: Offsets (12) sequence of object icons in maps.vga (from ID 30 to 3B, 00D1 = fallen rock)
	0x00EE45: Offsets sequence of monster's icons in maps.vga (ID 00 = 40D3 = goblin)		0x00EE45: Offsets sequence of monster's icons in maps.vga (ID 00 = 40D3 = goblin)
			0x00EE95: Sequence of 2Ch memory pointers to the profile of the 2D furnitures icons
			0x00EEC1: Sequence of 2Ch profiles of the 2D furnitures icons that tells how the full picture is composed

	== Intro Sequence ==		== Intro Sequence ==

HeroQuest Quest Format

Nyerguds — Fri, 26 Jun 2026 12:03:50 GMT

Map Layers: More table formatting

← Older revision		Revision as of 12:03, 26 June 2026
(5 intermediate revisions by the same user not shown)
Line 47:		Line 47:

	This block starts at the beginning of the file. The rooms layout determines which area on the map is part of which room. Since the game is limited to showing rooms with a maximum dimension of 6x5, all paths are chopped up into different 'rooms' as well. Rooms have numbers from 0 to 42. A value of 0 means the room is not used. Rooms 1 to 20 (0x14) are the pathways. The remaining range, from 21 to 42 (0x15 to 0x2A), are the main rooms.		This block starts at the beginning of the file. The rooms layout determines which area on the map is part of which room. Since the game is limited to showing rooms with a maximum dimension of 6x5, all paths are chopped up into different 'rooms' as well. Rooms have numbers from 0 to 42. A value of 0 means the room is not used. Rooms 1 to 20 (0x14) are the pathways. The remaining range, from 21 to 42 (0x15 to 0x2A), are the main rooms.

			The room values can have two additional options set, in the upper two bits that are never used by the room number itself. These are not used in any of the existing map files; they are normally set by the game itself during gameplay in the loaded file data. But enabling them in the map file works to accomplish the same effects.

			{\|class="wikitable" style="text-align:center"
			! Bit !! Bin value !! Hex Value !! Effect
			\|-
			\| 7 \|\| 01000000 \|\| 0x40 \|\| style="text-align:left" \| This tile was explored and is visible on the overview map. Normally this is done for entire rooms at once.
			\|-
			\| 8 \|\| 10000000 \|\| 0x80 \|\| style="text-align:left" \| This tile's walls are explored. This is used on the east and south tiles adjacent to explored tiles, to make the overview map draw the outer walls around explored rooms. The game checks which adjacent tiles (north and/or west of the marked tile) are explored to determine which wall should be shown.
			\|}

	The default rooms layout with coordinates:		The default rooms layout with coordinates:
Line 108:		Line 118:
	Each byte in this block is made up of bit flags that can be combined. However, these bits are not just settings interpreted by the code; the full value made up of these bits also creates the index used to look up the corresponding sprite graphics. Because of this, the unused bit 0x02 can be used to mod alternate graphics into wall tiles, even if it has no real meaning to the game. Here are the meanings of each separate bit:		Each byte in this block is made up of bit flags that can be combined. However, these bits are not just settings interpreted by the code; the full value made up of these bits also creates the index used to look up the corresponding sprite graphics. Because of this, the unused bit 0x02 can be used to mod alternate graphics into wall tiles, even if it has no real meaning to the game. Here are the meanings of each separate bit:

	{\|class="wikitable"		{\| class="wikitable" style="text-align:center"
	! Bin value !! Hex Value !! Effect		! Bit !! Bin value !! Hex Value !! Effect
	\|-		\|-
	\| 00000000 \|\| 0x00 \|\| None		\| -\|\| 00000000 \|\| 0x00 \|\| style="text-align:left" \| None
	\|-		\|-
	\| 00000001 \|\| 0x01 \|\| Do not draw this wall. Doors show up as a frame only. This is done with walls when the area goes around a corner behind the walls, to prevent them from overlapping the floor tiles.		\| 1 \|\| 00000001 \|\| 0x01 \|\| style="text-align:left" \| Do not draw this wall. Doors show up as a frame only. This is done with walls when the area goes around a corner behind the walls, to prevent them from overlapping the floor tiles.
	\|-		\|-
	\| 00000010 \|\| 0x02 \|\| Not used (only appears once in Quest 3) can be used in conjunction with 4th bit to change graphic for opened secret door		\| 2 \|\| 00000010 \|\| 0x02 \|\| style="text-align:left" \| Not used (only appears once in Quest 3) can be used in conjunction with 4th bit to change graphic for opened secret door
	\|-		\|-
	\| 00000100 \|\| 0x04 \|\| The door is Open (can't be applied if secret)		\| 3 \|\| 00000100 \|\| 0x04 \|\| style="text-align:left" \| The door is Open (can't be applied if secret)
	\|-		\|-
	\| 00001000 \|\| 0x08 \|\| The door is Secret (can't be applied if open)		\| 4 \|\| 00001000 \|\| 0x08 \|\| style="text-align:left" \| The door is Secret (can't be applied if open)
	\|-		\|-
	\| 00010000 \|\| 0x10 \|\| Door to the West		\| 5 \|\| 00010000 \|\| 0x10 \|\| style="text-align:left" \| Door to the West
	\|-		\|-
	\| 00100000 \|\| 0x20 \|\| Door to the North		\| 6 \|\| 00100000 \|\| 0x20 \|\| style="text-align:left" \| Door to the North
	\|-		\|-
	\| 01000000 \|\| 0x40 \|\| Wall to the West		\| 7 \|\| 01000000 \|\| 0x40 \|\| style="text-align:left" \| Wall to the West
	\|-		\|-
	\| 10000000 \|\| 0x80 \|\| Wall to the North		\| 8 \|\| 10000000 \|\| 0x80 \|\| style="text-align:left" \| Wall to the North
	\|}		\|}

User:AranVink

Malvineous — Thu, 18 Jun 2026 01:23:33 GMT

Creating user page for new user.

New page

Would like to contribute to Major Stryker level information

User:AranVink

Malvineous — Thu, 18 Jun 2026 01:23:30 GMT

User account AranVink was created by Malvineous and password was sent by email

HeroQuest Quest Format

Theruler — Mon, 15 Jun 2026 20:43:52 GMT

Monster Types

← Older revision		Revision as of 20:43, 15 June 2026
Line 389:		Line 389:
	\| 0x14 \|\| 20 \|\| Spirit Rider \|\| Chaos warrior \|\| 03 \|\| 03 \|\| 08 \|\| 04 \|\| 03 \|\| 0000		\| 0x14 \|\| 20 \|\| Spirit Rider \|\| Chaos warrior \|\| 03 \|\| 03 \|\| 08 \|\| 04 \|\| 03 \|\| 0000
	\|-		\|-
	\| 0x15 \|\| 21 \|\| Death Mist\|\| No graphics \|\| \|\| \|\| 06 \|\| 04 \|\| 03 \|\| 0000		\| 0x15 \|\| 21 \|\| Death Mist\|\| No graphics \|\| - \|\| - \|\| 06 \|\| 04 \|\| 03 \|\| 0000
	\|-		\|-
	\| 0x16 \|\| 22 \|\| Bellthor \|\| Gargoyle \|\| \|\| \|\| 06 \|\| 04 \|\| 06 \|\| B82B		\| 0x16 \|\| 22 \|\| Bellthor \|\| Gargoyle \|\| 03 \|\| 03 \|\| 06 \|\| 04 \|\| 06 \|\| B82B
	\|-		\|-
	\| 0x17 \|\| 23 \|\| Skulmar \|\| Gargoyle \|\| \|\| \|\| 08 \|\| 05 \|\| 06 \|\| 0000		\| 0x17 \|\| 23 \|\| Skulmar \|\| Gargoyle \|\| 03\|\| 04 \|\| 08 \|\| 05 \|\| 06 \|\| 0000
	\|-		\|-
	\| 0x18 \|\| 24 \|\| Doomguard \|\| Gargoyle \|\| \|\| \|\| 06 \|\| 04 \|\| 06 \|\| 0000		\| 0x18 \|\| 24 \|\| Doomguard \|\| Gargoyle \|\| 03 \|\| 03 \|\| 06 \|\| 04 \|\| 06 \|\| 0000
	\|-		\|-
	\| 0x19 \|\| 25 \|\| Witch Kessandria \|\| Gargoyle \|\| \|\| \|\| 06 \|\| 04 \|\| 06 \|\| 0000		\| 0x19 \|\| 25 \|\| Witch Kessandria \|\| Gargoyle \|\| 03 \|\| 04 \|\| 06 \|\| 04 \|\| 06 \|\| 0000
	\|-		\|-
	\| 0x1A \|\| 26 \|\| The Witch Lord \|\| Gargoyle \|\| \|\| \|\| 0A \|\| 05 \|\| 06 \|\| DC2B		\| 0x1A \|\| 26 \|\| The Witch Lord \|\| Gargoyle \|\| 04 \|\| 05 \|\| 0A \|\| 05 \|\| 06 \|\| DC2B
	\|-		\|-
	\| 0x1B \|\| 27 \|\| Orc \|\| Orc \|\| \|\| \|\| 08 \|\| 03 \|\| 02 \|\| 0000		\| 0x1B \|\| 27 \|\| Orc \|\| Orc \|\| - \|\| - \|\| 08 \|\| 03 \|\| 02 \|\| 0000
	\|}		\|}

HeroQuest EQUESTS Format

Theruler — Wed, 10 Jun 2026 12:57:25 GMT

← Older revision		Revision as of 12:57, 10 June 2026
Line 14:		Line 14:
	\|0x021\|\|[[char]][variable]\|\| Title of the first quest		\|0x021\|\|[[char]][variable]\|\| Title of the first quest
	\|}		\|}

			All the rest of the lines and pages that follow have the same structure. Only the pointer block is unique.


			==Research credits==

			* [[user:Theruler\|TheRuler]] from the OldGamesItalia translation project mapped the format of the strings files.

HeroQuest EQUESTS Format

Theruler — Wed, 10 Jun 2026 12:54:53 GMT

Created page with "EQUESTS.BIN contains the Quests names in each of the 5 languages. The internal format is the following: {|class="wikitable" !Offset!!Data type!!Description |- |0x000||UINT16LE[10]|| Pointer block to the 10 pages (2 for each language, Page 1 Base quests, Page 2, Expansion quests) |- |0x014||UINT8[10]|| First Page Header, contains box info and number of entries |- |0x01E||UINT8[03]|| Line start code with coordinates: 11 YY XX |- |0x021||char[variable]|| T..."

New page

EQUESTS.BIN contains the Quests names in each of the 5 languages.

The internal format is the following:

{|class="wikitable"
!Offset!!Data type!!Description
|-
|0x000||[[UINT16LE]][10]|| Pointer block to the 10 pages (2 for each language, Page 1 Base quests, Page 2, Expansion quests)
|-
|0x014||[[UINT8]][10]|| First Page Header, contains box info and number of entries
|-
|0x01E||[[UINT8]][03]|| Line start code with coordinates: 11 YY XX
|-
|0x021||[[char]][variable]|| Title of the first quest
|}

HeroQuest

Theruler — Wed, 10 Jun 2026 12:40:14 GMT

File formats

← Older revision		Revision as of 12:40, 10 June 2026
(One intermediate revision by the same user not shown)
Line 100:		Line 100:
	}}		}}
	{{GameFile		{{GameFile
	\| Name = *.BIN		\| Name = [language].BIN
	\| Format = [[HeroQuest Strings Format]]		\| Format = [[HeroQuest Strings Format]]
	\| KnownFormat = Yes		\| KnownFormat = Yes
	\| Desc = Binary files with in-game text in five languages (ENGLISH, GERMAN, FRENCH, SPANISH, ITALIAN) ~~and EQUEST~~.BIN with quest names.		\| Desc = Binary compressed files with in-game text in five languages (ENGLISH, GERMAN, FRENCH, SPANISH, ITALIAN).
			}}
			{{GameFile
			\| Name = EQUESTS.BIN
			\| Format = [[HeroQuest EQUESTS Format]]
			\| KnownFormat = Yes
			\| Desc = Binary file with quest names.
	}}		}}
	{{GameFile		{{GameFile

Westwood RLE

Nyerguds — Sat, 06 Jun 2026 16:05:34 GMT

Small fixes.

← Older revision		Revision as of 16:05, 6 June 2026
(2 intermediate revisions by the same user not shown)
Line 3:		Line 3:
	\| UnitSize = 1-byte		\| UnitSize = 1-byte
	\| Games =		\| Games =
			{{Game\|A Nightmare on Elm Street}}
			{{Game\|DragonStrike}}
			{{Game\|Eye of the Beholder}}
			{{Game\|Eye of the Beholder II: The Legend of Darkmoon}}
	{{Game\|Lands of Lore: The Throne of Chaos}}		{{Game\|Lands of Lore: The Throne of Chaos}}
	~~{{Game\|Eye of the Beholder}}~~
	~~{{Game\|A Nightmare on Elm Street}}~~
	}}		}}

	[[:Category:Westwood Studios\|Westwood Studios]]' RLE compression, ~~also known as~~ "~~Format 3~~" ~~because~~ it is ~~usually indicated in file headers as compression method "3", and~~ called "HORIZONTAL" ~~in Westwood's source code~~<ref>[https://github.com/electronicarts/CnC_Remastered_Collection/blob/master/TIBERIANDAWN/WIN32LIB/IFF.H#L68 IFF.H in the ''Command & Conquer'' source code:] <tt>HORIZONTAL, // Run length encoding (RLE).</tt></ref>, is ~~a classic~~ [[~~RLE Compression#Code~~\|~~code-based RLE~~]] ~~structure that uses codes~~ where ~~the highest bit indicates~~ a ~~Repeat command~~. ~~For copy commands~~, the ~~amount~~ to ~~copy is simply the Code value. For repeat commands~~, the ~~amount to repeat~~ is ~~calculated with <code>0x100-Code</code>~~.		[[:Category:Westwood Studios\|Westwood Studios]]' RLE compression is a classic [[RLE Compression#Code\|code-based RLE]] structure that uses codes where the highest bit indicates a Repeat command. For copy commands, the amount to copy is simply the Code value. For repeat commands, the amount to repeat is calculated with <code>0x100-Code</code>.

			In older games it was internally called "CMV", though the exact meaning of that term is unknown. In the Command & Conquer source code, it is called "HORIZONTAL"<ref>[https://github.com/electronicarts/CnC_Remastered_Collection/blob/master/TIBERIANDAWN/WIN32LIB/IFF.H#L68 IFF.H in the ''Command & Conquer'' (remaster) source code:] <tt>HORIZONTAL, // Run length encoding (RLE).</tt></ref>, although the actual compression type is not supported in the game. The name "HORIZONTAL" was used because in earlier file formats, like [[Westwood CMP Format\|CMP]], this compression could be applied vertically as well, in cases where this resulted in a smaller compressed size. In community tools, the format is often referred to as "Format 3", because (as shown in the C&C source code) it is generally indicated in file headers as compression method "3".

	Westwood RLE deviates from the classic one-byte copy/repeat code structure by assigning a special function to the normally-useless "copy 0 bytes" command (code 0x00). When this is encountered, the system instead reads the two following bytes as 16-bit integer, and performs a Repeat command using that value and the byte following that extended code.		Westwood RLE deviates from the classic one-byte copy/repeat code structure by assigning a special function to the normally-useless "copy 0 bytes" command (code 0x00). When this is encountered, the system instead reads the two following bytes as 16-bit integer, and performs a Repeat command using that value and the byte following that extended code.
Line 14:		Line 18:
	This extended format has some odd endianness issues. In general, the 16-bit integer needs to be read as big-endian, which is a bit counterintuitive on a PC format, since PC CPUs are little-endian. However, in [[Westwood CMP Format\|the CMP format]], the older 4-bit format reads the large repeat value as little-endian. In [[Westwood CPS Format\|the CPS format]], the PC format reads it as little-endian, while Amiga files read it as big-endian, meaning they do the completely opposite from how their respective CPUs would write such numbers. Do note that the Amiga version of the CPS format differs enough from the PC version that this never causes real issues in determining how to decompress it.		This extended format has some odd endianness issues. In general, the 16-bit integer needs to be read as big-endian, which is a bit counterintuitive on a PC format, since PC CPUs are little-endian. However, in [[Westwood CMP Format\|the CMP format]], the older 4-bit format reads the large repeat value as little-endian. In [[Westwood CPS Format\|the CPS format]], the PC format reads it as little-endian, while Amiga files read it as big-endian, meaning they do the completely opposite from how their respective CPUs would write such numbers. Do note that the Amiga version of the CPS format differs enough from the PC version that this never causes real issues in determining how to decompress it.

	In earlier formats like CMP, the compression could be applied vertically, because in some cases this resulted in a smaller compressed size. The fact the source code of later games refers to the standard RLE compression as "HORIZONTAL" is a leftover of this.

	== Example compression / decompression code ==		== Example compression / decompression code ==

Westwood CMP Format

Nyerguds — Sat, 06 Jun 2026 15:44:41 GMT

Image data: Specified endianness on Westwood RLE compression.

← Older revision		Revision as of 15:44, 6 June 2026
Line 44:		Line 44:
	!Type!!Colour depth!!Compression		!Type!!Colour depth!!Compression
	\|-		\|-
	\|1\|\|4-bit\|\|[[Westwood RLE]] (horizontal)		\|1\|\|4-bit\|\|[[Westwood RLE]] (horizontal). Reads the extended 16-bit integer repeat values as little-endian.
	\|-		\|-
	\|2\|\|4-bit\|\|[[Westwood RLE]] (vertical)		\|2\|\|4-bit\|\|[[Westwood RLE]] (vertical). Reads the extended 16-bit integer repeat values as little-endian.
	\|-		\|-
	\|3\|\|8-bit\|\|[[Westwood LZW-12]]		\|3\|\|8-bit\|\|[[Westwood LZW-12]]
	\|-		\|-
	\|4\|\|8-bit\|\|[[Westwood RLE]] (horizontal)~~, oddly using~~ big-endian ~~16 bit values (in DragonStrike)~~		\|4\|\|8-bit\|\|[[Westwood RLE]] (horizontal). Reads the extended 16-bit integer repeat values as big-endian.
	\|-		\|-
	\|5\|\|-\|\|Unknown, probably unused. (In DragonStrike, any value besides 3, 4 and 6 seems to default to loading as type 4)		\|5\|\|-\|\|Unknown, probably unused. (In DragonStrike, any value besides 3, 4 and 6 seems to default to loading as type 4)

Westwood RLE

Nyerguds — Sat, 06 Jun 2026 15:41:08 GMT

Fixed again. Man they made a mess of this.

← Older revision		Revision as of 15:41, 6 June 2026
(One intermediate revision by the same user not shown)
Line 12:		Line 12:
	Westwood RLE deviates from the classic one-byte copy/repeat code structure by assigning a special function to the normally-useless "copy 0 bytes" command (code 0x00). When this is encountered, the system instead reads the two following bytes as 16-bit integer, and performs a Repeat command using that value and the byte following that extended code.		Westwood RLE deviates from the classic one-byte copy/repeat code structure by assigning a special function to the normally-useless "copy 0 bytes" command (code 0x00). When this is encountered, the system instead reads the two following bytes as 16-bit integer, and performs a Repeat command using that value and the byte following that extended code.

	This extended format ~~suffers from~~ endianness ~~problems, though: on Amiga files~~, the 16-bit integer is little-endian, ~~while PC files have it~~ as ~~big~~-endian~~, meaning files can't be decompressed without knowing their target system~~. In ~~reality, however, this compression is only used in~~ [[Westwood CPS Format\|the CPS format]], ~~and~~ the Amiga version of ~~that~~ format differs enough from the PC version to ~~make this issue moot~~.		This extended format has some odd endianness issues. In general, the 16-bit integer needs to be read as big-endian, which is a bit counterintuitive on a PC format, since PC CPUs are little-endian. However, in [[Westwood CMP Format\|the CMP format]], the older 4-bit format reads the large repeat value as little-endian. In [[Westwood CPS Format\|the CPS format]], the PC format reads it as little-endian, while Amiga files read it as big-endian, meaning they do the completely opposite from how their respective CPUs would write such numbers. Do note that the Amiga version of the CPS format differs enough from the PC version that this never causes real issues in determining how to decompress it.

	In earlier formats, like ~~[[Westwood~~ CMP ~~Format\|Westwood CMP]]~~, the compression could be applied vertically, because in some cases this resulted in a smaller compressed size. The fact the source code of later games refers to the standard RLE compression as "HORIZONTAL" is a leftover of this.		In earlier formats like CMP, the compression could be applied vertically, because in some cases this resulted in a smaller compressed size. The fact the source code of later games refers to the standard RLE compression as "HORIZONTAL" is a leftover of this.

	== Example compression / decompression code ==		== Example compression / decompression code ==

Westwood CMP Format

Nyerguds — Fri, 05 Jun 2026 20:42:55 GMT

Removed speculation on type 5 after further testing.

← Older revision		Revision as of 20:42, 5 June 2026
(One intermediate revision by the same user not shown)
Line 1:		Line 1:
	{{Image Infobox		{{Image Infobox
	\| Hardware1 = EGA		\| Hardware1 = EGA
	\| Depth = 4-bit		\| Depth = 4-bit, 8-bit
	\| MinSize = 320×200		\| MinSize = 320×200
	\| MaxSize = 320×200		\| MaxSize = 320×200
Line 10:		Line 10:
	\| Games =		\| Games =
	{{Game\|A Nightmare on Elm Street}}		{{Game\|A Nightmare on Elm Street}}
			{{Game\|DragonStrike}}
	}}		}}

	The '''CMP Format''' is an older version of what would later become the [[Westwood CPS Format\|CPS format]]. It is a 4-bit ~~[[RLE Compression\|RLE~~-compressed]] file which always contains a 320x200 image. It contains no palette.		The '''CMP Format''' is an older version of what would later become the [[Westwood CPS Format\|CPS format]]. It is a 4-bit or 8-bit compressed file which always contains a 320x200 image. It contains no palette.

	Like the CPS format, these files tend to be used both for fullscreen 320x200 images, and for collections of sprites.		Like the CPS format, these files tend to be used both for fullscreen 320x200 images, and for collections of sprites.
Line 27:		Line 28:
	!Data type!!Name!!Description		!Data type!!Name!!Description
	\|-		\|-
	\|[[UINT16LE]]\|\|FileSize\|\|File size. This only counts the bytes behind this value, making it two bytes less than the actual file size.		\|[[UINT16LE]]\|\|FileSize\|\|File size. This only counts the bytes behind this value, making it two bytes less than the actual file size. On type 4, it is three bytes less than the full size.
	\|-		\|-
	\|[[UINT8]]\|\|~~CompressionType~~\|\|~~Compression~~ type. ~~Either <tt>1</tt> for horizontal compression, or <tt>2</tt> for vertical~~ compression.		\|[[UINT8]]\|\|Type\|\|File type. Determines the bits per pixel and the compression scheme? See the list below.
	\|}		\|}

	~~This~~ header is ~~immediately~~ followed by the ~~compressed~~ data.		For types 3 and 6, this header is followed by another [[UINT16LE]] that indicate the length of the uncompressed data. This should always be 64000.

			The image data follows immediately after this header.

	=== Image data ===		=== Image data ===

	The image data ~~is compressed with~~ the [[Westwood RLE]] ~~compression~~, using ~~little~~-endian 16-bit values ~~for its large repeat values~~. If the ~~<tt>CompressionType</tt> in the header~~ is ~~set to~~ "2", decompressed bytes should be painted onto the image per column. Do note that ~~the image is~~ 4-bit, so each such column is two pixels wide.		The image data can be in different formats, depending on the <tt>Type</tt> in the header:

			{\|class="wikitable"
			!Type!!Colour depth!!Compression
			\|-
			\|1\|\|4-bit\|\|[[Westwood RLE]] (horizontal)
			\|-
			\|2\|\|4-bit\|\|[[Westwood RLE]] (vertical)
			\|-
			\|3\|\|8-bit\|\|[[Westwood LZW-12]]
			\|-
			\|4\|\|8-bit\|\|[[Westwood RLE]] (horizontal), oddly using big-endian 16 bit values (in DragonStrike)
			\|-
			\|5\|\|-\|\|Unknown, probably unused. (In DragonStrike, any value besides 3, 4 and 6 seems to default to loading as type 4)
			\|-
			\|6\|\|8-bit\|\|[[Westwood LZW-14]]
			\|}

			If the type is "2", the decompressed bytes should be painted onto the image per column. Do note that that type denotes a 4-bit image, so each such column is two pixels wide.

	To handle ~~<tt>CompressionType</tt> 2~~, the game decompresses the data straight into the screen buffer vertically using a separate decompression function. For modern applications, it is probably simpler to swap the rows and columns as post-processing step, since that means both compression types can use the same decompression code.		To handle this type, the game decompresses the data straight into the screen buffer vertically using a separate decompression function. For modern applications, it is probably simpler to swap the rows and columns as post-processing step, since that means both compression types can use the same decompression code.

	The vertical compression is consistently used on images where compressing the bytes per column results in a lower file size.		The vertical compression is consistently used on images where compressing the bytes per column results in a lower file size.

	[[Category:Westwood Studios File Formats]]		[[Category:Westwood Studios File Formats]]