ModdingWiki - User contributions [en-gb]

User:Ceidwad

2015-06-08T18:37:59Z

Ceidwad:

Longtime hobbyist reverse engineer.

Games I'm contributing info for:
 Captain Comic
 Captain Comic 2: Fractured Reality
 Death Rally
 Lost Files of Sherlock Holmes: Case of the Serrated Scalpel
 The Lion King

I have an extensive archive of info for other games that I will be uploading as time allows. Drop me a line if you have a favourite game for which you'd like file format info and I'll see what I can do!

Death Rally BPA Format

2015-06-08T18:36:33Z

Ceidwad:

{{Archive Infobox
| MaxFiles = 255
| FAT = Start
| Names = Yes, 8.3
| Metadata = None
| Subdirectories = N
| Compressed = N
| Encrypted = Y
| Hidden = N
| Game1 = Death Rally
}}

The BPA file format is an archive format used by [[Death Rally]].

== Header ==

{|class="wikitable"
!Data type!!Description
|-
|[[UINT32LE]] numFiles||Number of files in the archive
|-
|<tt>FILEREC</tt>[255] fileRecords||Encrypted FAT
|}

Each <tt>FILEREC</tt> is of the form

{|class="wikitable"
!Data type!!Description
|-
|[[char]][13] encryptedName||See below for filename encryption
|-
|[[UINT32LE]] compressedSize||Size of the compressed file data
|}

The <tt>FILEREC</tt> table has a fixed size of 255 * 17 bytes, padded with null bytes, and cannot contain more than 255 <tt>FILEREC</tt>s. Compressed file data begins immediately after the table, at offset 0x10F3. Because the header does not store offsets, these must be calculated by accumulating through the table.

== Filename encryption ==

To restore a filename, subtract <tt>117 - 3 * index</tt> from each byte, where <tt>index</tt> is the 0-based index of the byte in the filename. This will yield a null-terminated string in uppercase. The encrypted filename is also null-terminated.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Death Rally BPA Format

2015-06-08T18:35:28Z

Ceidwad: Added.

{{Archive Infobox
| MaxFiles = 255
| FAT = Start
| Names = Yes, 8.3
| Metadata = None
| Subdirectories = N
| Compressed = N
| Encrypted = Y
| Hidden = N
| Game1 = Death Rally
}}

The BPA file format is an archive format used by [[Death Rally]].

== Header ==

{|class="wikitable"
!Data type!!Description
|-
|[[UINT32LE]] numFiles||Number of files in the archive
|-
|<tt>FILEREC</tt>[255] fileRecords||Encrypted FAT
|}

Each <tt>FILEREC</tt> is of the form

{|class="wikitable"
!Data type!!Description
|-
|[[char]][13] encryptedName||See below for filename encryption
|-
|[[UINT32LE]] compressedSize||Size of the compressed file data
|}

The <tt>FILEREC</tt> table has a fixed size of 255 * 17 bytes, padded with null bytes, and cannot contain more than 255 <tt>FILEREC</tt>s. Compressed file data begins immediately after the table, at offset 0x10F3. Because the header does not store offsets, these must be calculated by accumulating through the table.

== Filename encryption ==

To restore a filename, subtract <tt>117 - 3 * index</tt> from each byte, where <tt>index</tt> is the 0-based index of the byte in the filename. This will yield a null-terminated string in uppercase.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Lion King Level Format

2015-06-08T02:08:05Z

Ceidwad: clarification of extra layers, more to come when I actually play the game

{{Map Infobox
| Type = 2D tile-based
| Layers = 6
| Tile size = 8×8
| Viewport = 320×200
| Game1 = The Lion King
}}
[[The Lion King]] '''MAP Format''' is used to store game levels.

== File format ==

=== Header ===

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT32LE]] || paletteOffset || Offset of 256-colour VGA palette
|-
| [[UINT32LE]] || tilesetOffset || Offset of 8x8 tiles
|-
| [[UINT32LE]] || foregroundWidth ||rowspan=2|Size of foreground layers in tiles
|-
| [[UINT32LE]] || foregroundHeight
|-
| [[UINT32LE]] || layersOffset || Offset of foreground layer data
|-
| [[UINT32LE]] || backgroundWidth ||rowspan=2|Size of background layer in tiles
|-
| [[UINT32LE]] || backgroundHeight
|-
| [[UINT32LE]] || background || Offset of first background layer data
|-
| [[BYTE]][96] || padding || Set to 0x00
|}

The header is padded by null bytes up to offset 0x80.

Note the different dimensions of the foreground and background layers. The game uses parallax scrolling for the background layer.

Most levels have one (backgroundWidth, backgroundHeight, background) structure, but other numbers are supported. BONUS.MAP has several, using them for both foreground and background, apparently with special case code.

PEOPLE_S.MAP (a list of credits) has none. CREDITS.MAP (studio banners, etc.) has two, which are used to store entirely separate screens.

=== Unknown section ===

The header is followed by a section of 40 unknown bytes, before the VGA palette which always occurs at offset 0xA8.

=== Tileset ===

The tileset is a raw block of 8x8 bitmaps. The end of this block is marked by <tt>layersOffset</tt>.

=== Foreground and background layers ===

All levels have four foreground layers except level four which has one. These layers are arrays of <tt>INT16LE</tt> indices into the tileset. To obtain a working index, subtract one from the layer values. An index of -1 means an undrawn tile. Bit 15 (i.e. the MSB) indicates horizontal flipping, bit 14 indicates vertical flipping. The purpose of bit 13 is currently unknown.

The first foreground layer defines tiles. The second layer appears to define platforms, the third appears to define impassable lines, and the fourth perhaps powerup and enemy positions.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Lion King Level Format

2015-06-08T01:21:54Z

Ceidwad: clarified header fields

{{Map Infobox
| Type = 2D tile-based
| Layers = 6
| Tile size = 8×8
| Viewport = 320×200
| Game1 = The Lion King
}}
[[The Lion King]] '''MAP Format''' is used to store game levels.

== File format ==

=== Header ===

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT32LE]] || paletteOffset || Offset of 256-colour VGA palette
|-
| [[UINT32LE]] || tilesetOffset || Offset of 8x8 tiles
|-
| [[UINT32LE]] || foregroundWidth ||rowspan=2|Size of foreground layers in tiles
|-
| [[UINT32LE]] || foregroundHeight
|-
| [[UINT32LE]] || layersOffset || Offset of foreground layer data
|-
| [[UINT32LE]] || backgroundWidth ||rowspan=2|Size of background layer in tiles
|-
| [[UINT32LE]] || backgroundHeight
|-
| [[UINT32LE]] || background || Offset of background layer data
|-
| [[BYTE]][96] || padding || Set to 0x00
|}

The header is padded by null bytes up to offset 0x80. It can include up to four extra backgrounds, used only by BONUS.MAP and CREDITS.MAP.

Note the different dimensions of the foreground and background layers. The game uses parallax scrolling for the background layer.

{{TODO|How do the extra backgrounds work? Are they all parallaxed at the same time, or are there map codes to switch background image?}}

=== Unknown section ===

The header is followed by a section of 40 unknown bytes, before the VGA palette which always occurs at offset 0xA8.

=== Tileset ===

The tileset is a raw block of 8x8 bitmaps. The end of this block is marked by <tt>layersOffset</tt>.

=== Foreground and background layers ===

All levels have four foreground layers except level four which has one. These layers are arrays of <tt>INT16LE</tt> indices into the tileset. To obtain a working index, subtract one from the layer values. An index of -1 means an undrawn tile. Bit 15 (i.e. the MSB) indicates horizontal flipping, bit 14 indicates vertical flipping. The purpose of bit 13 is currently unknown.

The first foreground layer defines tiles. The second layer appears to define platforms, the third appears to define impassable lines, and the fourth perhaps powerup and enemy positions.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Lion King Level Format

2015-06-07T22:18:23Z

Ceidwad:

[[The Lion King]] '''MAP Format''' is used to store game levels.

=== Header ===

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT32LE]] || paletteOffset || Offset of 256-colour VGA palette
|-
| [[UINT32LE]] || tilesetOffset || Offset of 8x8 tiles
|-
| [[UINT32LE]] || foregroundWidth ||rowspan=2|Size of foreground layers
|-
| [[UINT32LE]] || foregroundHeight
|-
| [[UINT32LE]] || layersOffset || Offset of foreground layer data
|-
| [[UINT32LE]] || backgroundWidth ||rowspan=2|Size of background layer
|-
| [[UINT32LE]] || backgroundHeight
|-
| [[UINT32LE]] || background || Offset of background layer data
|}

The header is padded by null bytes up to offset 0x80. It can include up to four extra backgrounds, used only by BONUS.MAP and CREDITS.MAP.

Note the different dimensions of the foreground and background layers. The game uses parallax scrolling for the background layer.

=== Unknown section ===

The header is followed by a section of 40 unknown bytes, before the VGA palette which always occurs at offset 0xA8.

=== Tileset ===

The tileset is a raw block of 8x8 bitmaps. The end of this block is marked by <tt>layersOffset</tt>.

=== Foreground and background layers ===

All levels have four foreground layers except level four which has one. These layers are arrays of <tt>INT16LE</tt> indices into the tileset. To obtain a working index, subtract one from the layer values. An index of -1 means an undrawn tile. Bit 15 (i.e. the MSB) indicates horizontal flipping, bit 14 indicates vertical flipping. The purpose of bit 13 is currently unknown.

The first foreground layer defines tiles. The second layer appears to define platforms, the third appears to define impassable lines, and the fourth perhaps powerup and enemy positions.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

[[Category:Map Files]]
[[Category:The Lion King]]

MCH Format

2015-06-07T21:53:09Z

Ceidwad:

The '''MCH Format''' is used to store sprite animations, e.g. the image frames of a creature walking.

== File format ==

=== Header ===

The file starts with an image count.

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE frameCount||Number of frames in the animation
|}

