If you appreciate the work done within the wiki, please consider supporting The Cutting Room Floor on Patreon. Thanks for all your support!

Notes:Harvester

From The Cutting Room Floor
Jump to navigation Jump to search

This page contains notes for the game Harvester.

BM File Format

BM files contain all the static background bitmaps and non-animated foreground sprites in the game.

The source code in C# to an application which can convert this filetype to something readable can be found here: HarvesterImageConverter

Every BM file beings with a simple 9-byte header:

0x00 u32 - Bitmap width
0x04 u32 - Bitmap height
0x08 u32 - Presumed to be a pointer to an external palette file

The bitmap data in pixels then follows:

0x0C u8[Bitmap width * Bitmap height]

Each byte is a pointer to a R/G/B triplet in the accompanying palette file.

Each PAL file simply contains 256 8-bit R/G/B triplets,
making the file exactly 768 bytes in length.


(Source: HarroSIN)
(Source: Davidoff96)

ABM File Format

ABM files contain all the animated sprites in the game (the player character, NPCs, enemies and room objects).

The source code to an application which can convert these files is available upon request because it's a work-in-progress and uses dirty/lazy GOTO statements.

Every ABM file begins with an 8-byte global header:

0x00 u32 - Total number of cells
0x04 u32 - Largest Frame Bytecount (the largest result of cell_width*cell_height in the sequence, for allocating arrays)

A local header for the first cell follows:

0x08 u32 - Cell padding on the X-axis from 0 // Can skip if simply extracting cells and not drawing to screen
0x0C u32 - Cell padding on the Y-axis from 0 // Can skip if simply extracting cells and not drawing to screen
0x10 u32 - Cell width
0x14 u32 - Cell height
0x18 u8  - Compression flag (0 = uncompressed, 1 = RLE)
0x19 u32 - Payload length in bytes
0x1D u32 - Unknown (presumed to be a pointer to an external palette file)

The image payload then follows based on the payload length.

If the file is uncompressed, each byte represents one pixel similar to the BM file format above.
If the file is compressed with RLE, the formula is as follows:

READ a control byte.
  IF the top bit is 0, the following X bytes are literal based on the lower 7 bits of the control byte.
  ELSE the top bit is 1, the following byte is repeated X number of times based on the lower 7 bits of the control byte.
DO until end of payload.

Once the image is written, repeat the above steps (local header + payload data) for each cell.

Source code for decoding an .ABM file (in C#) can be found here: HarvesterImageConverter.ConvertAnimatedImage

(Source: HarroSIN)
(Source: Davidoff96)

DAT (XFLE) Archive Format

DAT files (called XFLE archives by the engine) are binary packages encompassing all the resources for Harvester (mostly containing graphics and voice-over files).

The source code to an application which can extract these files is available upon request because I'm in the middle of porting it from ANSI C to Win32.

Every file entry in the DAT archive begins with a 148-bytes header:

0x00 uchar[4] - "XFLE" magic header
0x04 s8[128]  - File name INCLUDING internal drive letter and directory path (never larger than 64 bytes -- may contain junk data after filename string) first byte may be null, advised to ignore and resume parsing the rest of the string if it is the first byte.
0x84 u32      - Data pointer (this almost always points +12 bytes from here globally, which is at the end of the header)
0x88 u32      - File length
0x8C u32      - zeroes (these never change, have an unknown purpose)
0x90 u32      - File length (again, is always identical to first occurrence)

The payload is located at the data pointer, and is as long as the file length; although this is usually immediately after the header.

INDEX.00* files have the exact same content as all DAT files, just lacking the file data -- only the 148-byte XFLE headers back to back. All pointers and lengths remain the same.
(Source: HarroSIN)
(Source: EntranceJew)

Relevant Formats

Other notes on formats used in-game are available here:

  • FST FMV video + PCM audio
   * Some notes on the page above do not seem to be completely correct, but I have not finished implementing the FMV extraction portion so I cannot identify which ones in particular are wrong.
  • CMP sound effects