ModdingWiki - User contributions [en-gb]

CC Format

2014-12-07T07:05:43Z

Driedfruit: I was a bit wrong about the 1122 byte limit, it's just the maximum allowed header size;

{{Archive Infobox
| MaxFiles = 140
| FAT = Beginning
| Names = Yes, hashed
| Metadata = None
| Subdirectories = N
| Compressed = Y
| Encrypted = N
| Hidden = N
| Game1 = King's Bounty
}}
The '''CC Format''' is how files in the game [[King's Bounty]] are stored. Files in this format have the ".CC" extension, which probably stands for "crude" or "compact" compression. It's a group file format with compression (similar to .zip file) with a simple file allocation table in its header.

The game will check the current directory for files only if they weren't found in the CC file first. However, stand-alone files are still expected to be compressed and include UINT32LE length, see Compression below.

== File format ==

The first 1122 (or less) bytes of the file consists of file entries, with the remainder containing the data. Each file entry takes 8 bytes, and consists of the filename hash, it's offset and compressed length.

=== Signature ===

There is no known signature for this format. One method to identify files is to read in the file entries (as there is a fixed maximum of these, all 1122 bytes must be present for the file to be valid) and confirm that each file offset refers to a location after a previous file offset (that is not the requirement of the format, but that is how the original CC files are composed), and that offset is within file boundary.

=== Header ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||numFiles||Number of entries
|-
|struct FileEntry||entries[]||Array of entries
|}

The 1122 bytes available makes enough room for 140 files. However, the largest amount actually seen - 136 files in 416.CC.

=== File entry ===

A file entry is laid out as follows.

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||hash||Filename hash
|-
|UINT24LE||offset||File offset from start of group file
|-
|UINT24LE||size||Size of compressed data
|}

Note the weird 24-bit data type. It is indeed an unsigned integer composed from 3 bytes in little endian order.

The hash key for a filename could be calculated as follows:
<source lang="c">
//word is UINT16LE
word cc_filename_hash(char *filename)
{
word key = 0;
byte next;

while ((next = *filename++))
{
next &= 0x7F;
if (next >= 0x60)
next -= 0x20;

/* Swap high and low bytes */
key = ((key >> 8) & 0x00FF) | ((key << 8) & 0xFF00);

/* Rotate left by 1 bit */
key = (key << 1) | ((key >> 15) & 0x0001);

key += next;
}

return key;
}
</source>

As the filenames themselves are not stored in the group file, only their hashes are, we must have a prepared list of filenames handy. The game keeps it in the EXE file.

The files are:
<pre>
// Add .4, .16 or .256 extension to those:
char *graf_files[] = {
//Troops
"peas","spri","mili","wolf","skel","zomb","gnom","orcs","arcr","elfs",
"pike","noma","dwar","ghos","kght","ogre","brbn","trol","cavl","drui",
"arcm","vamp","gian","demo","drag",

//Villains
"mury","hack","ammi","baro","drea","cane","mora","barr","barg","rina",
"ragf","mahk","auri","czar","magu","urth","arec",

"knig","pala","sorc","barb","nwcp","title","select",
"tileseta","tilesetb","tilesalt","cursor","town","cstl","plai",
"frst","dngn","cave","comtiles","view","endpic"
};
// Use as is:
char *extra_files[] = {
"KB.CH", // 1bpp 8x8 font file
"LAND.ORG", // world map
"TIMER.DRV",
"SOUND.DRV",
"CGA.DRV",
"EGA.DRV",
"TGA.DRV",
"HGA.DRV",
"MCGA.DRV",
};
</pre>

The .4, .16 and .256 files are graphics, kept in [[King's Bounty Graphics Format]].

All files are compressed.

== Compression ==

At each offset, a data chunk is located:

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT32LE]]||size||Size of uncompressed data
|-
|[[BYTE]]||lzwData[]||Compressed data
|}

The data is compressed by [[LZW compression]] with the following characteristics:
* Codeword takes from 9 to 12 bits (as in Commander Keen)
* <tt>0x0100</tt> codeword instructs '''dictionary reset''' and not '''error'''
The '''dictionary reset''' is performed like this:
<pre>
the dictionary is cleared
(the bit step is made 9 bits again)
one more value is being read from input
that value is written to output as-is
that value is NOT saved into the dictionary
</pre>

== Credits ==

Originally devised by the [http://sourceforge.net/p/openkb/wiki/Home/ openkb project], with best regards to the modding community.

Talk:CC Format

2014-12-07T07:02:32Z

Driedfruit:

The compression format looks a lot like [[LZW compression]] - is it a known algorithm like this or is it custom? -- [[User:Malvineous|Malvineous]] 10:57, 23 August 2011 (GMT)

: Argh, I feel so stupid! Yes, indeed it's the LZW compression. The only notable difference being the 0x1000 key which is used for dictionary reset and not errors. -- [[User:Driedfruit|Driedfruit]] 19:31, 23 August 2011 (GMT)

Is the 140 entry limit a hard limit, or just coincidence that no archives have more than this many files? i.e. will the game fail to run if you put 300 files in the archive, adjusting offsets as appropriate? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 09:51, 22 November 2014 (UTC)

: The maximum number of entries encountered is 136. The number 140 comes from the fact only that much (1122 bytes) is read as FAT by the game, so, yeah, I assume adding more entries will not work. -- [[User:Driedfruit|Driedfruit]] ([[User talk:Driedfruit|talk]]) 12:15, 22 November 2014 (UTC)

BTW, I would love libgamearchive/Camoto to handle this format for me, because writing full extractor/compressor is a PITA, but I unfortunately wouldn't be able to add this support myself. -- [[User:Driedfruit|Driedfruit]] ([[User talk:Driedfruit|talk]]) 12:17, 22 November 2014 (UTC)

: Happy to add support since the format is quite well documented. One question though, as a technicality - do you think the compression is part of the CC format itself or not? As in, should Camoto transparently compress and decompress files, or should the files be inserted unchanged and you would already have compressed versions of them as the compression is part of those files' formats? I ask because it says the game will read files outside of the .cc archive, but they have to be compressed. This suggests to me that all the file formats in the game are compressed with the same method, and the .cc format just groups them together, without technically compressing anything. What do you think? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 21:34, 6 December 2014 (UTC)

:: Great question. I think on principle, extracted files should be kept archived, for the reasons you outlined. However on practice, that is very inconvenient for both modders and tool writers (i.e. simple image conversion tool becomes a tad more quite complex with that approach). For my simplistic tool I went with full decompression, but I'm not 100% convinced I did the right thing. The decision is yours. BTW, since I posted that comment, I bit the bullet and did write the full set of tools. I know this is not the right place to ask about it, but should I create/post an article about them on this wiki? The thing that irks me is that it's not a single program, so I'm not quite sure how to go about that (they do form a set and will be distributed in a single .zip archive). Can I create an article called, for example, "openkb tools" and explain how to use them all together? Again, sorry for asking in the wrong place. [[User:Driedfruit|Driedfruit]] ([[User talk:Driedfruit|talk]]) 07:02, 7 December 2014 (UTC)

Talk:CC Format

2014-11-22T12:41:57Z

Driedfruit:

Talk:CC Format

2014-11-22T12:17:25Z

Driedfruit:

Talk:CC Format

2014-11-22T12:15:24Z

Driedfruit:

Talk:CC Format

2014-11-22T12:14:42Z

Driedfruit:

CC Format

2014-11-09T16:04:06Z

Driedfruit: some minor corrections

{{Archive Infobox
| MaxFiles = 140
| FAT = Beginning
| Names = Yes, hashed
| Metadata = None
| Subdirectories = N
| Compressed = Y
| Encrypted = N
| Hidden = Y
| Game1 = King's Bounty
}}
The '''CC Format''' is how files in the game [[King's Bounty]] are stored. Files in this format have the ".CC" extension, which probably stands for "crude" or "compact" compression. It's a group file format with compression (similar to .zip file) with a simple file allocation table in its header.

The game will check the current directory for files only if they weren't found in the CC file first. However, stand-alone files are still expected to be compressed and include UINT32LE length, see Compression below.

== File format ==

The first 1122 bytes of the file consists of file entries, with the remainder containing the data. Each file entry takes 8 bytes, and consists of the filename hash, it's offset and compressed length.

=== Signature ===

There is no known signature for this format. One method to identify files is to read in the file entries (as there is a fixed maximum of these, all 1122 bytes must be present for the file to be valid) and confirm that each file offset refers to a location after a previous file offset (that is not the requirement of the format, but that is how the original CC files are composed), and that offset is within file boundary.

=== Header ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||numFiles||Number of entries
|-
|struct FileEntry||entries[]||Array of entries
|}

The 1122 bytes available makes enough room for 140 files. However, the largest amount actually seen - 136 files in 416.CC leaves 64 bytes unused.

=== File entry ===

A file entry is laid out as follows.

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||hash||Filename hash
|-
|UINT24LE||offset||File offset from start of group file
|-
|UINT24LE||size||Size of compressed data
|}

Note the weird 24-bit data type. It is indeed an unsigned integer composed from 3 bytes in little endian order.

The hash key for a filename could be calculated as follows:
<source lang="c">
//word is UINT16LE
word cc_filename_hash(char *filename)
{
word key = 0;
byte next;

while ((next = *filename++))
{
next &= 0x7F;
if (next >= 0x60)
next -= 0x20;

/* Swap high and low bytes */
key = ((key >> 8) & 0x00FF) | ((key << 8) & 0xFF00);

/* Rotate left by 1 bit */
key = (key << 1) | ((key >> 15) & 0x0001);

key += next;
}

return key;
}
</source>

As the filenames themselves are not stored in the group file, only their hashes are, we must have a prepared list of filenames handy. The game keeps it in the EXE file.

The files are:
<pre>
// Add .4, .16 or .256 extension to those:
char *graf_files[] = {
//Troops
"peas","spri","mili","wolf","skel","zomb","gnom","orcs","arcr","elfs",
"pike","noma","dwar","ghos","kght","ogre","brbn","trol","cavl","drui",
"arcm","vamp","gian","demo","drag",

//Villains
"mury","hack","ammi","baro","drea","cane","mora","barr","barg","rina",
"ragf","mahk","auri","czar","magu","urth","arec",

"knig","pala","sorc","barb","nwcp","title","select",
"tileseta","tilesetb","tilesalt","cursor","town","cstl","plai",
"frst","dngn","cave","comtiles","view","endpic"
};
// Use as is:
char *extra_files[] = {
"KB.CH", // 1bpp 8x8 font file
"LAND.ORG", // world map
"TIMER.DRV",
"SOUND.DRV",
"CGA.DRV",
"EGA.DRV",
"TGA.DRV",
"HGA.DRV",
"MCGA.DRV",
};
</pre>

The .4, .16 and .256 files are graphics, kept in [[King's Bounty Graphics Format]].

All files are compressed.

== Compression ==

At each offset, a data chunk is located:

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT32LE]]||size||Size of uncompressed data
|-
|[[BYTE]]||lzwData[]||Compressed data
|}