=== Frame entry ===

After the image count are frame details, repeated <tt>frameCount</tt> times.

{|class="wikitable"
!Data type!!Description
|-
|UINT16LE width||Width in pixels
|-
|UINT16LE height||Height in pixels
|-
|UINT32LE offset||Offset from start of file where data begins
|}

Each frame's image data starts at <tt>offset</tt> bytes from the start of the file.

=== Frame image data ===

Frame pixel data is stored in chunks representing horizontal runs of pixels. Each chunk has this format:

{|class="wikitable"
!Data type!!Description
|-
|BYTE x||rowspan=2|Position to start drawing
|-
|BYTE y
|-
|BYTE numPixels||Number of pixels in the chunk
|-
|BYTE[numPixels] pixels||Pixels using current level palette
|}

One row's pixels may be defined by multiple chunks. The data ends when <tt>x == 0xFF</tt>.

== Tools ==

{{BeginFileFormatTools|Type=image}}
{{FileFormatTool
| Name = [[Camoto]]
| canView = No
| canExport = No
| canImport = No
| editMetadata = N/A
}}
{{EndFileFormatTools}}

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]] and [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

[[Category:Graphics Files]]
[[Category:The Lion King]]

Talk:Captain Comic II Tileset Format

2014-12-27T13:09:18Z

Ceidwad:

How are the zero bytes used during compression? I tried inserting a zero byte after each tile but the game loads with completely blank (black) tiles then. It seems the game doesn't need these zero bytes? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 07:39, 27 December 2014 (UTC)

I believe they aren't used in the tileset which the game loads as one contiguous block. Putting in a stop code would then prevent the game from loading the rest of the tiles. The zero byte stop code is used in the sprite files which use the same compression/decompression algorithm. With the sprites, the game knows where to seek in the sprite files to read each sprite, and the stop code prevents it from reading to EOF through several other sprites. (That data is in the EXE, which I'll have a page on soon, as it contains many sprites and the level metadata.) [[User:Ceidwad|Ceidwad]] ([[User talk:Ceidwad|talk]]) 13:09, 27 December 2014 (UTC)

Captain Comic II Dialog Format

2014-12-27T09:35:50Z

Ceidwad: Solved unknown string prefices.

{{Text Infobox
| Type = Story
| Lines = ?
| Charset = ?
| Game1 = Captain Comic II
}}
This format stores the text used in conversation with NPCs in [[Captain Comic II]]. It is found in <tt>FRNNN.3</tt> dialog files, which are only present for some game levels.

== File format ==

Before the file can be parsed, it must be decrypted. This can be done by XORing every byte in the file with 0x25.

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]][...] || offsets || Offsets of each string record.
|-
| [[char]][...][...] || strings || Each string is prefixed with two bytes giving the column and row counts, respectively, in characters, needed to draw the text in a window.
|}

There is no count field in the header. To load the offsets array, add new values until the file position equals the first element.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

File:Captain Comic II Map Format.png

2014-12-21T06:49:39Z

Ceidwad:

File:Captain Comic II Tileset Format.png

2014-12-21T06:42:36Z

Ceidwad:

Visage Format

2014-12-21T06:21:02Z

Ceidwad: Added decompression methods.

{{Image Infobox
| Hardware1 = VGA
| Depth = 8-bit (VGA)
| MinSize = 0×0
| MaxSize = 65535×65535 
| Palette = Internal/External
| NumPlanes = 1
| HasTransparency = Yes
| HasHitmap = No
| Game1 = The Lost Files of Sherlock Holmes: The Case of the Serrated Scalpel
| Game2 = The Lost Files of Sherlock Holmes: The Case of the Rose Tattoo
}}

The '''Visage Format''' is a graphic format that can store multiple images and palettes. It is used in [[The Lost Files of Sherlock Holmes: The Case of the Serrated Scalpel]] and [[The Lost Files of Sherlock Holmes: The Case of the Rose Tattoo]] to store various backgrounds and sprites. Each block of data can be uncompressed or use RLE. Visage files use the *.vgs extension, though some use *.lbv.

== File format ==
Although the format can contain multiple blocks, there is no header to tell how many data blocks exist. You just need to check for End of File to know when you're done reading.

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || Width || Data width.
|-
| [[UINT16LE]] || Height || Data height.
|-
| [[UINT8]] || Unknown || 0 usually, disasssembly shows this can control scaling somehow.
|-
| [[UINT8]] || Compressed || 0 - Uncompressed, 1 - RLE.
|-
| [[BYTE]] || xOffset || Added to drawing position to offset an image. Works as an anchor to allow sprite
frames with varying dimensions to 'line up'.
|-
| [[BYTE]] || yOffset || See X Offset.
|-
| [[BYTE]][Width×height] || Data || Palette or graphic data.
|}

With the header loaded, you know to read width×height bytes of data which can either be palette or graphic data.

=== Palettes ===
Palette data can be identified because it begins with "VGS palette" followed by a standard 256 index, 6-bit color depth [[VGA Palette]]. For some reason the palette data is given a height of 1 (2 rows), so you have to concatenate the data to read the values properly.

=== Graphics ===
Graphic data is implied if the data block isn't a palette. The graphic data is 8-bit VGA data, but, depending on the compression flag, can be either linear VGA data or use a type of RLE as described below.

== RLE Compression ==

The compressed data in both [[The Lost Files of Sherlock Holmes: The Case of the Serrated Scalpel]] and the sequel [[The Lost Files of Sherlock Holmes: The Case of the Rose Tattoo]] uses the following header:

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]] || size || Size of the compressed data.
|-
| [[BYTE]] || repeatMarker || Signals a repeated byte. Only used in the first game.
|}

In the first game, decompress as follows:

# Read a [[BYTE]] as <tt>testByte</tt>.
#* If <tt>testByte</tt> == <tt>repeatMarker</tt>, read a [[BYTE]] as <tt>val</tt>, read a [[UINT8]] as <tt>num</tt>, and copy <tt>num</tt> <tt>val</tt>s to output.
#* Else add <tt>testByte</tt> to output.
# Loop until out of data.

The second game's compression scheme divides each row into alternating chunks of transparent and opaque pixels. The decompression of each row follows this logic:

For each row:
# Read a [[UINT8]] as <tt>skipSize</tt>.
# Add <tt>skipSize</tt> × 0xff to output. 0xff is the transparent colour index.
# Read a [[UINT8]] as <tt>chunkSize</tt>.
# Copy <tt>chunkSize</tt> bytes from input to output.
# Loop until the end of the row is reached.

== Source Code ==
The following FreeBASIC code will load through each block of a Visage file and display the palette or graphic data. It doesn't yet properly decode the RLE compressed graphics.

<source lang="freebasic">
' Visage File Viewer.

' Visage files contain 1 or more blocks of data that can include either palette or graphic data.
' Each block begins with a header of four 16-bit integers: width, height, RLE compression, and unknown.
' Blocks containing palette data begin with "VGA palette", all other blocks are graphic data.
' Palette blocks are typical 8-bit VGA palettes, 256 indexes, each with three 6-bit color values.
' Graphic blocks are raw 8-bit indexed VGA pixel data.

' The file path to the palette file you want to open.
Dim As String VGSFile = "H:\Programs\LIB Extractor\vgs\bigmap.vgs"

' Open the Visage file.
If Open(VGSFile For Binary Access Read As #1) <> 0 Then
Print "File: " + VGSFile + " not found!"
Sleep
End
End If

Dim Y As Integer, X As Integer
Dim Index As UByte, Length As UByte
Dim XSize As UShort, YSize As UShort
Dim RLEFlag As UShort, Unknown As UShort
Dim BlockSize As UInteger
Dim As String PaletteCheck = ""
Dim ColorIndex As UShort, ColorOffset As UShort
Dim Red As UByte, Green As UByte, Blue As UByte
Dim As UByte Block = 0
Dim Offset As UInteger, Delta As UShort, I As UShort, FullLength As UInteger

Screen 13
Do
CLS

' Load the block header.
Get #1, , XSize
Get #1, , YSize
Get #1, , RLEFlag
Get #1, , Unknown

'If XSize = 389 And YSize = 1 Then
' ' Trap for palette which doesn't store the correct size to load.
' XSize = 780
'End If

BlockSize = (XSize + 1) * (YSize + 1)

Print " Block #: " + Str(Block)
Print "X, Y (Size): " + Str(XSize) + ", " + Str(YSize) + " (" + Str(BlockSize) + " bytes)"
Print " Compressed: " + Str(RLEFlag)
Print " Unknown: " + Str(Unknown)

' Create an array for the block data.
ReDim VGSData(0 To Blocksize) As UByte

' Load this block's data into the array.
For Y = 0 To YSize
For X = 0 To XSize
Get #1, , VGSData(Y * XSize + X)
Next X
Next Y

' Check for palette.
PaletteCheck = ""
For X = 0 To 11
PaletteCheck = PaletteCheck + Chr(VGSData(X))
Next X
If PaletteCheck = "VGA palette" + Chr(26) Then
Print " Type: Palette Data"
Sleep
Cls

' Loop through all of the colors.
ColorOffset = 12
ColorIndex = 0
Do
' Read the color attributes from the file.
Red = VGSData(ColorOffset)
Green = VGSData(ColorOffset + 1)
Blue = VGSData(ColorOffset + 2)

Red = Red * 4
Green = Green * 4
Blue = Blue * 4

' Change the palette.
Palette ColorIndex, Red, Green, Blue

Line(ColorIndex, 0)-(ColorIndex, 199), ColorIndex
ColorIndex = ColorIndex + 1
ColorOffset = ColorOffset + 3
Loop Until ColorOffset >= BlockSize
Else
Print " Type: Graphic Data"
Sleep
Cls

' If it's not a palette, it's graphic data.
If RLEFlag = 0 Then
' Uncompressed image.
For Y = 0 To YSize
For X = 0 To XSize
PSet(X, Y), VGSData(Y * XSize + X)
Next X
Next Y
Else
' Compressed image.
Y = 0
X = 0
FullLength = VGSData(1) * 256 + VGSData(0) ' Data Stream Length
' Unknown: Always FE FE.
Offset = 4
' To Do: Decode RLE.
End If
End If

Sleep
Block = Block + 1
Loop While Not EOF(1)

Close #1

</source>

== Credits ==

This file format was reverse engineered by [[User:TheAlmightyGuru|TheAlmightyGuru]]. The RLE compression was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic II Dialog Format

2014-12-21T03:54:34Z

Ceidwad:

The '''Captain Comic 2 Dialog Format''' stores the text used in conversation with NPCs in [[Captain Comic 2 Fractured Reality]]. It is found in <tt>FRNNN.3</tt> dialog files, which are only present for some game levels.

== File format ==

Before the file can be parsed, it must be decrypted. This can be done by XORing every byte in the file with 0x25.

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]][...] || offsets || Offsets of each string record.
|-
| [[char]][...][...] || strings || {{TODO|Each string is prefixed with two unknown bytes.}}
|}

There is no count field in the header. To load the offsets array, add new values until the file position equals the first element.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic II Dialog Format

2014-12-21T03:53:32Z

Ceidwad: Created page with "The '''Captain Comic 2 Dialog Format''' stores the text used in conversation with NPCs. It is found in <tt>FRNNN.3</tt> dialog files, which are only present for some game leve..."

The '''Captain Comic 2 Dialog Format''' stores the text used in conversation with NPCs. It is found in <tt>FRNNN.3</tt> dialog files, which are only present for some game levels.

== File format ==

Before the file can be parsed, it must be decrypted. This can be done by XORing every byte in the file with 0x25.

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]][...] || offsets || Offsets of each string record.
|-
| [[char]][...][...] || strings || {{TODO|Each string is prefixed with two unknown bytes.}}
|}

There is no count field in the header. To load the offsets array, add new values until the file position equals the first element.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic II

2014-12-21T03:40:22Z

Ceidwad:

{{NeedMoreInfo}}

[[Captain Comic 2 Fractured Reality]] is the sequel to [[Captain Comic]], offering a larger gameworld and more flexible engine.

{{BeginGameFileList}}
{{GameFile
| Name = frNNN.0
| Format = [[Captain Comic 2 Tileset Format]]
| KnownFormat = Yes
| Desc = Background tiles
}}
{{GameFile
| Name = frNNN.1
| Format = [[Captain Comic 2 Map Format]]
| KnownFormat = Yes
| Desc = Game levels
}}
{{GameFile
| Name = frNNN.2 frdata.N frdemo.N
| Format = [[Captain Comic 2 Sprite Format]]
| KnownFormat = Partial
| Desc = Enemy sprites
}}
{{GameFile
| Name = frNNN.3
| Format = [[Captain Comic 2 Dialog Format]]
| KnownFormat = Yes
| Desc = Dialog text
}}
{{GameFile
| Name = frpak.NNN
| Format = [[Captain Comic Image Format]]
| KnownFormat = Yes
| Desc = Full-screen EGA images (title screen, story, high scores, etc.)
}}
{{EndGameFileList}}

[[Category:Sidescroller]]

Captain Comic II Sprite Format

2014-12-21T03:34:46Z

Ceidwad: Created page with "{{Tileset Infobox | Hardware1 = EGA | MaxTiles = ''Unlimited'' | Palette = Default EGA | Names = N | TileMinSize = 1×1 | TileMaxSize = 320×200 | NumPlanes =..."

{{Tileset Infobox
| Hardware1 = EGA
| MaxTiles = ''Unlimited''
| Palette = Default EGA
| Names = N
| TileMinSize = 1×1
| TileMaxSize = 320×200
| NumPlanes = 4/5
| PlaneArrangement = [[Raw_EGA_data#Planar_EGA_data|Tile-planar]]
| HasTransparency = Y
| HasHitmap = N
| Metadata = None
| Subtilesets = N
| Compressed = N
| Hidden = N
| Game1 = Captain Comic 2 Fractured Reality
}}
The '''Captain Comic 2 Sprite Format''' stores the images used for drawing animated creatures and objects in <tt>FRNNN.2</tt> level sprite files, <tt>FRDEMO.N</tt> introduction sequence files, and <tt>FRDATA.1</tt>.

== File format ==

The file has no header - the first frame's data starts right at the beginning of the file. Each frame has a header of 4 or 6 bytes.

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]] || width ||rowspan=2| Size of the frame in pixels
|-
| [[UINT16LE]] || height
|-
| [[UINT16LE]] || planeSize || Size in bytes of one plane. This is equal to width × height / 8, but see following note.
|}