The data is compressed by [[LZW compression]] with the following characteristics:
* Codeword takes from 9 to 12 bits (as in Commander Keen)
* <tt>0x0100</tt> codeword instructs '''dictionary reset''' and not '''error'''
The '''dictionary reset''' is performed like this:
<pre>
the dictionary is cleared
(the bit step is made 9 bits again)
one more value is being read from input
that value is written to output as-is
that value is NOT saved into the dictionary
</pre>

== Credits ==

Originally devised by the [http://sourceforge.net/p/openkb/wiki/Home/ openkb project], with best regards to the modding community.

King's Bounty Music Format

2014-11-09T10:13:45Z

Driedfruit: add offsets of '90 version

[[King's Bounty]] stores it's PC speaker music in the EXE file*.

* Note: The 1990 version of the EXE is compressed, offsets listed here are taken after uncompressing it with [[Knowledge_Dynamics_LZW_COMPRESSOR|unexecomp]] and [[Microsoft_EXEPACK|unexepack]].

{|class="wikitable"
!Offset 1990!!Offset 1995!!Data Type!!Description
|-
|0x18997||0x18B5D||[[BYTE]] str[]||Tunes (2 bytes per note, <tt>0xFF</tt> marks end)
|-
|0x189D1||0x18B97||[[UINT16LE]] freq[]||Note palette (frequencies)
|-
|0x18A81||0x18C47 ||[[UINT16LE]] delay[]||Duration palette
|-
|0x18AA1||0x18C67||[[UINT16LE]] offsets[10]||Offsets into tunes (add <tt>0x15690</tt> or <tt>0x15850</tt>)
|-
|}

For example, in 95 version, tune #0's offset (at 0x18C67) is <tt>0x330D</tt>, which leads us to <tt>0x18B5D</tt> (<tt>0x15850+0x330D</tt>). There, we see:
<pre>
0x28 0x07 0xFF
</pre>

Which are: index into note palette, index into duration palette, end marker. In default palettes, note <tt>0x28</tt> is 65 hz, and duration <tt>0x07</tt> is a 15 ms delay.

[[Category:King's Bounty]]
[[Category:Sound Files]]

King's Bounty Graphics Format

2014-11-09T09:49:40Z

Driedfruit:

[[King's Bounty]] stores all its graphics in external files in this format, packed into group files.

The CGA & EGA graphic files (4 and 16 colors) have the ".4" and ".16" extensions (<tt>title.4, title.16</tt>) and are kept in the <tt>416.CC</tt> file.

The VGA graphic files (256 colors) have the ".256" extension (<tt>title.256</tt>) and are kept in the <tt>256.CC</tt> file, except for <tt>endpic.256</tt>, which is kept in <tt>416.CC</tt> for some reason.

== Compression ==

All files are compressed as described in the [[CC Format]].

== File structure ==

The file starts with the number of chunks (graphics) in the file, followed by a number of values giving the offset of each chunk and a mask/color key offset.

If a graphic doesn't have a mask (background tile, title screen), the offset for the mask is 0x0000.

=== Header ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||count||Number of images in the file
|-
|struct Entry||entries[]||Array of image and mask offsets
|}

=== Graphic Entry ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||offset||Offset from start of file to image data
|-
|[[UINT16LE]]||mask_offset||Offset from start of file to mask data (0 if no mask)
|}

For VGA images, '''mask_offset''' points somewhere inside the image data, specifying which pixel should be treated as the color key.

== Image formats ==

=== Images ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||width||Image width, also pitch
|-
|[[UINT16LE]]||height||Image height
|-
|[[BYTE]]||data[]||Image data
|}

==== CGA ====

Image data is [[Linear CGA]].

The actual colours for each pixel depend on the active CGA palette, the game allows up to 8 choices. See [[wp:Color Graphics Adapter]] for details.

==== EGA ====

Unlike many other DOS games, EGA data is linear too, 4bpp this time.

==== VGA ====

[[Image:King's Bounty palette.png|thumb|right|128px|King's Bounty VGA palette]]

The VGA data is standard 8bpp single-plane data. The palette can be found in <tt>MCGA.DRV</tt> file, at offset <tt>0x032D</tt>. It's in [[VGA Palette|classic VGA format]] (6-bit RGB).

=== Masks ===

Masks are always linear 1bpp '''without''' the width and height data (the values of the actual image are used). Masks do not exist for VGA graphics, color keys are used instead (see above). Mask image data are rounded to the nearest 8-byte boundary and are padded with zeroes (i.e. 48x34 = 204 bytes / 8 => 26 = 208 bytes).

== Credits ==
Devised by the openkb project with best regards to the modding community.

[[Category: King's Bounty]]
[[Category: File Formats]]
[[Category: Graphics Files]]

File:King's Bounty palette.png

2014-11-09T09:42:07Z

Driedfruit: Palette for VGA mode of King's Bounty

Palette for VGA mode of [[King's Bounty]]

King's Bounty Saved game Format

2013-09-04T13:03:05Z

Driedfruit: add "unknown3", rename "followers" to "foes", change hint order for dwelling

This format is used to save the whole game state for [[King's Bounty]].

As the save files do not require re-insertion into group files, nor are compressed, yet maintain their own full copies of the game world, they provide good opportunity to distribute custom levels or maps.

== File format ==

A save always takes exactly 20421 bytes.

<pre>
0x000 - 0x00A | name
0x00B | class
0x00C | rank
0x00D | spell power
0x00E | max # of spells
0x00F - 0x01F | is villain N caught
0x020 - 0x027 | is artifact N found
0x028 - 0x02B | is continent N available
0x02C - 0x02F | is orb N found
0x030 - 0x03D | number of spells N
0x03E | knows magic
0x03F | siege weapons
0x040 | current contract
0x041 - 0x045 | hero army
0x046 | Option: Delay (0-9)
0x047 | difficulty
0x048 | Option: Sounds
0x049 | Option: Walk Beep
0x04A | Option: Animation
0x04B | Option: Show Army Size
0x04C | hero continent
0x04D | hero X
0x04E | hero Y
0x04F | last X
0x050 | last Y
0x051 | boat X
0x052 | boat Y
0x053 | boat continent (0xFF - no boat)
0x054 | mount mode (0x00 - boat, 0x04 - fly, 0x08 - horse)
0x055 | Option: CGA palette
0x056 - 0x069 | spell sold in town N
0x070 - 0x074 | contract cycle (5 villains)
0x075 | last contract (starts as 0x04 to flip to 0x00 on first run)
0x076 | max contract (starts as 0x05)
0x077 | steps left (until end of day)
0x078 | ? //unknown3
0x079 - 0x092 | castle owned by... (0x7F = no one, 0xFF = you, LOW 5 bits = villain)
0x093 - 0x0AC | visited castle N
0x0AD - 0x0C6 | visited town N
0x0C7 | scepter continent ('encrypted')
0x0C8 | scepter X ('encrypted')
0x0C9 | scepter Y ('encrypted')
0x0CA - 0x8C9 | fog of war (1bpp)
0x8CA - 0x94B | garrison troops
0x94C - 0x973 | foeF coords (2 bytes each, 5 per continent)
0x974 - 0x979 | map chests coords (2 bytes each, 1 per continent)
0x97a - 0x981 | orb chests coords (2 bytes each, 1 per continent)
0x982 - 0x991 | teleporter coords (2 bytes each, 2 per continent)
0x992 - 0x9E9 | dwelling coords (2 bytes each, 11 per continent)
0x9EA - 0xB01 | foeH coords (2 bytes each, 35 per continent)
0xB02 - 0xCA5 | foeH troops (3 bytes each)
0xCA6 - 0xE49 | foeH numbers (3 bytes each)
0xE4A - 0xE75 | dwelling N troop
0xE76 - 0xEA1 | dwelling N population
0xEA2 | scepter key (to XOR scepter coords with)
0xEA3 - 0xEA4 | base leadership
0xEA5 - 0xEA6 | leadership
0xEA7 - 0xEA8 | commission
0xEA9 - 0xEAA | followers killed
0xEAB - 0xEB4 | hero army numbers
0xEB5 - 0xFB8 | garrison numbers
0xFB9 - 0xFBA | time stop ("free" steps left)
0xFBB - 0xFBC | days left
0xFBD - 0xFBE | score (never actually used)
0xFBF | ? // unknown1, always "00"
0xFC0 | ? // unknown2, always "00"
0xFC1 - 0xFC4 | gold
0xFC5 - END | map dump
</pre>

=== Notes ===



* Player name is padded with spaces
* There are 26 castles, 26 towns, 17 villains, 25 troops, 14 spells and 4 continents in the game.
* Coordinates always take 2 bytes and always go in X, Y order.
* Scepter coordinates are XORed with ''scepter key'' upon load/save.
* Troop and villain indexes are in production order (as seen in .CC files).
* Dwelling populations are kept in [[BYTE]]s, 250 being maximum possible value.
* Hero and castle army numbers are kept in [[UINT16LE]]s, 5 per army.
* Hostile foes only have 3 troops and their numbers are kept in [[BYTE]]s.
* The ''mount mode'' is also an offset into hero's sprite-sheet.
* The map is a complete dump in [[King's Bounty Map Format]].

=== Coordinates ===

The game is consistent with it's map coordinate system, which goes in the '''bottom-to-top''', left-to-right order. That means top left corner has coordinate X=0, Y=63.

== Credits ==

Originally devised by the [http://sourceforge.net/p/openkb/wiki/Home/ openkb project], with best regards to the modding community.

[[Category:King's Bounty]]
[[Category:File Formats]]
[[Category:Saved Game Files]]

King's Bounty Saved game Format

2013-09-04T12:59:01Z

Driedfruit: adjust whitespace in table

This format is used to save the whole game state for [[King's Bounty]].

As the save files do not require re-insertion into group files, nor are compressed, yet maintain their own full copies of the game world, they provide good opportunity to distribute custom levels or maps.

== File format ==

A save always takes exactly 20421 bytes.

<pre>
0x000 - 0x00A | name
0x00B | class
0x00C | rank
0x00D | spell power
0x00E | max # of spells
0x00F - 0x01F | is villain N caught
0x020 - 0x027 | is artifact N found
0x028 - 0x02B | is continent N available
0x02C - 0x02F | is orb N found
0x030 - 0x03D | number of spells N
0x03E | knows magic
0x03F | siege weapons
0x040 | current contract
0x041 - 0x045 | hero army
0x046 | Option: Delay (0-9)
0x047 | difficulty
0x048 | Option: Sounds
0x049 | Option: Walk Beep
0x04A | Option: Animation
0x04B | Option: Show Army Size
0x04C | hero continent
0x04D | hero X
0x04E | hero Y
0x04F | last X
0x050 | last Y
0x051 | boat X
0x052 | boat Y
0x053 | boat continent (0xFF - no boat)
0x054 | mount mode (0x00 - boat, 0x04 - fly, 0x08 - horse)
0x055 | Option: CGA palette
0x056 - 0x069 | spell sold in town N
0x070 - 0x074 | contract cycle (5 villains)
0x075 | last contract (starts as 0x04 to flip to 0x00 on first run)
0x076 | max contract (starts as 0x05)
0x077 | steps left (until end of day)
0x078 - 0x092 | castle owned by... (0x7F = no one, 0xFF = you, LOW 5 bits = villain)
0x093 - 0x0AC | visited castle N
0x0AD - 0x0C6 | visited town N
0x0C7 | scepter continent ('encrypted')
0x0C8 | scepter X ('encrypted')
0x0C9 | scepter Y ('encrypted')
0x0CA - 0x8C9 | fog of war (1bpp)
0x8CA - 0x94B | garrison troops
0x94C - 0x973 | followerF coords (2 bytes each, 5 per continent)
0x974 - 0x979 | map chests coords (2 bytes each, 1 per continent)
0x97a - 0x981 | orb chests coords (2 bytes each, 1 per continent)
0x982 - 0x991 | teleporter coords (2 bytes each, 2 per continent)
0x992 - 0x9E9 | dwelling coords (2 bytes each, 11 per continent)
0x9EA - 0xB01 | followerH coords (2 bytes each, 35 per continent)
0xB02 - 0xCA5 | followerH troops (3 bytes each)
0xCA6 - 0xE49 | followerH numbers (3 bytes each)
0xE4A - 0xE75 | creature of dwelling N
0xE76 - 0xEA1 | population of dwelling N
0xEA2 | scepter key (to XOR scepter coords with)
0xEA3 - 0xEA4 | base leadership
0xEA5 - 0xEA6 | leadership
0xEA7 - 0xEA8 | commission
0xEA9 - 0xEAA | followers killed
0xEAB - 0xEB4 | hero army numbers
0xEB5 - 0xFB8 | garrison numbers
0xFB9 - 0xFBA | time stop ("free" steps left)
0xFBB - 0xFBC | days left
0xFBD - 0xFBE | score (never actually used)
0xFBF | ? // unknown1, always "00"
0xFC0 | ? // unknown2, always "00"
0xFC1 - 0xFC4 | gold
0xFC5 - END | map dump
</pre>

=== Notes ===



* Player name is padded with spaces
* There are 26 castles, 26 towns, 17 villains, 25 troops, 14 spells and 4 continents in the game.
* Coordinates always take 2 bytes and always go in X, Y order.
* Scepter coordinates are XORed with ''scepter key'' upon load/save.
* Troop and villain indexes are in production order (as seen in .CC files).
* Dwelling populations are kept in [[BYTE]]s, 250 being maximum possible value.
* Hero and castle army numbers are kept in [[UINT16LE]]s, 5 per army.
* Hostile followers only have 3 troops and their numbers are kept in [[BYTE]]s.
* The ''mount mode'' is also an offset into hero's sprite-sheet.
* The map is a complete dump in [[King's Bounty Map Format]].

=== Coordinates ===

The game is consistent with it's map coordinate system, which goes in the '''bottom-to-top''', left-to-right order. That means top left corner has coordinate X=0, Y=63.

== Credits ==

Originally devised by the [http://sourceforge.net/p/openkb/wiki/Home/ openkb project], with best regards to the modding community.

[[Category:King's Bounty]]
[[Category:File Formats]]
[[Category:Saved Game Files]]

Knowledge Dynamics LZW COMPRESSOR

2012-07-06T23:59:30Z

Driedfruit: initial commit

[[Knowledge Dynamics LZW COMPRESSOR]] is a semi-known tool used to compress
executable files by some early DOS games.

The program ("COMPRESSOR v1.01") was is some-what wide use around 1989-1991.
Knowledge Dynamics Corp. were responsible for INSTALL.EXE redist package
that was used by many games, so it is possible that it was part of the same
suite.

The algorithm is very similar to LZEXE, however is different enough to be
incompatible with any version of UNLZEXE tool.

==Games compressed with this COMPRESSOR ==

* [[King's Bounty]]
* [[Tunnels And Trolls: Crusaders Of Khazan]] (1990)
* [[Lexi Cross]] (1991) by Interplay
* [[Sim City]]'s <tt>settings.exe</tt> (1989) by Maxis
* [[Days of Thunder]] (1990) by Argonaut Software

==File Format==
<pre>
offset length purpose
0 0x200 DOS exe header, with wrong block count
0x200 0x3 jump instruction to 0x29C
0x203 unpacker data -- copyright notice, or garbage
0x24D 0x10 unpacker data -- filename
0x25D unpacker data -- error message, or garbage
0x29C 0x3EE unpacker code
0x68a < garbage, will be used for variables in unpacker code >
0x699 0x25 packed header
0x6C0 special buffer, unknown purpose (old reloc. table?)
"offset" packed exe

offset to packed header = main_header.blocks * 512 + main_header.extra_bytes
offset to packed exe = offset_to_packed_header + packed_header.headpars * 16
length of packed exe = filesize - offset_to_packed_exe
length of unpacked exe = packed_header.blocks * 512 + packed_header.extra_bytes
</pre>

* Filename is null-terminated and is padded with 0x24.
* In some games, copyright notice and error message are obfuscated/replaced with garbage.
* Copyright states: "Copyright(C) 1989 Knowledge Dynamics Corp.All rights reserved worldwide."
* Error message is: "Unable to find $..$"

===Signature===
It is hard to tell how many versions of COMPRESSOR existed and how much they
differed. One possible approach is verifying that jump instruction ("e9 99 00")
is at position 0x200.

As strings tend to be unreadable (see above), they could not be used reliably.

==Decompression algorithm==
* copies "packed header" into 0x68a
* copies "unpacker code" [0x200-0x680] to far location
* jumps to far location to execute that code
* opens file "filename"
* seeks to "offset to packed exe"
* unpacks into cs:0000

The compression is identical to the one used in [[CC_Format#Compression]] -- it
is [[LZW_compression]] with dictionary reset.

The unpacked exe is written to offset 0 in memory (offset 0x20 in file).

==Credits==

Devised by openkb project with best regards to modding community.

==Tools==

https://sourceforge.net/p/openkb/code/ci/master/tree/src/tools/unexecomp.c
uncompexe, open-source / public domain decompressor for this format

[[Category:File Formats]]
[[Category:EXE Compression]]
[[Category:Compressed Files]]
[[Category:Compression Algorithms]]

Microsoft EXEPACK

2012-07-06T23:48:32Z

Driedfruit: initial commit

[[Microsoft EXEPACK]] is a an executable file compressor used by several classic games.

EXEPACK compression could be added to a program by <tt>LINK.EXE /EXEPACK</tt>
switch or by invoking <tt>EXEPACK.EXE</tt> utility, that was distributed with MASM.

==Games using EXEPACK==
Some games utilize EXEPACK as an inner layer of their compression:

* [[Ultima 4]]
* [[King's Bounty]]

==Games packed with EXEPACK==

* [[1869]] (1992) by Max Design
* [[A10 Tank Killer]] (1989) by Dynamix
* [[Ace Of Aces]] (1987) by Accolade
* [[Alien Attack]] (1997) by Eldon Martin
* [[Alien Syndrome]] (1987) by Sega Entertainment Inc
* [[Ballrace]] (1988) by Carl Mclawhorn
* [[Barbarian II Dungeons Of Drax]] (1988) by Epyx
* [[Bards Tale Construction Set the]] (1991) by Interplay
* [[Battle Of Austerlitz]] (1989) by Cornerstone Software Inc
* [[Beetlejuice In Skeletons In The Closet]] (1990) by Hi Tech Expressions Inc
* [[Beyond Columns]] (1990) by Sega Entertainment Inc
* [[Bible Builder]] (1992) by Everbright

* [[Big Sea]] (1994) by Starbyte
* [[Bravo Romeo Delta]] (1993) by Frankennstein
* [[Bugs Bunny Hare Brained The]] (1990) by Hi Tech Expressions Inc
* [[California Games]] (1987) by Epyx
* [[California Games II]] (1990) by Epyx
* [[Captain Comic 2 Fractured Reality]] (1990) by Michael Denio
* [[Chessmaster 2100]] (1988) by Software Toolworks
* [[Das Boot]] (1990) by Three Sixty Pacific
* [[Dont Go Alone]] (1989) by Accolade
* [[Ega Roids]] (1986) by Designer Software
* [[Elite]] (1985) by Firebird Software Ltd
* [[Fantasy Pinball]] (1994) by 21st Century Entertainment
* [[Fantasy World Dizzy]] (1990) by Codemasters
* [[Fort Apache]] (1992)
* [[Greens 1.01]] (1992) by Microprose Software Inc
* [[Gunship 2000]] (1990,1991) by Microprose Software Inc
* [[Highway Patrol II]] (1989) by Titus Interactive
* [[Humans 3]] (1996) by Imagitec Design
* [[License To Kill]] (1989) by Domark
* [[Mario Teaches Typing]] (1992) by Interplay
* [[Mean Mini Golf]] (1992) by Johnathon Lexa
* [[Pc Bowl]] (1983) by Bareware Systems
* [[Pc Starglider 2]] (1988) by Argonaut Software
* [[Pinball Dreams]] (1992) by 21st Century Entertainment
* [[Pinball Fantasies]] (1992) by 21st Century Entertainment
* [[Pyramid Of Egypt]] (1989) by Softdisk Publishing

* [[Rocket Ranger]] (1988) by Cinemaware Corporation
* [[Romance Of The Three Kingdoms II]] (1990) by Koei Co Ltd
* [[Star Fleet II Krellan Commander]] (1989) by Interstel
* [[Star Trek 5 The Final Frontier]] (1989) by Mindscape Inc
* [[Street Rod 2 The Next Generation]] (1991) by California Dreams
* [[Tower Toppler]] (1987) by Us Gold
* [[Trek Trivia]] (1988) by Apogee Software Ltd
* [[Ultimate Gin]] (1993) by Accidential Software

* [[World Trophy Soccer]] (1989) by Novotrade

==File Format==
<pre>
offset length purpose
0 0x1C DOS exe header
??? ??? packed exe
0x12 unpacker vars (EXEPACK variables, see below)
0x105 unpacker code
0x16 string "Packed file is corrupt"
??? packed reloc table (see below for more information)

offset to packed exe = header * 16 (from exe header)
length of packed exe = CS:IP (from exe header)
length of packed reloc table = exepack_size - dest_len (from exepack variables)
</pre>
===EXEPACK variables===
Variables used by the exepack unpacker (all except <tt>mem_start</tt> are pre-initialized):

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||real_IP||real start address (offset)
|-
|[[UINT16LE]]||real_CS||real start address (offset)
|-
|[[UINT16LE]]||mem_start||start of the exe in memory (segment)
|-
|[[UINT16LE]]||exepack_size||size of <tt>unpacker vars + unpacker code + error string + packed reloc table</tt> in bytes
|-
|[[UINT16LE]]||real_SP||real stack (offset)
|-
|[[UINT16LE]]||real_SS||real stack (segment)
|-
|[[UINT16LE]]||dest_len||destination of the unpacker code (in paragraphs, relative to start of exe in memory)
|-
|[[UINT16LE]]||skip_len||<i>number of paragraphs between packed exe and unpacker variables</i> + 1
|-
|[[UINT16LE]]||signature||"RB" (magic number of exepacked files)
|}
===Relocation Table===
<pre>
packed relocation table = section_0, section_1, ..., section_0xf
section = number_of_entries [can be zero], set of entry [can be empty]
number_of_entries = unsigned word (16 bits)
entry = unsigned word (16 bits)

An entry in section n patches the segment value at:
0x1000*n + entry (relative to the start of the exe in memory)
</pre>
==Decompression algorithm==
The exepack unpacker first copies itself to the location stored in <tt>dest_len</tt>.
(the value in <tt>dest_len</tt> also equals the unpacked exe's size in paragraphs).
It then executes a retf to the new location and starts unpacking.
The unpacking algorithm works like this:

<source lang="c">
int srcPos; /* start at the end of the packed exe, because the unpacker works downwards */
int dstPos;
int commandByte, lengthWord, fillByte;

/* skip all 0xff bytes (they're just padding to make the packed exe's size a multiple of 16 */
while (*srcPos == 0xff) {
srcPos--;
}

/* unpack */
do {
commandByte = *(srcPos--);

switch (commandByte & 0xFE) {
/* (byte)value (word)length (byte)0xb0 */
/* writes a run of <length> bytes with a value of <value> */
case 0xb0:
lengthWord = (*(srcPos--))*0x100;
lengthWord += *(srcPos--);
fillByte = *(srcPos--);
for (i = 0; i < lengthWord; i++) {
*(dstPos--) = fillByte;
}
break;
/* (word)length (byte)0xb2 */
/* copies the next <length> bytes */
case 0xb2:
lengthWord = (*(srcPos--))*0x100;
lengthWord += *(srcPos--);
for (i = 0; i < lengthWord; i++) {
*(dstPos--) = *(srcPos--);
}
break;
/* unknown command */
default:
printf("Unknown command %x at position %x\n", commandByte, srcPos);
exit(1);
break;
}
} while ((commandByte & 1) != 1); /* lowest bit set => last block */
</source>

Notes:
* The sizes of both the packed exe and the unpacked exe are multiples of 16
* The unpacker code unpacks the exe onto itself, i.e. the unpacked exe has the same starting address (in memory) as the packed exe (in memory).

==Credits==

This information was adopted from http://cvs.z88dk.org/cgi-bin/viewvc.cgi/xu4/doc/avatarExepacked.txt?revision=1.1&root=zxu4&view=markup
by aowen. The source page said:
<blockquote>
Please send additions, corrections and feedback to this e-mail address:
Remove space + vowels from "marc winterrowd" and append "at yahoo dot com"
</blockquote>

==Tools==

http://www.tbcnet.com/~clive/unpack.zip
http://www.tbcnet.com/~clive/vcomwinp.html
UNPACK, a DOS program written by Clive Turvey, that decompresses files packed with Microsoft EXEPACK.

https://sourceforge.net/p/openkb/code/ci/master/tree/src/tools/unexepack.c
unexepack, open-source / public domain exepack decompressor

[[Category:File Formats]]
[[Category:EXE Compression]]
[[Category:Compressed Files]]
[[Category:Compression Algorithms]]
[[Category:Code examples]]

King's Bounty

2012-07-06T23:42:30Z

Driedfruit: added info on exe compression

{{Stub}}

{{GamePage}}
== File formats ==

This section lists the major file formats used in the game.

* [[CC Format]] - Group files (<tt>416.CC, 256.CC</tt>)
* [[King's Bounty Graphics Format|.4/.16/.256 Format]] - Graphics format (<tt>*.4, *.16, *.256</tt>)
* [[King's Bounty Map Format|ORG Format]] - World map (<tt>LAND.ORG</tt>)
* [[King's Bounty Saved game Format|DAT Format]] - Save files (<tt>*.DAT</tt>)
* CH Format - Bitmap font, 8x8 1bpp (<tt>KB.CH</tt>)
* [[King's Bounty Music Format|Music Format]] - Music format (stored internally in <tt>KB.EXE</tt>)

== EXE compression ==

The 1995 version of <tt>kb.exe</tt> contains no compression. The 1990 version is compressed twice: with
[[Microsoft EXEPACK]] in inner layer and [[Knowledge Dynamics LZW COMPRESSOR]] in outer layer.
To mod this version, both compressions should be removed. Telling two versions apart is easy - uncompressed
exe is 113718 bytes long, while compressed takes only 79839 bytes.

== External links ==
* [https://sourceforge.net/p/openkb/wiki/Home/ OpenKB] - open-source clone / digital preservation project.

King's Bounty Music Format

2011-09-09T07:51:00Z

Driedfruit: offsets and description

[[King's Bounty]] stores it's PC speaker music in the EXE file*.

* Note: The 1990 version of the EXE is compressed by unknown compression, and so is not described here yet. The offsets listed are for the 1995 version.

{|class="wikitable"
!Offset!!Data Type!!Description
|-
|0x18B5D||[[BYTE]] str[]||Tunes (2 bytes per note, <tt>0xFF</tt> marks end)
|-
|0x18B97||[[UINT16LE]] freq[]||Note palette (frequencies)
|-
|0x18C47 ||[[UINT16LE]] delay[]||Duration palette
|-
|0x18C67||[[UINT16LE]] offsets[10]||Offsets into tunes (add <tt>0x15850</tt>)
|-
|}

For example, tune #0's offset (at 0x18C67) is <tt>0x330D</tt>, which leads us to <tt>0x18B5D</tt> (<tt>0x15850+0x330D</tt>). There, we see:
<pre>
0x28 0x07 0xFF
</pre>

Which are: index into note palette, index into duration palette, end marker. In default palettes, note <tt>0x28</tt> is 65 hz, and duration <tt>0x07</tt> is a 15 ms delay.

[[Category:King's Bounty]]
[[Category:Sound Files]]

CC Format

2011-08-31T01:22:11Z

Driedfruit: renames 'crc keys' into 'hashes', fills out missing info

The '''CC format''' is how files in the game [[King's Bounty]] are stored. Files in this format have the ".CC" extension, which probably stands for "crude" or "compact" compression. It's a group file format with compression (similar to .zip file) with a simple file allocation table in it's header.

The game will check the current directory for files only if they weren't found in the CC file first.

== File format ==

The first 1122 bytes of the file consists of file entries, with the remainder containing the data. Each file entry takes 8 bytes, and consists of the filename hash, it's offset and compressed length.

=== Signature ===

There is no known signature for this format. One method to identify files is to read in the file entries (as there is a fixed maximum of these, all 1122 bytes must be present for the file to be valid) and confirm that each file offset refers to a location after a previous file offset (that is not the requirement of the format, but that is how the original CC files are composed), and that offset is within file boundary.

=== Header ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||numFiles||Number of entries
|-
|struct FileEntry||entries[]||Array of entries
|}

The 1120 bytes available makes enough room for 140 files. However, the largest amount actually seen - 136 files in 416.CC leaves 64 bytes unused.

=== File entry ===

A file entry is laid out as follows.

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||hash||Filename hash
|-
|UINT24LE||offset||File offset from start of group file
|-
|UINT24LE||size||Size of compressed data
|}

Note the weird 24-bit data type. It is indeed an unsigned integer composed from 3 bytes in little endian order.

The hash key for a filename could be calculated as follows:
<source lang="c">
//word is UINT16LE
word cc_filename_hash(char *filename)
{
word key = 0;
byte next;

while ((next = *filename++))
{
next &= 0x7F;
if (next >= 0x60)
next -= 0x20;

/* Swap high and low bytes */
key = ((key >> 8) & 0x00FF) | ((key << 8) & 0xFF00);

/* Rotate left by 1 bit */
key = (key << 1) | ((key >> 15) & 0x0001);

key += next;
}

return key;
}
</source>

As the filenames themselves are not stored in the group file, only their hashes are, we must have a prepared list of filenames handy. The game keeps it in the EXE file.

The files are:
<pre>
// Add .4, .16 or .256 extension to those:
char *graf_files[] = {
//Troops
"peas","spri","mili","wolf","skel","zomb","gnom","orcs","arcr","elfs",
"pike","noma","dwar","ghos","kght","ogre","brbn","trol","cavl","drui",
"arcm","vamp","gian","demo","drag",

//Villains
"mury","hack","ammi","baro","drea","cane","mora","barr","barg","rina",
"ragf","mahk","auri","czar","magu","urth","arec",

"knig","pala","sorc","barb","nwcp","title","select",
"tileseta","tilesetb","tilesalt","cursor","town","cstl","plai",
"frst","dngn","cave","comtiles","view","endpic"
};
// Use as is:
char *extra_files[] = {
"KB.CH", // 1bpp 8x8 font file
"LAND.ORG", // world map
"TIMER.DRV",
"SOUND.DRV",
"CGA.DRV",
"EGA.DRV",
"TGA.DRV",
"HGA.DRV",
"MCGA.DRV",
};
</pre>

The .4, .16 and .256 files are graphics, kept in [[King's Bounty Graphics Format]].

All files are compressed.

== Compression ==

At each offset, a data chunk is located:

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT32LE]]||size||Size of uncompressed data
|-
|[[BYTE]]||lzwData[]||Compressed data
|}

The data is compressed by [[LZW compression]] with the following characteristics:
* Codeword takes from 9 to 12 bits (as in Commander Keen)
* <tt>0x0100</tt> codeword instructs '''dictionary reset''' and not '''error'''
The '''dictionary reset''' is performed like this:
<pre>
the dictionary is cleared
(the bit step is made 9 bits again)
one more value is being read from input
that value is written to output as-is
that value is NOT saved into the dictionary
</pre>

== Credits ==

Originally devised by the [http://sourceforge.net/p/openkb/wiki/Home/ openkb project], with best regards to the modding community.

[[Category:King's Bounty]]
[[Category:File Formats]]
[[Category:Group Files]]
[[Category:Group Files supporting compression]]
[[Category:Group Files with hashed filenames]]

King's Bounty Saved game Format

2011-08-30T04:38:04Z

Driedfruit: adds savegame format information

This format is used to save the whole game state for [[King's Bounty]].

As the save files do not require re-insertion into group files, nor are compressed, yet maintain their own full copies of the game world, they provide good opportunity to distribute custom levels or maps.

== File format ==

A save always takes exactly 20421 bytes.

<pre>
0x000 - 0x00A | name
0x00B | class
0x00C | rank
0x00D | spell power
0x00E | max # of spells
0x00F - 0x01F | is villain N caught
0x020 - 0x027 | is artifact N found
0x028 - 0x02B | is continent N available
0x02C - 0x02F | is orb N found
0x030 - 0x03D | number of spells N
0x03E | knows magic
0x03F | siege weapons
0x040 | current contract
0x041 - 0x045 | hero army
0x046 | Option: Delay (0-9)
0x047 | difficulty
0x048 | Option: Sounds
0x049 | Option: Walk Beep
0x04A | Option: Animation
0x04B | Option: Show Army Size
0x04C | hero continent
0x04D | hero X
0x04E | hero Y
0x04F | last X
0x050 | last Y
0x051 | boat X
0x052 | boat Y
0x053 | boat continent (0xFF - no boat)
0x054 | mount mode (0x00 - boat, 0x04 - fly, 0x08 - horse)
0x055 | Option: CGA palette
0x056 - 0x069 | spell sold in town N
0x070 - 0x074 | contract cycle (5 villains)
0x075 | last contract (starts as 0x04 to flip to 0x00 on first run)
0x076 | max contract (starts as 0x05)
0x077 | steps left (until end of day)
0x078 - 0x092 | castle owned by... (0x7F = no one, 0xFF = you, LOW 5 bits = villain)
0x093 - 0x0AC | visited castle N
0x0AD - 0x0C6 | visited town N
0x0C7 | scepter continent ('encrypted')
0x0C8 | scepter X ('encrypted')
0x0C9 | scepter Y ('encrypted')
0x0CA - 0x8C9 | fog of war (1bpp)
0x8CA - 0x94B | garrison troops
0x94C - 0x973 | followerF coords (2 bytes each, 5 per continent)
0x974 - 0x979 | map chests coords (2 bytes each, 1 per continent)
0x97a - 0x981 | orb chests coords (2 bytes each, 1 per continent)
0x982 - 0x991 | teleporter coords (2 bytes each, 2 per continent)
0x992 - 0x9E9 | dwelling coords (2 bytes each, 11 per continent)
0x9EA - 0xB01 | followerH coords (2 bytes each, 35 per continent)
0xB02 - 0xCA5 | followerH troops (3 bytes each)
0xCA6 - 0xE49 | followerH numbers (3 bytes each)
0xE4A - 0xE75 | creature of dwelling N
0xE76 - 0xEA1 | population of dwelling N
0xEA2 | scepter key (to XOR scepter coords with)
0xEA3 - 0xEA4 | base leadership
0xEA5 - 0xEA6 | leadership
0xEA7 - 0xEA8 | commission
0xEA9 - 0xEAA | followers killed
0xEAB - 0xEB4 | hero army numbers
0xEB5 - 0xFB8 | garrison numbers
0xFB9 - 0xFBA | time stop ("free" steps left)
0xFBB - 0xFBC | days left
0xFBD - 0xFBE | score (never actually used)
0xFBF | ? // unknown1, always "00"
0xFC0 | ? // unknown2, always "00"
0xFC1 - 0xFC4 | gold
0xFC5 - END | map dump
</pre>

=== Notes ===



* Player name is padded with spaces
* There are 26 castles, 26 towns, 17 villains, 25 troops, 14 spells and 4 continents in the game.
* Coordinates always take 2 bytes and always go in X, Y order.
* Scepter coordinates are XORed with ''scepter key'' upon load/save.
* Troop and villain indexes are in production order (as seen in .CC files).
* Dwelling populations are kept in [[BYTE]]s, 250 being maximum possible value.
* Hero and castle army numbers are kept in [[UINT16LE]]s, 5 per army.
* Hostile followers only have 3 troops and their numbers are kept in [[BYTE]]s.
* The ''mount mode'' is also an offset into hero's sprite-sheet.
* The map is a complete dump in [[King's Bounty Map Format]].

=== Coordinates ===

The game is consistent with it's map coordinate system, which goes in the '''bottom-to-top''', left-to-right order. That means top left corner has coordinate X=0, Y=63.

== Credits ==

Originally devised by the [http://sourceforge.net/p/openkb/wiki/Home/ openkb project], with best regards to the modding community.

[[Category:King's Bounty]]
[[Category:File Formats]]
[[Category:Saved Game Files]]

King's Bounty Map Format

2011-08-30T03:14:48Z

Driedfruit: adds map format information

This format is used to store the world map for [[King's Bounty]] in both it's initial state (<tt>LAND.ORG</tt> file) and in modified, randomized state (in the <tt>*.DAT</tt> save files at offset <tt>0xFC5</tt>). Consequently, there are minor format differences, described below.

== File format ==

The map always takes exactly 16384 bytes. As there are 4 continents 64 x 64 tiles each, and each tile takes 1 byte, all continents start at a convenient offset - 0x0000, 0x1000, 0x2000 or 0x3000.

{|class="wikitable"
!Data type!!Description
|-
|[[BYTE]] map[4][64][64]||Map data
|-
|}

=== Coordinates ===

The game is consistent with it's map coordinate system, which goes in the '''bottom-to-top''', left-to-right order. That means top left corner has coordinate X=0, Y=63.

=== Salting ===

When a new game is first created, the initial map data is read and then the following values are replaced:

<pre>
0xFF - continent start -> 0x20 - sea tile
0x8B - put something random here -> 0x8B - 0x93 , but not 0x90
0x8E - archmage's alcove -> 0x00 (for mages) / 0x8E (for rest)
</pre>

Note, that the <tt>0x8B</tt> index is used in both initial and salted data with different meanings - it stands for ''random object'' in <tt>LAND.ORG</tt>, and a ''treasure chest'' in the save files.

=== Tileset ===

The tileset is kept inside the <tt>tileseta.*</tt> and <tt>tilesetb.*</tt> graphic files. Each file contains 36 tiles, making 72 in total. ''Additionally, <tt>tilesalt.*</tt> contains replacements graphics for tiles <tt>0x11-0x13</tt> for continents 2-4''. Each level byte '''with it's most significant bit cleared''' maps directly into that range (<tt>0x00-0x47</tt>). The high bit signifies if the tile is interactive, and those high-bit versions are always used instead of the regular indexes:

<pre>
0x80 - magic barrier (blocks followers)
0x85 - castle gate
0x8A - town
0x8B - treasure chest
0x8C - plains dwelling
0x8D - forest dwelling
0x8E - cave dwelling (multiple purposes)
0x8F - dungeon dwelling
0x90 - sign
0x91 - follower
0x92 - artifact 1
0x93 - artifact 2
</pre>

=== Constant Locations ===

Those locations are hard-coded into the game and can not be changed from within the map:
<pre>
X=11 Y=7 - King's Castle
X=11 Y=6 - Retreat location
X=11 Y=5 - Starting Location
X=11 Y=3 - Continent 1 starting location
X=1 Y=37 - Continent 2 starting location
X=14 Y=62 - Continent 3 starting location
X=9 Y=1 - Continent 4 starting location
X=11 Y=19 - Archmage's Alcove
</pre>

== Credits ==

Originally devised by the [http://sourceforge.net/p/openkb/wiki/Home/ openkb project], with best regards to the modding community.

[[Category:File Formats]]
[[Category:Map Files]]


[[Category:King's Bounty]]

King's Bounty

2011-08-30T01:28:53Z

Driedfruit: changes format names a bit

CC Format

2011-08-23T21:12:27Z

Driedfruit: corrects filename list, removes useless compression info in favor of link to LZW

The '''CC format''' is how files in the game [[King's Bounty]] are stored. Files in this format have the ".CC" extension, which probably stands for "crude" or "compact" compression. It's a group file format with compression (similar to .zip file) which stores CRC key, offset and some unknown metadata for each file.

The game will check the current directory for files only if they weren't found in the CC file first.

== File format ==

The first 1122 bytes of the file consists of file entries, with the remainder containing the data. Each file entry takes 8 bytes, and consists of the filename crc, its offset and some unknown value.

=== Signature ===

There is no known signature for this format. One method to identify files is to read in the file entries (as there is a fixed maximum of these, all 1122 bytes must be present for the file to be valid) and confirm that each file offset refers to a location after a previous file offset (that is not the requirement of the format, but that is how the original CC files are composed), and that offset is within file boundary.

=== Header ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||numFiles||Number of entries
|-
|struct FileEntry||entries[]||Array of entries
|}

The 1120 bytes available makes enough room for 140 files. However, the largest amount actually seen - 136 files in 416.CC leaves 64 bytes unused.

=== File entry ===

A file entry is laid out as follows.

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||crcKey||CRC of the filename
|-
|UINT24LE||offset||File offset from start of group file
|-
|BYTE||???||Unknown, likely bit flags
|}

Note the weird 24-bit data type. The 3 bytes that follow the crcKey ''do'' form ONE value, while the 4th byte means something
else entirely (what exactly is presently unknown).

The crc key for a filename could be calculated as follows:
<source lang="c">
//word is UINT16LE
word crcFilename(char *filename)
{
word key = 0;
byte next;

while ((next = *filename++))
{
next &= 0x7F;
if (next >= 0x60)
next -= 0x20;

/* Swap high and low bits */
key = ((key >> 8) & 0x00FF) | ((key << 8) & 0xFF00);

/* Rotate left by 1 bit */
key = (key << 1) | ((key >> 15) & 0x0001);

key += next;
}

return key;
}
</source>

As the filenames themselves are not stored in the group file, only their CRC keys, we must have a prepared list of filenames handy. The game keeps it in the EXE file.

The files are:
<pre>
// Add .4, .16 or .256 extension to those:
char *graf_files[] = {
"peas","spri","mili","wolf","skel","zomb","gnom","orcs","arcr","elfs",
"pike","noma","dwar","ghos","kght","ogre","brbn","trol","cavl","drui",
"arcm","vamp","gian","demo","drag","mury","hack","ammi","baro","drea",
"cane","mora","barr","barg","rina","ragf","mahk","auri","czar","magu",
"urth","arec","knig","pala","sorc","barb","nwcp","title","select",
"tileseta","tilesetb","tilesalt","cursor","town","cstl","plai",
"frst","dngn","cave","comtiles","view","endpic"
};
// Use as is:
char *extra_files[] = {
"KB.CH", // 1bpp 8x8 font file
"LAND.ORG", // world map
"TIMER.DRV",
"SOUND.DRV",
"CGA.DRV",
"EGA.DRV",
"TGA.DRV",
"HGA.DRV",
"MCGA.DRV",
};
</pre>

The .4, .16 and .256 files are graphics, kept in [[King's Bounty Graphics Format]].

All files are compressed.

== Compression ==

At each offset, a data chunk is located:

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||size||Size of uncompressed data
|-
|[[UINT16LE]]||???||Unknown, always 0000
|-
|[[BYTE]]||lzwData[]||Compressed data
|}

The data is compressed by [[LZW compression]] with the following characteristics:
* Codeword takes from 9 to 12 bits (as in Commander Keen)
* <tt>0x0100</tt> codeword instructs '''dictionary reset''' and not '''error'''
The '''dictionary reset''' is performed like this:
<pre>
the dictionary is cleared
(the bit step is made 9 bits again)
one more value is being read from input
that value is written to output as-is
that value is NOT saved into the dictionary
</pre>

== Credits ==

Originally devised by the [http://sourceforge.net/p/openkb/wiki/Home/ openkb project], with best regards to the modding community.

[[Category:King's Bounty]]
[[Category:File Formats]]
[[Category:Group Files]]
[[Category:Group Files supporting compression]]
[[Category:Group Files with hashed filenames]]

Talk:CC Format

2011-08-23T19:31:44Z

Driedfruit:

King's Bounty

2011-08-23T07:14:06Z

Driedfruit: removes wrong palette info, adds LAND.ORG refrence

King's Bounty Graphics Format

2011-08-23T07:05:06Z

Driedfruit:

[[King's Bounty]] stores all its graphics in external files in this format, packed into group files.

The CGA & EGA graphic files (4 and 16 colors) have the ".4" and ".16" extensions (<tt>title.4, title.16</tt>) and are kept in the <tt>416.CC</tt> file.

The VGA graphic files (256 colors) have the ".256" extension (<tt>title.256</tt>) and are kept in the <tt>256.CC</tt> file, except for <tt>endpic.256</tt>, which is kept in <tt>416.CC</tt> for some reason.

== Compression ==

All files are compressed as described in the [[CC Format]].

== File structure ==

The file starts with the number of chunks (graphics) in the file, followed by a number of values giving the offset of each chunk and a mask/color key offset.

If a graphic doesn't have a mask (background tile, title screen), the offset for the mask is 0x0000.

=== Header ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||count||Number of images in the file
|-
|struct Entry||entries[]||Array of image and mask offsets
|}

=== Graphic Entry ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||offset||Offset from start of file to image data
|-
|[[UINT16LE]]||mask_offset||Offset from start of file to mask data (0 if no mask)
|}

For VGA images, '''mask_offset''' points somewhere inside the image data, specifying which pixel should be treated as the color key.

== Image formats ==

=== Images ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||width||Image width, also pitch
|-
|[[UINT16LE]]||height||Image height
|-
|[[BYTE]]||data[]||Image data
|}

==== CGA ====

CGA data is 2bpp linear.

The actual colours for each pixel depend on the active CGA palette, the game allows up to 8 choices. See [[wp:Color Graphics Adapter]] for details.

==== EGA ====

Unlike many other DOS games, EGA data is linear too, 4bpp this time.

==== VGA ====

The VGA data is standard 8bpp single-plane data. The palette can be found in <tt>MCGA.DRV</tt> file, at offset <tt>0x032D</tt>. It's in [[VGA Palette|classic VGA format]] (6-bit RGB).

=== Masks ===

Masks are always linear 1bpp '''without''' the width and height data (the values of the actual image are used). Masks do not exist for VGA graphics, color keys are used instead (see above).

== Credits ==
Devised by the openkb project with best regards to the modding community.

[[Category: King's Bounty]]
[[Category: File Formats]]
[[Category: Graphics Files]]

King's Bounty

2011-08-22T20:50:29Z

Driedfruit: Created page with "{{Stub}} {{GamePage}} == File formats == This section lists the major file formats used in the game. * CC Format - Group files (<tt>416.CC, 256.CC</tt>) * [[King's Bounty ..."

King's Bounty Graphics Format

2011-08-22T20:20:06Z

Driedfruit: Created page with "King's Bounty stores all its graphics in external files in this format, packed into group files. The VGA graphic files (256 colors) have the ".256" extension ("title.256") a..."

[[King's Bounty]] stores all its graphics in external files in this format, packed into group files.

The VGA graphic files (256 colors) have the ".256" extension ("title.256") and are kept in the "256.CC" file.

The CGA & EGA graphic files (4 and 16 colors) have the ".4" and ".16" extensions ("title.4", "title.16") and are kept in the "416.CC" file.

== Compression ==

All files are compressed as described in the [[CC Format]].

== File structure ==

The file starts with the number of chunks (graphics) in the file, followed by a number of values giving the offset of each chunk and it's mask.

If a graphic doesn't have a mask (background tile, title screen), the offset for the mask is 0x0000.

=== Header ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||count||Number of images in the file
|-
|struct Entry||entries[]||Array of image and mask offsets
|}

=== Graphic Entry ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||offset||Offset from start of file to image data
|-
|[[UINT16LE]]||mask_offset||Offset from start of file to mask data (0 if no mask)
|}

== Image formats ==

=== Images ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||width||Image width, also pitch
|-
|[[UINT16LE]]||height||Image height
|-
|[[BYTE]]||data[]||Image data
|}

==== CGA ====

CGA data is 2bpp linear.

The actual colours for each pixel depend on the active CGA palette, the game allows up to 8 choices. See [[wp:Color Graphics Adapter]] for details.

==== EGA ====

Unlike many other DOS games, EGA data is linear too, 4bpp this time.

==== VGA ====

The VGA data is standard 8bpp single-plane data. The palette is stored in the main EXE file (see [[King's Bounty]] for its location.)

=== Masks ===

Masks are always linear 1bpp '''without''' the width and height data (Use the values of the actual image).

== Credits ==
Devised by the openkb project with best regards to the modding community.

[[Category: King's Bounty]]
[[Category: File Formats]]
[[Category: Graphics Files]]

CC Format

2011-08-22T19:32:16Z

Driedfruit: initial import and mediawiki-fication of CC format description

The '''CC format''' is how files in the game [[King's Bounty]] are stored. Files in this format have the ".CC" extension, which probably stands for "crude" or "compact" compression. It's a group file format with compression (similar to .zip file) which stores CRC key, offset and some unknown metadata for each file.

The game will check the current directory for files only if they weren't found in the CC file first.

== File format ==

The first 1122 bytes of the file consists of file entries, with the remainder containing the data. Each file entry takes 8 bytes, and consists of the filename crc, its offset and some unknown value.

=== Signature ===

There is no known signature for this format. One method to identify files is to read in the file entries (as there is a fixed maximum of these, all 1122 bytes must be present for the file to be valid) and confirm that each file offset refers to a location after a previous file offset (that is not the requirement of the format, but that is how the original CC files are composed), and that offset is within file boundary.

=== Header ===

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||numFiles||Number of entries
|-
|struct FileEntry||entries[]||Array of entries
|}

The 1120 bytes available makes enough room for 140 files. However, the largest amount actually seen - 136 files in 416.CC leaves 64 bytes unused.

=== File entry ===

A file entry is laid out as follows.

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||crcKey||CRC of the filename
|-
|UINT24LE||offset||File offset from start of group file
|-
|BYTE||???||Unknown, likely bit flags
|}

Note the weird 24-bit data type. The 3 bytes that follow the crcKey ''do'' form ONE value, while the 4th byte means something
else entirely (what exactly is presently unknown).

The crc key for a filename could be calculated as follows:
<source lang="c">
//word is UINT16LE
word crcFilename(char *filename) {
int i;

word key = 0;
byte next;

while ((next = *filename++))
{
next &= 0x7F;
if (next >= 0x60)
next -= 0x20;

/* Swap high and low bits */
key = ((key >> 8) & 0x00FF) | ((key << 8) & 0xFF00);

/* Rotate left by 1 bit */
key = (key << 1) | ((key >> 15) & 0x0001);

key += next;
}

return key;
}
</source>

As the filenames themselves are not stored in the group file, only their CRC keys, we must have a prepared list of filenames handy. The game keeps it in the EXE file.

The files are:
<pre>
// Add .4, .16 or .256 extension to those:
char *graf_files[] = {
"peas","spri","mili","wolf","skel","zomb","gnom","orcs","arcr","elfs",
"pike","noma","dwar","ghos","kght","ogre","brbn","trol","cavl","drui",
"arcm","vamp","gian","demo","drag","mury","hack","ammi","baro","drea",
"cane","mora","barr","barg","rina","ragf","mahk","auri","czar","magu",
"urth","arec","knig","pala","sorc","barb","nwcp","title","select",
"tileseta","tilesetb","tilesalt","cursor","town","cstl","plai",
"frst","dngn","cave","comtiles","view","endpic","land","org",
};
// Use as is:
char *extra_files[] = {
"KB.CH", // 1bpp 8x8 font file
"TIMER.DRV",
"SOUND.DRV",
"CGA.DRV",
"EGA.DRV",
"TGA.DRV",
"HGA.DRV",
"MCGA.DRV",
"VGA.DRV",
};
</pre>

The .4, .16 and .256 files are graphics, kept in [[King's Bounty Graphics Format]].

There's also a mysterious file with key '0xEA34', taking exactly '0x4000' bytes, filename/purpose presently unknown.

All files are compressed.

== Compression ==

Before the compressed block starts, there's a mini-header:

{|class="wikitable"
!Data type!!Name!!Description
|-
|[[UINT16LE]]||size||Size of uncompressed data
|-
|[[UINT16LE]]||???||Unknown, always 0000
|}

Then, the rest of the data is kept in BIT-positioned "blocks". Each "block" can take from 9 to 12 bits of data. Last 8 bits are "the value". First N bits are "the key". If the "the key" is unset (00), the value is read as-is. Otherwise, the whole "block" (N+8 bytes) is treated as a dictionary key, and the dictionary is queried.

The exceptions are the 0x0100 value, which means the dictionary must be cleared, and the 0x0101 value, which marks END OF FILE.

<pre>
0. STEP = 9, CLEAR DICTIONARY

1. Read BLOCK of bit-size STEP

VALUE = low byte of BLOCK

if BLOCK = 0101 -- END

if BLOCK = 0100
STEP = 9
CLEAR DICTIONARY
OUTPUT VALUE
LAST_BLOCK = BLOCK
GOTO 1

if (BLOCK > DICTIONARY ENTRIES)
BLOCK = LAST BLOCK

OUTPUT VALUE

if (BLOCK is DICTIONARY INDEX)
OUTPUT WHOLE DICTIONARY[BLOCK]

Save BLOCK to DICTIONARY
Save VALUE to DICTIONARY

if (too much entries in dictionary)
INCREASE bit STEP

LAST_BLOCK = BLOCK
GOTO 1
</pre>

Each dictionary entry consists of an index to a previous entry and a value, forming a tree. Therefore, when we query the dictionary and get a hit, we then climb the tree backwards.

<pre>
Save:
dict_val[BLOCK] = VALUE
dict_prev[BLOCK] = LAST_BLOCK

Read:
WHILE BLOCK
OUTPUT dict_val[BLOCK]
BLOCK = dict_prev[BLOCK]
</pre>

== Credits ==

Originally devised by openkb project, with best regards to the modding community.

[[Category:King's Bounty]]
[[Category:File Formats]]
[[Category:Group Files]]
[[Category:Group Files supporting compression]]