The frames are 16-colour images, split into four or five planes (see [[Raw_EGA_data#Planar_EGA_data]]). Each image is stored one after the other, each image having the above header. The planes within each image are ordered with opacity first, if present, then blue, green, red, and intensity.

In reading these files, <tt>planeSize</tt> should always be checked against <tt>width × height / 8</tt> for every image. If it is equal, this signals that an opacity plane is present. If it is not equal, that signals that there is no opacity plane, and the <tt>planeSize</tt> field should be treated as absent: the input stream should be backtracked two bytes (i.e. <tt>sizeof(planeSize)</tt>) before reading the four colour planes.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic II

2014-12-21T02:13:59Z

Ceidwad:

{{NeedMoreInfo}}

[[Captain Comic 2 Fractured Reality]] is the sequel to [[Captain Comic]], offering a larger gameworld and more flexible engine.

{{BeginGameFileList}}
{{GameFile
| Name = frNNN.0
| Format = [[Captain Comic 2 Tileset Format]]
| KnownFormat = Yes
| Desc = Background tiles
}}
{{GameFile
| Name = frNNN.1
| Format = [[Captain Comic 2 Map Format]]
| KnownFormat = Yes
| Desc = Game levels
}}
{{GameFile
| Name = frNNN.2 frdata.1 frdemo.N
| Format = [[Captain Comic 2 Sprite Format]]
| KnownFormat = Partial
| Desc = Enemy sprites
}}
{{GameFile
| Name = frNNN.3
| Format = [[Captain Comic 2 Dialog Format]]
| KnownFormat = Yes
| Desc = Dialog text
}}
{{GameFile
| Name = frpak.NNN
| Format = [[Captain Comic Image Format]]
| KnownFormat = Yes
| Desc = Full-screen EGA images (title screen, story, high scores, etc.)
}}
{{EndGameFileList}}

[[Category:Sidescroller]]

Captain Comic II Map Format

2014-12-21T02:00:39Z

Ceidwad:

{{Map Infobox
| Type = 2D tile-based
| Layers = 1
| Tile size = 16×16
| Viewport = 208×160
| Game1 = Captain Comic 2 Fractured Reality
}}

The '''Captain Comic 2 Map Format''' stores the playable game levels. Each level is stored in a separate file in the game directory, using the <tt>FRNNN.1</tt> filename pattern, where NNN ranges from 000 to 014.

The files only store the map background layer. It is currently unknown how to change the player start position.

== File format ==

The file format differs from [[Captain Comic Map Format]]. In the former game, each 'level' (or game region using a specific tileset) contained three different maps or 'parts' stored in <tt>.PT</tt> files. All those parts were a fixed 128x10 tiles. In the new format, the map file is a container for a variable number of 'parts', each with a variable tile dimension.

=== Header ===

Each file begins with the following header.

{|class="wikitable"
! Data Type || Name || Description
|-
| [[UINT16LE]] || numParts || Number of maps in the file
|-
| MAPDEF[numParts] || mapdefs || see below
|}

<tt>MAPDEF</tt> is defined as follows:

{|class="wikitable"
! Data Type || Name || Description
|-
| [[UINT16LE]] || width || Width in tiles of the map
|-
| [[UINT16LE]] || height || Height in tiles of the map
|-
| [[UINT16LE]] || offset || Offset in this file of the compressed map data
|}

Each map data chunk is compressed with the same algorithm described in [[Captain Comic 2 Tileset Format]]. Once uncompressed, the data has the same format as in [[Captain Comic Map Format]], with one byte for each tile, left-to-right and top-to-bottom. The total size of this section is the map width multiplied by the map height.

=== Map codes ===

Map codes are direct indices into the tileset. So a map code of 0x01 means the second tile in the tileset should be drawn at that location. The tileset to use is matched up by filename (<tt>FR002.0</tt> provides the tiles for the maps in <tt>FR002.1</tt>, for example.)

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic II Map Format

2014-12-21T02:00:05Z

Ceidwad: Created page with "{{Map Infobox | Type = 2D tile-based | Layers = 1 | Tile size = 16×16 | Viewport = 208×160 | Game1 = Captain Comic }} The '''Captain Comic 2 Map Format''' st..."

{{Map Infobox
| Type = 2D tile-based
| Layers = 1
| Tile size = 16×16
| Viewport = 208×160
| Game1 = Captain Comic
}}

The '''Captain Comic 2 Map Format''' stores the playable game levels. Each level is stored in a separate file in the game directory, using the <tt>FRNNN.1</tt> filename pattern, where NNN ranges from 000 to 014.

The files only store the map background layer. It is currently unknown how to change the player start position.

== File format ==

The file format differs from [[Captain Comic Map Format]]. In the former game, each 'level' (or game region using a specific tileset) contained three different maps or 'parts' stored in <tt>.PT</tt> files. All those parts were a fixed 128x10 tiles. In the new format, the map file is a container for a variable number of 'parts', each with a variable tile dimension.

=== Header ===

Each file begins with the following header.

{|class="wikitable"
! Data Type || Name || Description
|-
| [[UINT16LE]] || numParts || Number of maps in the file
|-
| MAPDEF[numParts] || mapdefs || see below
|}

<tt>MAPDEF</tt> is defined as follows:

{|class="wikitable"
! Data Type || Name || Description
|-
| [[UINT16LE]] || width || Width in tiles of the map
|-
| [[UINT16LE]] || height || Height in tiles of the map
|-
| [[UINT16LE]] || offset || Offset in this file of the compressed map data
|}

Each map data chunk is compressed with the same algorithm described in [[Captain Comic 2 Tileset Format]]. Once uncompressed, the data has the same format as in [[Captain Comic Map Format]], with one byte for each tile, left-to-right and top-to-bottom. The total size of this section is the map width multiplied by the map height.

=== Map codes ===

Map codes are direct indices into the tileset. So a map code of 0x01 means the second tile in the tileset should be drawn at that location. The tileset to use is matched up by filename (<tt>FR002.0</tt> provides the tiles for the maps in <tt>FR002.1</tt>, for example.)

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic II Tileset Format

2014-12-21T01:46:14Z

Ceidwad:

{{Tileset Infobox
| Hardware1 = EGA
| MaxTiles = ''Unlimited''
| Palette = Default EGA
| Names = N
| TileMinSize = 16×16
| TileMaxSize = 16×16
| NumPlanes = 4
| PlaneArrangement = [[Raw_EGA_data#Planar_EGA_data|Tile-planar]]
| HasTransparency = N
| HasHitmap = N
| Metadata = None
| Subtilesets = N
| Compressed = Y
| Hidden = N
| Game1 = Captain Comic 2 Fractured Reality
}}

The '''Captain Comic 2 Tileset Format''' stores the images used for drawing the game levels. All tiles are fixed as 16×16 pixels in size. The format is similar to the [[Captain Comic Tileset Format]], but extends the header and adds RLE compression.

== File format ==

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || unknown || {{TODO|Unknown - a tile index}}
|-
| [[UINT16LE]] || lastBlockingTile || index of the last blocking tile
|-
| [[UINT16LE]] || lastWaterTile || index of the last underwater tile in the tileset
|}

Tiles must be in the order blocking, underwater, other. <tt>unknown</tt> is always <= <tt>lastBlockingTile</tt>. If there are no underwater tiles, <tt>lastWaterTile = 0xffff</tt>.

The tile data follows this header, in blocks of 128 bytes per tile. See [[Captain Comic Tileset Format]] for an explanation. However, first the data must be decompressed, as follows.

# Read one byte
#* If the high bit is NOT set (<= 127) then copy this many bytes unchanged
#* If the high bit is set (>= 128) then repeat the next byte. The repeat count is 256 - the first byte
#* If the byte is 0, break
# Repeat until EOF

Note the stop code (0). This means that a partial block can be decompressed instead of waiting for EOF.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic II Tileset Format

2014-12-21T01:35:32Z

Ceidwad:

{{Tileset Infobox
| Hardware1 = EGA
| MaxTiles = ''Unlimited''
| Palette = Default EGA
| Names = N
| TileMinSize = 16×16
| TileMaxSize = 16×16
| NumPlanes = 4
| PlaneArrangement = [[Raw_EGA_data#Planar_EGA_data|Tile-planar]]
| HasTransparency = N
| HasHitmap = N
| Metadata = None
| Subtilesets = N
| Compressed = Y
| Hidden = N
| Game1 = Captain Comic 2 Fractured Reality
}}

The '''Captain Comic 2 Tileset Format''' stores the images used for drawing the game levels. All tiles are fixed as 16×16 pixels in size. The format is similar to the [[Captain Comic Tileset Format]], but extends the header and adds RLE compression..

== File format ==

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || unknown || {{TODO|Unknown - a tile index}}
|-
| [[UINT16LE]] || lastBlockingTile || index of the last blocking tile
|-
| [[UINT16LE]] || lastWaterTile || index of the last underwater tile in the tileset
|}

Tiles must be in the order blocking, underwater, other. <tt>unknown</tt> is always <= <tt>lastBlockingTile</tt>. If there are no underwater tiles, <tt>lastWaterTile = 0xffff</tt>.

The tile data follows this header, in blocks of 128 bytes per tile. See [[Captain Comic Tileset Format]] for an explanation. However, first the data must be decompressed, as follows.

# Read one byte
#* If the high bit is NOT set (<= 127) then copy this many bytes unchanged
#* If the high bit is set (>= 128) then repeat the next byte. The repeat count is 256 - the first byte
#* If the byte is 0, break
# Repeat until EOF

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic II Tileset Format

2014-12-21T01:32:36Z

Ceidwad:

{{Tileset Infobox
| Hardware1 = EGA
| MaxTiles = ''Unlimited''
| Palette = Default EGA
| Names = N
| TileMinSize = 16×16
| TileMaxSize = 16×16
| NumPlanes = 4
| PlaneArrangement = [[Raw_EGA_data#Planar_EGA_data|Tile-planar]]
| HasTransparency = N
| HasHitmap = N
| Metadata = None
| Subtilesets = N
| Compressed = Y
| Hidden = N
| Game1 = Captain Comic 2 Fractured Reality
}}

The '''Captain Comic 2 Tileset Format''' stores the images used for drawing the game levels. All tiles are fixed as 16×16 pixels in size. The format is similar to the [[Captain Comic Tileset Format]], but extends the header and adds RLE compression..

== File format ==

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || unknown || {{TODO|Unknown - a tile index}}
|-
| [[UINT16LE]] || lastBlockingTile || index of the last blocking tile
|-
| [[UINT16LE]] || lastWaterTile || index of the last underwater tile in the tileset
|}

Tiles must be in the order blocking, underwater, other. unknown0 and unknown1 are equal in some tilesets. <tt>unknown</tt> is always <= <tt>lastBlockingTile</tt>. If there are no underwater tiles, <tt>lastWaterTile = 0xffff</tt>.

The tile data follows this header, in blocks of 128 bytes per tile. See [[Captain Comic Tileset Format]] for an explanation. However, first the data must be decompressed, as follows.

# Read one byte
#* If the high bit is NOT set (<= 127) then copy this many bytes unchanged
#* If the high bit is set (>= 128) then repeat the next byte. The repeat count is 256 - the first byte
#* If the byte is 0, break
# Repeat until EOF

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic II Tileset Format

2014-12-21T01:30:06Z

Ceidwad: Created page with "{{Tileset Infobox | Hardware1 = EGA | MaxTiles = ''Unlimited'' | Palette = Default EGA | Names = N | TileMinSize = 16×16 | TileMaxSize = 16×16 | NumPlanes =..."

{{Tileset Infobox
| Hardware1 = EGA
| MaxTiles = ''Unlimited''
| Palette = Default EGA
| Names = N
| TileMinSize = 16×16
| TileMaxSize = 16×16
| NumPlanes = 4
| PlaneArrangement = [[Raw_EGA_data#Planar_EGA_data|Tile-planar]]
| HasTransparency = N
| HasHitmap = N
| Metadata = None
| Subtilesets = N
| Compressed = Y
| Hidden = N
| Game1 = Captain Comic 2 Fractured Reality
}}

The '''Captain Comic 2 Tileset Format''' stores the images used for drawing the game levels. All tiles are fixed as 16×16 pixels in size. The format is similar to the [[Captain Comic Tileset Format]], but extends the header and adds RLE compression..

== File format ==

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || unknown0 || {{TODO|Unknown - a tile index, related to blocking somehow; always <= }}
|-
| [[UINT16LE]] || lastBlockingTile || index of the last blocking tile
|-
| [[UINT16LE]] || lastWaterTile || index of the last underwater tile in the tileset
|}

Tiles must be in the order blocking, underwater, other. unknown0 and unknown1 are equal in some tilesets. If there are no underwater tiles, lastWaterTile = 0xffff.

The tile data follows this header, in blocks of 128 bytes per tile. See [[Captain Comic Tileset Format]] for an explanation. However, first the data must be decompressed, as follows.

# Read one byte
#* If the high bit is NOT set (<= 127) then copy this many bytes unchanged
#* If the high bit is set (>= 128) then repeat the next byte. The repeat count is 256 - the first byte
#* If the byte is 0, break
# Repeat until EOF

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic II

2014-12-21T01:03:20Z

Ceidwad: Created page with "{{NeedMoreInfo}} Captain Comic 2 Fractured Reality is the sequel to Captain Comic, offering a larger gameworld and more flexible engine. {{BeginGameFileList}} {{Game..."

User:Ceidwad

2014-12-21T00:46:49Z

Ceidwad:

Longtime hobbyist reverse engineer.

Games I'm contributing info for:
 Captain Comic
 Captain Comic 2: Fractured Reality
 Lost Files of Sherlock Holmes: Case of the Serrated Scalpel

I have an extensive archive of info for other games that I will be uploading as time allows. Drop me a line if you have a favourite game for which you'd like file format info and I'll see what I can do!

RRM Format (Mythos Software)

2014-12-21T00:43:10Z

Ceidwad: Added object structure definition.

The '''RRM Format (Mythos Software)''' is a container for room-specific data in [[The Lost Files of Sherlock Holmes: The Case of the Serrated Scalpel]].

== File format ==

=== Header ===

The header has this format:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[char]][32] || magicText || "\r\n\nHOLMES RESOURCE FILE V2.1\r\n\n\x1A"
|-
| [[BYTE]][7] || magicBytes || The same in all files: 00 14 9C 0E 74 50 05. Unknown meaning.
|-
| [[BYTE]] || isPacked || 09 = unpacked, 0A = packed.
|-
| [[UINT32LE]] || dirOffset || Offset of the directory, described below.
|}

=== Animations ===

The header is followed by zero or more animation offsets and data:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT32LE]][nAnims] || animOffsets || Offsets to VGS data for animations.
|-
| VGSChunk[nAnims] || anims || Animations in the Visage format.
|}

nAnims is found in the directory that follows. RRM files are not parsed sequentially.

=== Directory ===

The directory gives total numbers or sizes of various resources.

{|class="wikitable"
! Data Type !! Name !! Description
|-
| [[UINT16LE]] || nObjects || Number of logical room objects, defined below.
|-
| [[UINT16LE]] || nSprites || Number of VGS chunks associated with room objects.
|-
| [[UINT16LE]] || nAnims || Number of VGS chunks in the previous section.
|-
| [[UINT16LE]] || textSize || Size of the text block below, containing object descriptions.
|-
| [[UINT16LE]] || sequencesSize || Size of the sequence block below, defining sprite frame orders.
|-
| [[UINT16LE]] || unknown || Always zero.
|}

Sprites are persistent graphics for room objects, typically lasting the duration of play in the room. Animations are typically used for one-off events.

=== Sprite Definitions ===

Next comes a table defining the sprites:

{|class="wikitable"
! Data Type !! Name !! Description
|-
| SPRITEDEF[nObjects] || spriteDefs || See below for SPRITEDEF definition.
|}

Note that there are nObjects SPRITEDEFs not nSprites. There are always at least as many objects as there are sprites, and the table is null-padded.

{|class="wikitable"
! DataType !! Name !! Description
|-
| [[UINT32LE]] || spriteSize || Size of the VGS chunk for this sprite.
|-
| [[UINT8]] || numFrames || Number of frames in the sprite.
|-
| [[char]][9] || spriteName || Internal name of the sprite.
|}

=== Object Data ===

Objects are the game's most complex data structure and will be defined later on this page. For now, they will be viewed simply as 569-byte chunks. They and their remaining associated data follow:

{|class="wikitable"
! DataType || Name || Description
|-
| OBJECTDEF[nObjects] || objects || Logical room objects.
|-
| [[char]][textSize] || objectText || ASCIIZ descriptions used when looking at an object.
|-
| [[BYTE]][sequencesSize] || sequenceBlock || Object sequences, defined later on this page.
|-
| VGSChunk[nSprites] || sprites || VGS chunks for sprites defined in the SPRITEDEFs.
|}

The VGS chunks for sprites can be read sequentially using the size field in the SPRITEDEFs.

=== Animation Structures ===

Next come structures defining the behaviour of animations:

{|class="wikitable"
! DataType || Name || Description
|-
| ANIMDEF[nAnims] || animDefs || See below.
|}

{|class="wikitable"
! DataType || Name || Description
|-
| [[char]][12] || name || Name of the animation structure.
|-
| [[BYTE]][30] || sequence || Sequence defining frame order, etc. Sequences are defined later.
|-
| [[UINT16LE]] || x ||rowspan=2| Topleft coordinate for first animation frame.
|-
| [[UINT16LE]] || y
|-
| [[UINT32LE]] || size || Size of VGS chunk in the block near the top of the file.
|-
| [[UINT16LE]] || state || Related to state field of objects, explained later.
|-
| [[UINT8]] || drawOptions || Related to drawOptions field of objects, explained later.
|-
| HPOS || startPos || Holmes' standing position when the animation begins.
|-
| HPOS || endPos || Holmes' standing position when the animation ends.
|}

HPOS is a type also used elsewhere in this file. It defines a 'stance' for Holmes:

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]] || x ||rowspan=2| Screen coordinate * 100
|-
| [[UINT16LE]] || y
|-
| [[UINT16LE]] || loopNum || Index into Holmes' list of lists of frames, to be added here later. Essentially, the direction he is facing and whether he is walking or standing still.
|}

The game does coordinate calculations internally in multiples of 100, for example the centre of the screen would be 16000x10000. This was presumably done to avoid floating point in diagonal move deltas.

=== Pathing Data ===

Next comes a number of data structures defining how Holmes moves around the room.

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]] || boxBlockSize || Size of the following block of BOXDEFs. Let nBoxes = boxBlockSize / 10.
|-
| BOXDEF[nBoxes] || boxDefs || Boxes as defined below.
|}

BOXDEF is defined as follows:

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]] || x ||rowspan=4| Coordinates defining a walkable area on the screen.
|-
| [[UINT16LE]] || y
|-
| [[UINT16LE]] || w
|-
| [[UINT16LE]] || h
|-
| [[UINT16LE]] || flags || Unknown purpose.
|}

A magic byte 0xFE follows, and then a lookup table and waypoints data chunk:

{|class="wikitable"
| DataType || Name || Description
|-
| [[INT16LE]][nBoxes][nBoxes] || lookup || See below for explanation.
|-
| [[UINT16LE]] || waypointsSize || Size of following waypoints data chunk.
|-
| [[BYTE]][waypointsSize] || waypoints || Waypoints data chunk.
|}

This data is used when Holmes tries to walk from one box to another. The boxes may not be connected and require travel through other boxes. Let <tt>src</tt> be the index of the box he is in, and <tt>dest</tt> be the index of the destination box. lookup[<tt>src</tt>][<tt>dest</tt>] where <tt>src</tt> is a column in the table will yield an index into the waypoints chunk. A waypoints entry looks like this:

{|class="wikitable"
| DataType || Name || Description
|-
| [[UINT8]] || nWaypoints || Number of waypoints that follow.
|-
| WAYPOINT[nWaypoints] || waypoints || List of screen coordinates that Holmes should walk towards on his path from <tt>src</tt> to <tt>dest</tt>. Each coordinate is UINT16LE x, UINT8 y.
|}

Note that all entries on the main diagonal of the lookup matrix are 0, and at offset 0 in the waypoints block is a set of 0 waypoints, because there is no path needed from a box to itself. Additionally, all entries below the main diagonal are -1, indicating a redundant entry. This is because paths are reversible and the upper half contains all data needed.

Next come the exit boxes:

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT8]] || nExitDefs || Number of following EXITDEFs.
|-
| EXITDEF[nExitDefs] || exitDefs || Exits as defined below.
|}

EXITDEF is defined as follows:

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]] || x ||rowspan=4| Coordinates defining a walkable area on the screen.
|-
| [[UINT16LE]] || y
|-
| [[UINT16LE]] || w
|-
| [[UINT16LE]] || h
|-
| [[UINT16LE]] || roomNum || Destination room number.
|-
| [[UINT16LE]] || unknown || Always 1.
|-
| [[UINT16LE]] || destX ||rowspan=2| Holmes' position on entering the new room.
|-
| [[UINT16LE]] || destY
|-
| [[UINT16LE]] || destLoop || Holmes' animation loop on entering the new room.
|-
|}

Walking on an EXITDEF area causes Holmes to leave the room.

Concluding the pathing data, Holmes' starting position in the room:

{|class="wikitable"
| DataType || Name || Description
|-
| HPOS || startPos || Holmes' starting position on entering the current room.
|}

=== Sounds ===

A list of sound effects follows.

{|class="wikitable"
| DataType || Name || Description
|-
| [[UINT8]] || nSoundDefs || Number of sound effect names that follow.
|-
| [[char]][nSoundDefs][9] || soundDefs || 8-byte sound effect name, padded with nulls, followed by byte 09. The sound effect is found in the LIB archive SND.SND
|}

Room object sequences, defined later on this page, can cause a sound effect to be played by index into this list.

=== Palette and Background ===

The remainder of the <tt>.RRM</tt> consists of a 768-byte [[VGA Palette]] and a 320x138 background image.

The palette is required to construct the animations and sprites earlier in the file. The programmer may choose between parsing through the file and constructing the animations and sprites later, or seeking to the end of the file immediately, since the palette is always at the fixed offset of EOF - (320 * 138 + 768).

== Object Structure ==

Objects are logical entities in a room that affect gameplay. They may have an associated sprite, or they may have not and function as an invisible trigger area. Still other objects may have no spatial meaning and represent state transitions.

Objects always occupy 569 bytes. Many fields only have meaning at runtime.

FARPTR in the DataType column refers to a 32-bit memory location composed of UINT16LE offset, UINT16LE segment. These runtime fields are included for completeness.

{|class="wikitable"
| Offset || DataType || Name || Description
|-
| 0 || [[char]][12] || name || Internal ASCIIZ object name.
|-
| 12 || [[char]][41] || hoverText || ASCIIZ text shown on the status line when the player hovers over the object.
|-
| 53 || FARPTR || textPtr || runtime: pointer to ASCIIZ text description.
|-
| 57 || FARPTR || seqPtr || Initially, the first UINT16LE in this field holds the offset of this object's sequence data in the room sequenceBlock. runtime: afterwards, the field is used as a FARPTR to the sequence.
|-
| 61 || FARPTR || spritePtr || runtime: pointer to VGS sprite for the object.
|-
| 65 || FARPTR || framePtr || runtime: pointer to current sprite frame.
|-
| 69 || [[BYTE]] || unknown || always 0
|-
| 70 || [[BYTE]] || unknown || always 0
|-
| 71 || [[UINT16LE]] || seqIndex || runtime: current position in the object's sequence.
|-
| 73 || [[UINT16LE]] || unknown || always 0
|-
| 75 || [[UINT16LE]] || x ||rowspan=2|Topleft screen coordinate of the object.
|-
| 77 || [[UINT16LE]] || y
|-
| 79 || [[INT16LE]] || deltaX ||rowspan=2|runtime: position delta for moving object.
|-
| 81 || [[INT16LE]] || deltaY
|-
| 83 || [[UINT16LE]] || state || These values occur in the <tt>.RRM</tt>: 4: active, with sprite 6: active, without sprite 7: inactive
|-
| 85 || [[UINT16LE]] || frameX ||rowspan=4| runtime: dimensions of the current sprite frame.
|-
| 87 || [[UINT16LE]] || frameY
|-
| 89 || [[UINT16LE]] || frameWidth
|-
| 91 || [[UINT16LE]] || frameHeight
|-
| 93 || [[BYTE]][4] || unknown || always 0
|-
| 97 || [[UINT8]] || intBehave || encodes various things that happen when the user interacts with the object.
|-
| 98 || [[UINT8]] || defBehave || default interaction, as an index into the menu commands (1=Look, 2=Talk, 3=Move, etc.)
|-
| 99 || [[INT16LE]][3] || flags || story progress flags, to be described elsewhere.
|-
| 105 || [[UINT16LE]] || hoverX ||rowspan=2| Area occupied by an object with no sprite. 0,0 for objects with sprites.
|-
| 107 || [[UINT16LE]] || hoverY
|-
| 109 || [[UINT16LE]] || unknown || always 0
|-
| 111 || [[UINT8]] || spriteNum || If 0, the object has no sprite. If > 0, subtract 1 and use as index into room sprite list.
|-
| 112 || [[UINT16LE]] || spriteFrames || Number of frames in the object's sprite.
|-
| 114 || [[BYTE]] || drawOptions || Bitfield controlling drawing of the object's sprite. The following bits are known so far: 0 and 2: OR these bits together and interpret as a number from 0..3 representing drawing layer, with 0 as backmost and 3 as frontmost. 1: if 1, the sprite is mirrored.
|-
| 115 || ACTIONDEF || openAction || Behaviour when opening the object. See below for ACTIONDEF.
|-
| 165 || [[BYTE]] || onCollision || Unknown value encoding what to do when Holmes collides with the object.
|-
| 166 || [[BYTE]] || unknown || unknown purpose
|-
| 167 || [[BYTE]] || seqRepCounter || runtime: counts how many times the object's sequence's current loop has repeated.
|-
| 168 || [[UINT16LE]] || approachX ||rowspan=3| Holmes walks to this position when approaching an object to interact with it.
|-
| 170 || [[UINT8]] || approachY
|-
| 171 || [[UINT8]] || approachLoop
|-
| 172 || [[BYTE]] || unknown || unknown purpose
|-
| 173 || ACTIONDEF || closeAction || Behaviour when closing the object. See below for ACTIONDEF.
|-
| 223 || [[UINT8]] || seqPrevIndex || runtime: previous sequence loop position, saved by sequence call command.
|-
| 224 || [[UINT8]] || seqFinalFrame || runtime: final frame of sequence shorthand iterator, to be defined later in sequence section.
|-
| 225 || [[UINT16LE]] || textOffset || Offset of object's ASCIIZ description text in room textBlock, used when Holmes uses Look interaction on the object.
|-
| 227 || [[UINT8]] || seqLoopCounter || runtime: number of times a called sequence loop has repeated.
|-
| 228 || [[UINT16LE]] || seqSize || Size of object's sequence data in the room sequenceBlock.
|-
| 230 || [[BYTE]] || unknown || always 0
|-
| 231 || ACTIONDEF || moveAction || Behaviour when moving the object. See below for ACTIONDEF.
|-
| 281 || [[BYTE]][8] || unknown || always 0
|-
| 289 || ACTIONDEF2[4] || extraActions || See below for ACTIONDEF2.
|}

<tt>ACTIONDEF</tt> handles open, close, move actions. It is defined as follows:

{|class="wikitable"
| DataType || Name || Description
|-
| [[BYTE]] || animNum || Animation number to play when interacting. 99 means a TLK script is to be loaded.
|-
| [[BYTE]] || unknown || unknown purpose
|-
| [[char]][4][12] || names || Names of other room objects to toggle or TLK scripts to load.
|}

<tt>ACTIONDEF2</tt> handles other actions like pickup. It is defined as follows:

{|class="wikitable"
| DataType || Name || Description
|-
| [[BYTE]] || animNum || Animation number to play when interacting. 99 means a TLK script is to be loaded.
|-
| [[BYTE]] || unknown || unknown purpose
|-
| [[char]][4][12] || names || Names of other room objects to toggle or TLK scripts to load.
|-
| [[INT16LE]] || flag || story progress flag, either a prerequisite for or result of the action.
|-
| [[BYTE]][6] || unknown || always 0
|-
| [[char]][12] || lastName || Always contains either a TLK script name, or special tags like *SELF*, *PICKUP*.
|}

== Sequence Structure ==

Coming soon.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

RRM Format (Mythos Software)

2014-12-19T11:31:29Z

Ceidwad:

RRM Format (Mythos Software)

2014-12-19T11:09:51Z

Ceidwad: Created.

The '''RRM Format (Mythos Software)''' is a container for room-specific data in The Lost Files of Sherlock Holmes: The Case of the Serrated Scalpel.

== File format ==

=== Header ===

The header has this format:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[char]][32] || magicText || "\r\n\nHOLMES RESOURCE FILE V2.1\r\n\n\x1A"
|-
| [[BYTE]][7] || magicBytes || The same in all files: 00 14 9C 0E 74 50 05. Unknown meaning.
|-
| [[BYTE]] || isPacked || 09 = unpacked, 0A = packed.
|-
| [[UINT32LE]] || dirOffset || Offset of the directory, described below.
|}

=== Animations ===

The header is followed by zero or more animation offsets and data:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT32LE]][nAnims] || animOffsets || Offsets to VGS data for animations.
|-
| VGSChunk[nAnims] || anims || Animations in the Visage format.
|}

nAnims is found in the directory that follows. RRM files are not parsed sequentially.

=== Directory ===

The directory gives total numbers or sizes of various resources.

{|class="wikitable"
! Data Type !! Name !! Description
|-
| [[UINT16LE]] || nObjects || Number of logical room objects, defined below.
|-
| [[UINT16LE]] || nSprites || Number of VGS chunks associated with room objects.
|-
| [[UINT16LE]] || nAnims || Number of VGS chunks in the previous section.
|-
| [[UINT16LE]] || textSize || Size of the text block below, containing object descriptions.
|-
| [[UINT16LE]] || sequencesSize || Size of the sequence block below, defining sprite frame orders.
|-
| [[UINT16LE]] || unknown || Always zero.
|}

Sprites are persistent graphics for room objects, typically lasting the duration of play in the room. Animations are typically used for one-off events.

=== Sprite Definitions ===

Next comes a table defining the sprites:

{|class="wikitable"
! Data Type !! Name !! Description
|-
| SPRITEDEF[nObjects] || spriteDefs || See below for SPRITEDEF definition.
|}

Note that there are nObjects SPRITEDEFs not nSprites. There are always at least as many objects as there are sprites, and the table is null-padded.

{|class="wikitable"
! DataType !! Name !! Description
|-
| [[UINT32LE]] || spriteSize || Size of the VGS chunk for this sprite.
|-
| [[UINT8]] || numFrames || Number of frames in the sprite.
|-
| [[char]][9] || spriteName || Internal name of the sprite.
|}

=== Object Data ===

Objects are the game's most complex data structure and will be defined later on this page. For now, they will be viewed simply as 569-byte chunks. They and their remaining associated data follow:

{|class="wikitable"
! DataType || Name || Description
|-
| OBJECTDEF[nObjects] || objects || Logical room objects.
|-
| [[char]][textSize] || objectText || ASCIIZ descriptions used when looking at an object.
|-
| [[BYTE]][sequencesSize] || sequenceBlock || Object sequences, defined later on this page.
|-
| VGSChunk[nSprites] || sprites || VGS chunks for sprites defined in the SPRITEDEFs.
|}

The VGS chunks for sprites can be read sequentially using the size field in the SPRITEDEFs.

=== Animation Structures ===

Next come structures defining the behaviour of animations:

{|class="wikitable"
! DataType || Name || Description
|-
| ANIMDEF[nAnims] || animDefs || See below.
|}

{|class="wikitable"
! DataType || Name || Description
|-
| [[char]][12] || name || Name of the animation structure.
|-
| [[BYTE]][30] || sequence || Sequence defining frame order, etc. Sequences are defined later.
|-
| [[UINT16LE]] || x ||rowspan=2| Topleft coordinate for first animation frame.
|-
| [[UINT16LE]] || y
|-
| [[UINT32LE]] || size || Size of VGS chunk in the block near the top of the file.
|-
| [[UINT16LE]] || state || Related to state field of objects, explained later.
|-
| [[UINT8]] || drawOptions || Related to drawOptions field of objects, explained later.
|-
| HPOS || startPos || Holmes' standing position when the animation begins.
|-
| HPOS || endPos || Holmes' standing position when the animation ends.
|}

HPOS is a type also used elsewhere in this file. It defines a 'stance' for Holmes:

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]] || x ||rowspan=2| Screen coordinate * 100
|-
| [[UINT16LE]] || y
|-
| [[UINT16LE]] || loopNum || Index into Holmes' list of lists of frames, to be added here later. Essentially, the direction he is facing and whether he is walking or standing still.
|}

The game does coordinate calculations internally in multiples of 100, for example the centre of the screen would be 16000x10000. This was presumably done to avoid floating point in diagonal move deltas.

=== Pathing Data ===

Next comes a number of data structures defining how Holmes moves around the room.

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]] || boxBlockSize || Size of the following block of BOXDEFs. Let nBoxes = boxBlockSize / 10.
|-
| BOXDEF[nBoxes] || boxDefs || Boxes as defined below.
|}

BOXDEF is defined as follows:

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]] || x ||rowspan=4| Coordinates defining a walkable area on the screen.
|-
| [[UINT16LE]] || y
|-
| [[UINT16LE]] || w
|-
| [[UINT16LE]] || h
|-
| [[UINT16LE]] || flags || Unknown purpose.
|}

A magic byte 0xFE follows, and then a lookup table and waypoints data chunk:

{|class="wikitable"
| DataType || Name || Description
|-
| [[INT16LE]][nBoxes][nBoxes] || lookup || See below for explanation.
|-
| [[UINT16LE]] || waypointsSize || Size of following waypoints data chunk.
|-
| [[BYTE]][waypointsSize] || waypoints || Waypoints data chunk.
|}

This data is used when Holmes tries to walk from one box to another. The boxes may not be connected and require travel through other boxes. Let <tt>src</tt> be the index of the box he is in, and <tt>dest</tt> be the index of the destination box. lookup[<tt>src</tt>][<tt>dest</tt>] where <tt>src</tt> is a column in the table will yield an index into the waypoints chunk. A waypoints entry looks like this:

{|class="wikitable"
| DataType || Name || Description
|-
| [[UINT8]] || nWaypoints || Number of waypoints that follow.
|-
| WAYPOINT[nWaypoints] || waypoints || List of screen coordinates that Holmes should walk towards on his path from <tt>src</tt> to <tt>dest</tt>. Each coordinate is UINT16LE x, UINT8 y.
|}

Note that all entries on the main diagonal of the lookup matrix are 0, and at offset 0 in the waypoints block is a set of 0 waypoints, because there is no path needed from a box to itself. Additionally, all entries below the main diagonal are -1, indicating a redundant entry. This is because paths are reversible and the upper half contains all data needed.

Next come the exit boxes:

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT8]] || nExitDefs || Number of following EXITDEFs.
|-
| EXITDEF[nExitDefs] || exitDefs || Exits as defined below.
|}

EXITDEF is defined as follows:

{|class="wikitable"
! DataType || Name || Description
|-
| [[UINT16LE]] || x ||rowspan=4| Coordinates defining a walkable area on the screen.
|-
| [[UINT16LE]] || y
|-
| [[UINT16LE]] || w
|-
| [[UINT16LE]] || h
|-
| [[UINT16LE]] || roomNum || Destination room number.
|-
| [[UINT16LE]] || unknown || Always 1.
|-
| [[UINT16LE]] || destX ||rowspan=2| Holmes' position on entering the new room.
|-
| [[UINT16LE]] || destY
|-
| [[UINT16LE]] || destLoop || Holmes' animation loop on entering the new room.
|-
|}

Walking on an EXITDEF area causes Holmes to leave the room.

Concluding the pathing data, Holmes' starting position in the room:

{|class="wikitable"
| DataType || Name || Description
|-
| HPOS || startPos || Holmes' starting position on entering the current room.
|}

=== Sounds ===

A list of sound effects follows.

{|class="wikitable"
| DataType || Name || Description
|-
| [[UINT8]] || nSoundDefs || Number of sound effect names that follow.
|-
| [[char]][nSoundDefs][9] || soundDefs || 8-byte sound effect name, padded with nulls, followed by byte 09. The sound effect is found in the LIB archive SND.SND
|}

Room object sequences, defined later on this page, can cause a sound effect to be played by index into this list.

=== Palette and Background ===

The remainder of the <tt>.RRM</tt> consists of a 768-byte VGA palette and a 320x138 background image.

The palette is required to construct the animations and sprites earlier in the file. The programmer may choose between parsing through the file and constructing the animations and sprites later, or seeking to the end of the file immediately, since the palette is always at the fixed offset of EOF - (320 * 138 + 768).

== Object and Sequence Definitions ==

Coming soon.

== Credits ==

This file format was reverse engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Talk:Visage Format

2014-12-19T09:19:56Z

Ceidwad: Created page with "BASIC isn't my cup of tea so I'll leave it to you to add this, but here's how the RLE works. After the 8-byte header, there are 3 compression header bytes: UINT16LE chunk_size..."

BASIC isn't my cup of tea so I'll leave it to you to add this, but here's how the RLE works. After the 8-byte header, there are 3 compression header bytes: UINT16LE chunk_size, BYTE repeat_marker. Now loop until out of data: read a BYTE as val; if it's the repeat_marker, read another BYTE as val2, read another BYTE as num, and add num val2s to output. If val wasn't the repeat marker, add it to output. Loop. Finally, output size should match width * height from the header. [[User:Ceidwad|Ceidwad]] ([[User talk:Ceidwad|talk]]) 09:19, 19 December 2014 (UTC)

The Lost Files of Sherlock Holmes: The Case of the Serrated Scalpel

2014-12-19T08:51:19Z

Ceidwad: Added link to RRM format page.

{{NeedMoreInfo}}
{{Game Infobox
| Title = The Lost Files of Sherlock Holmes- The Case of the Serrated Scalpel.png 
| Levels = No
| Tiles = No
| Sprites = No
| Fullscreen = No
| Sound = No
| Music = No
| Text = No
| Story = No
| Interface = No
}}

== Tools ==

{{BeginFileFormatTools|Type=game}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| grp = Edit
| map = No
| gfx = No
| mus = No
| sfx = No
| txt = No
| sav = No
| exe = No
}}
{{EndFileFormatTools}}

{{BeginGameFileList}}
{{GameFile
| Name = *.lib *.snd
| Format = [[LIB Format (Mythos Software)]]
| KnownFormat = Yes
| Desc = Archive files containing game data
}}
{{GameFile
| Name = *.mus
| Format = [[MUS Format (Mythos Software)]]
| KnownFormat = No
| Desc = Music. Appears to be standard MIDI data with a custom header.
}}
{{GameFile
| Name = *.rrm
| Format = [[RRM Format (Mythos Software)]]
| KnownFormat = Yes
| Desc = Room container: background, sprites, objects, pathing, etc.
}}
{{GameFile
| Name = *.vgs *.lbv
| Format = [[Visage Format]]
| KnownFormat = Yes
| Desc = Palette, backgrounds, and sprites.
}}
{{EndGameFileList}}

[[Category:Point and Click]]

User:Ceidwad

2014-12-19T08:39:23Z

Ceidwad:

Longtime hobbyist reverse engineer.

Games I'm contributing info for:
 Captain Comic
 Lost Files of Sherlock Holmes: Case of the Serrated Scalpel

I have an extensive archive of info for other games that I will be uploading as time allows. Drop me a line if you have a favourite game for which you'd like file format info and I'll see what I can do!

Visage Format

2014-12-19T08:37:30Z

Ceidwad: Minor corrections to header description.

{{Image Infobox
| Hardware1 = VGA
| Depth = 8-bit (VGA)
| MinSize = 0×0
| MaxSize = 65535×65535 
| Palette = Internal/External
| NumPlanes = 1
| HasTransparency = Yes
| HasHitmap = No
| Game1 = The Lost Files of Sherlock Holmes: The Case of the Serrated Scalpel
}}

The '''Visage Format''' is a graphic format that can store multiple images and palettes. It is used in [[The Lost Files of Sherlock Holmes: The Case of the Serrated Scalpel]] to store various backgrounds and sprites. Each block of data can be uncompressed or use RLE. Visage files use the *.vgs extension, though some use *.lbv.

== File format ==
Although the format can contain multiple blocks, there is no header to tell how many data blocks exist. You just need to check for End of File to know when you're done reading.

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT16LE]] || Width || Data width.
|-
| [[UINT16LE]] || Height || Data height.
|-
| [[UINT8]] || Unknown || 0 usually, disasssembly shows this can control scaling somehow.
|-
| [[UINT8]] || Compressed || 0 - Uncompressed, 1 - RLE.
|-
| [[BYTE]] || xOffset || Added to drawing position to offset an image. Works as an anchor to allow sprite
frames with varying dimensions to 'line up'.
|-
| [[BYTE]] || yOffset || See X Offset.
|-
| [[BYTE]][Width×height] || Data || Palette or graphic data.
|}

With the header loaded, you know to read width×height bytes of data which can either be palette or graphic data.

=== Palettes ===
Palette data can be identified because it begins with "VGS palette" followed by a standard 256 index, 6-bit color depth [[VGA Palette]]. For some reason the palette data is given a height of 1 (2 rows), so you have to concatenate the data to read the values properly.

=== Graphics ===
Graphic data is implied if the data block isn't a palette. The graphic data is 8-bit VGA data, but, depending on the compression flag, can be either linear VGA data or use a type of RLE that has yet to be determined.

== Source Code ==
The following FreeBASIC code will load through each block of a Visage file and display the palette or graphic data. It doesn't yet properly decode the RLE compressed graphics.

<source lang="freebasic">
' Visage File Viewer.

' Visage files contain 1 or more blocks of data that can include either palette or graphic data.
' Each block begins with a header of four 16-bit integers: width, height, RLE compression, and unknown.
' Blocks containing palette data begin with "VGA palette", all other blocks are graphic data.
' Palette blocks are typical 8-bit VGA palettes, 256 indexes, each with three 6-bit color values.
' Graphic blocks are raw 8-bit indexed VGA pixel data.

' The file path to the palette file you want to open.
Dim As String VGSFile = "H:\Programs\LIB Extractor\vgs\bigmap.vgs"

' Open the Visage file.
If Open(VGSFile For Binary Access Read As #1) <> 0 Then
Print "File: " + VGSFile + " not found!"
Sleep
End
End If

Dim Y As Integer, X As Integer
Dim Index As UByte, Length As UByte
Dim XSize As UShort, YSize As UShort
Dim RLEFlag As UShort, Unknown As UShort
Dim BlockSize As UInteger
Dim As String PaletteCheck = ""
Dim ColorIndex As UShort, ColorOffset As UShort
Dim Red As UByte, Green As UByte, Blue As UByte
Dim As UByte Block = 0
Dim Offset As UInteger, Delta As UShort, I As UShort, FullLength As UInteger

Screen 13
Do
CLS

' Load the block header.
Get #1, , XSize
Get #1, , YSize
Get #1, , RLEFlag
Get #1, , Unknown

'If XSize = 389 And YSize = 1 Then
' ' Trap for palette which doesn't store the correct size to load.
' XSize = 780
'End If

BlockSize = (XSize + 1) * (YSize + 1)

Print " Block #: " + Str(Block)
Print "X, Y (Size): " + Str(XSize) + ", " + Str(YSize) + " (" + Str(BlockSize) + " bytes)"
Print " Compressed: " + Str(RLEFlag)
Print " Unknown: " + Str(Unknown)

' Create an array for the block data.
ReDim VGSData(0 To Blocksize) As UByte

' Load this block's data into the array.
For Y = 0 To YSize
For X = 0 To XSize
Get #1, , VGSData(Y * XSize + X)
Next X
Next Y

' Check for palette.
PaletteCheck = ""
For X = 0 To 11
PaletteCheck = PaletteCheck + Chr(VGSData(X))
Next X
If PaletteCheck = "VGA palette" + Chr(26) Then
Print " Type: Palette Data"
Sleep
Cls

' Loop through all of the colors.
ColorOffset = 12
ColorIndex = 0
Do
' Read the color attributes from the file.
Red = VGSData(ColorOffset)
Green = VGSData(ColorOffset + 1)
Blue = VGSData(ColorOffset + 2)

Red = Red * 4
Green = Green * 4
Blue = Blue * 4

' Change the palette.
Palette ColorIndex, Red, Green, Blue

Line(ColorIndex, 0)-(ColorIndex, 199), ColorIndex
ColorIndex = ColorIndex + 1
ColorOffset = ColorOffset + 3
Loop Until ColorOffset >= BlockSize
Else
Print " Type: Graphic Data"
Sleep
Cls

' If it's not a palette, it's graphic data.
If RLEFlag = 0 Then
' Uncompressed image.
For Y = 0 To YSize
For X = 0 To XSize
PSet(X, Y), VGSData(Y * XSize + X)
Next X
Next Y
Else
' Compressed image.
Y = 0
X = 0
FullLength = VGSData(1) * 256 + VGSData(0) ' Data Stream Length
' Unknown: Always FE FE.
Offset = 4
' To Do: Decode RLE.
End If
End If

Sleep
Block = Block + 1
Loop While Not EOF(1)

Close #1

</source>

== Credits ==

This file format was reverse engineered by [[User:TheAlmightyGuru|TheAlmightyGuru]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic Map Format

2014-12-19T08:22:58Z

Ceidwad: Several corrections to EXE description. Added player start position info.

{{Map Infobox
| Type = 2D tile-based
| Layers = 1
| Tile size = 16×16
| Viewport = 192×160
| Game1 = Captain Comic
}}

The '''Captain Comic Map Format''' stores the playable game levels. Each level is stored in a separate file in the game directory, using the <tt>.PT</tt> filename extension.

The files only store the map background layer. The player start position can be changed by editing the executable file.

== File format ==

The file consists of a width, height and then a list of tiles.

=== Signature ===

There is no signature, however careful processing of the header can be used to check whether the width and height correctly describe the file size. This could be confused with an image file however, so some other checks will be required (such as the absence of certain unused byte values, perhaps.)

=== Header ===

Each file begins with the following header.

{|class="wikitable"
!Data type!!Description
|-
| [[UINT16LE]] width || Width of map, in number of tiles
|-
| [[UINT16LE]] height || Height of map, in number of tiles
|}

The map data follows immediately, with one byte for each tile, left-to-right and top-to-bottom. The total size of this section is the map width multiplied by the map height.

All maps are 128x10 tiles. Although the header uses UINT16LEs to store width and height, internally the game engine uses UINT8s, and the maximum width and height are hardcoded, so maps of different dimensions will not work properly.

=== Map codes ===

Map codes are direct indices into the tileset. So a map code of 0x01 means the second tile in the tileset should be drawn at that location. The tileset to use is matched up by filename (<tt>FOREST.TT2</tt> provides the tiles for <tt>FOREST[0-2].PT</tt>, for example.)

== Executable file ==

There is additional map data hard-coded in the game's main .exe file. The .exe file is lightly compressed with [[Microsoft_ EXEPACK]]. Working with an unpacked .exe is necessary for full control over the map data. The size of unpacked .exe assumed here is 82672.

At offset 63456 (0xF7E0) is a block of 1664 bytes containing the remaining level-related data. There are 8 blocks of 208 bytes, one for each level, 'level' meaning the complete regions - forest, lake, etc., and 'PT' for the three separate parts comprising the level.

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[char]][14] || tilesetFilename || <tt>.tt2</tt> filename
|-
| [[char]][14] || pt1Filename || First <tt>.pt</tt> filename
|-
| [[char]][14] || pt2Filename || Second <tt>.pt</tt> filename
|-
| [[char]][14] || pt3Filename || Third <tt>.pt</tt> filename
|-
| [[UINT8]][4] || doorTiles || Tileset indices of the four tiles used for drawing doors: top left, top right,
bottom left, bottom right. These are used to animate the doors.
|}

All filenames are 13 bytes long, padded with spaces, followed by a null terminator byte.

After this are four entries for the SHP files associated with the level. Each entry is of this form:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT8]] || frameCount || Number of frames in the SHP file's animation
|-
| [[UINT8]] || spriteCount || Number of sprites (e.g. facing left, facing right, etc.)
|-
| [[UINT8]] || unknown || {{TODO|Unknown; always 0 or 1}}
|-
| [[char]][14] || shapeFilename || SHP filename, null-terminated
|}

Note that multiplying number of frames by number of sprites by 160 (the number of bytes per frame), you do indeed get the total size of the shape file.

Finally there are three blocks of 25 bytes, one corresponding to each PT:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT8]] || itemType || Item type. 0=corkscrew, 1=key, 2=boots, 3=lantern, 4=teleport wand, 5=gems, 6=crown, 7=gold, 8=cola, 14=shield
|-
| [[UINT8]] || itemY || Item coordinate (max 18)
|-
| [[UINT8]] || itemX || Item coordinate (max 255; the PT is 128 tiles wide, but the player can stand halfway between tiles)
|-
| [[UINT8]] || exitL ||rowspan=2| Exit behaviour. <tt>exitL</tt> controls what happens on walking off the left side of the PT, <tt>exitR</tt> controls the right. The values can be 0, 1, 2, giving the PT to load, or 255, meaning no PT change occurs.
|-
| [[UINT8]] || exitR
|-
| DOOR[3] || door || Door data for up to three doors in the level (see below)
|-
| ENEMY[4] || enemy || Enemy data for up to four enemies (see below)
|}

This means there can be only one item or powerup per PT. The <tt>itemType</tt> is an index into the bitmaps found earlier in the EXE. (Not offsets; they just follow the same sequence.) (Slots between cola and shield (9-13) are for the five stages of the cola powerup display.)

<tt>DOOR</tt> is described as:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT8]] || doorY || Y-coordinate of the door
|-
| [[UINT8]] || doorX || X-coordinate of the door
|-
| [[UINT8]] || targetLevel || Target level (0-7, as an index into the overall dataset described on this page)
|-
| [[UINT8]] || targetPT || The target PT (0-2)
|}

Empty/unused door slots are FF FF 00 00.

<tt>ENEMY</tt> is described as:

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT8]] || shape || Enemy's sprite, as an index into the level's SHP data (see above)
|-
| [[UINT8]] || behaviour || Enemy behaviour. behaviour & 0x7f has these effects: 1=enemy bounces around the walls 2=the enemy approaches then bounces side to side 3=the enemy chases along the ground 4=the enemy dives to head height then chases 5=the enemy sporadically dives to head height 127=no enemy spawns in this slot (this restricts the maximum simultaneous enemies) If the high bit (=128) is set, the enemy moves at high speed.
|}

After a padding of five null bytes, data for the next level begins.

To control the player's position when the game loads, two separate edits of the unpacked .exe are needed: two bytes at 0x265E give the starting level (0..7) and starting PT (0..2), with default values 01 00. The player's starting coordinates are given by two bytes at 0x96C3: y (0..17), x (0..255), default values 0C 0E.

== Tools ==

{{BeginFileFormatTools|Type=map}}
{{FileFormatTool
| Name = [[Camoto]]
| Platform = Linux/Windows
| canView = Yes
| canCreate = Yes
| canModify = Yes
| editHidden = N/A
| editMetadata = N/A
}}
{{EndFileFormatTools}}

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]]. The .exe file data was reverse-engineered by [[User:Ceidwad|Ceidwad]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)

Captain Comic Tileset Format

2014-12-19T07:40:51Z

Ceidwad: clarified purpose of first header byte

{{Tileset Infobox
| Hardware1 = EGA
| MaxTiles = ''Unlimited''
| Palette = Default EGA
| Names = N
| TileMinSize = 16×16
| TileMaxSize = 16×16
| NumPlanes = 4
| PlaneArrangement = [[Raw_EGA_data#Planar_EGA_data|Tile-planar]]
| HasTransparency = N
| HasHitmap = N
| Metadata = None
| Subtilesets = N
| Compressed = N
| Hidden = N
| Game1 = Captain Comic
}}

The '''Captain Comic Tileset Format''' stores the images used for drawing the game levels. All tiles are fixed as 16×16 pixels in size. The format is very similar to the [[Captain Comic Sprite Format]].

== File format ==

{|class="wikitable"
! Data type !! Name !! Description
|-
| [[UINT8]] || lastPassable || index of last non-blocking tile, tiles of a higher index block the player (walls, ledges, etc.)
|-
| [[UINT8]] || unknown1 || {{TODO|Unknown - always 0x00}}
|-
| [[UINT8]] || unknown2 || {{TODO|Unknown - always 0x00}}
|-
| [[UINT8]] || flags || 0=default, 4=unknown, only used in CASTLE.TT2
|}

The tile data follows this header, in blocks of 128 bytes per tile.

The tiles are 16-colour images, split into four planes (see [[Raw_EGA_data#Planar_EGA_data]]). Each image is stored one after the other (no header.) The planes within each image are ordered with blue first, followed by green, red and intensity last. 32 bytes per plane multipled by four planes gives 128 bytes per tile.

As each image is entirely contained within the 128 bytes, the offset of a given tile can be calculated as

''offset'' = 4 + ''tile'' * 128

The filenames for each tileset match the levels, so <tt>FOREST.TT2</tt> contains the tiles for the three map files <tt>FOREST[0-2].PT</tt>.

== Credits ==

This file format was reverse engineered by [[User:Malvineous|Malvineous]]. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)