Pictures

Dark Seed for DOS uses a somewhat unusual VGA graphics mode: 640x350 with 16 colors. The manual explains how this was negotiated with artist H R Giger:

Giger agreed to lend his artwork, provided Cyberdreams uses only high-resolution graphics mode, in order to avoid the "square and jagged" look of low resolution.

The two programs by (START.EXE and TOS.EXE) by the two separate programmers (Krause and Feddersen, respectively) each use their own image formats. START.EXE uses files called ".IMG" while TOS.EXE uses ".PIC" instead.

Animations

This section is a stub.

START.EXE uses image (IMG) and animation (ANM) files, while TOS.EXE uses picture (PIC) and (NSP).

Sprites

This section is a stub.

NSP files (aNimated SPrite?)

Palettes

The palettes are stored in files with the extension ".PAL". The format is straightforward and maps very closely to VGA hardware. There are two sizes: most are 16-color palettes (stored as 48 bytes), and also a few 256-color palettes (stored as 768 bytes) but these seem to be unused in the game.

Each of the sixteen entries is three bytes: one byte for red, one byte for green, one byte for blue. The maximum value is 63. Thus pure white is represented as (63, 63, 63), pure black as (0, 0, 0).

Each room has its own palette file but many of them are complete duplicates.

Sound and music

Later (CD-ROM) versions of Dark Seed for DOS used standard MIDI files for music and Creative Labs "Voice" files for sound effects and speech. The speech files have the usual ".VOC" file extension and the sound effects use the alternative ".SFX" name.

Earlier (floppy) versions of Dark Seed for DOS provided music and sound in other formats to work with various hardware at the time. The three options are the basic PC speaker, AdLib, and Sound Blaster.

01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 00 13 14 15 16 17 18 00

String lists

The credits text is embedded as data in START.EXE, and the names of objects are embedded as data in TOS.EXE. Most of the in-game messages are read from an TOSTEXT.BIN.

The format of TOSTEXT.BIN begins with an ordered series of little-endian uint16 offset values. Each one of these offset values point to the start of a text string later in the file. The offset value is an absolute position within the file.

The series of bytes at the start of the file:

a6 07 d4 07 f6 07 ...

Can be read as a series of little-endian integers:

• 0x07a6
• 0x07d4
• 0x07f6

Which in turn can be used as file offsets to find a line of text:

0x07a6: "You have dared touch an Ancient! You die!\r\n"
0x07d4: "Fido takes a chunk of your head\r\n"
0x07f6: "The fleshy stalk"...

  93091353: FILES:file open command 0 file art\house.pal
  93091404: FILES:file open command 0 file art\letters.anm
 116353477: FILES:file open command 0 file art\ship.pal
 116353531: FILES:file open command 0 file art\left00.img
 116633112: FILES:file open command 0 file art\left01.img
 116906072: FILES:file open command 0 file art\i001.img
 117059306: FILES:file open command 0 file art\shipin.anm
 117064602: FILES:file open command 0 file credits.sbr
 117481719: FILES:file open command 0 file credits.pcs
 117529891: FILES:file open command 0 file credits.sit
 141428741: FILES:file open command 0 file art\t2.anm
 157367052: FILES:file open command 0 file art\tm.img
 157368774: FILES:file open command 0 file art\version.img
 157385720: FILES:file open command 0 file art\letters.anm
 157385949: FILES:file open command 0 file art\bdoll0.img
 157385991: FILES:file open command 0 file art\bdoll1.img
 157386037: FILES:file open command 0 file art\house.img
 158404462: FILES:file open command 0 file art\title.img
 158610266: FILES:file open command 0 file art\version.img
 158627215: FILES:file open command 0 file art\house.pal
 222938144: FILES:file open command 0 file art\nm1.anm
 222938393: FILES:file open command 0 file art\ship.pal
 222982876: FILES:file open command 0 file art\nmf0.img
 223289229: FILES:file open command 0 file art\nmf1.img
 223585787: FILES:file open command 0 file art\nm101.img
 223993317: FILES:file open command 0 file implant.sbr
 224304486: FILES:file open command 0 file implant.pcs
 224397303: FILES:file open command 0 file implant.sit

Pictures

Files with that begin with the header magic number "MCP" (M's Compressed Picture, perhaps?) are, once decompressed, in a suitable format for blitting to the Amiga graphics hardware.

The header is eight bytes. The low-order nybble of the fourth byte is either 1 or 4, and shows the count of bitplanes. A single bitplane file can be decompressed as a single stream.

The following two 16-bit values represent width and height respectively. The width is rounded up to the next multiple of 16 then divided by 8 and stored as a count of bytes per line. The height is multiplied by half of the width and the result is stored as the number of 16-bit words per bitplane. In the case of a single bitplane, that number (height times width-rounded-up divided by 16) is the number of words in the whole decompressed file.

In the case of multiple bitplanes, the decompression result is allocated first to the first (lowest-order) bitplane until it fills up (at a 16-bit word boundary). The next bytes to be decompressed fill up the second bitplane, until it fills up, and so on until all four are filled. These filled bitplanes are all the same size, and can be converted to so-called "chunky" format of one-byte-per-pixel palette indexes using an established "planar to chunky" conversion algorithm.

Here are the header bytes of some example files and their expected decompressed size:

Palettes

The Amiga floppy disk and Amiga CD32 version of Dark Seed both use 16-color (4-bit) palettes. Each of the 16 entries is a 16-bit number: 0xfff is bright white, 0x000 is pure black. The palettes are stored as data in the game executable rather than in a separate file.

There is a default palette and a table of 8 alternate palettes. The table of alternate palettes is 256 bytes: 8 palettes of 16 entries. There is a different table of data elsewhere in the executable which you can use to calculate which palette to load for each resource.

Resource IDs are 32-bit numbers that can also be treated as ASCII filenames.

Resources with a zero palette byte: No modification.

Resources with a "positive" palette byte (0x01-0x7e): Standard with modification. The second-highest palette entry is replaced with a value from a 63-entry lookup table.

Resources with a "negative"/high palette byte (0x80-0xff): A specific alternate palette. The number of the alternate palette can be calculated using (x + 5) % 8 where x is the byte in the lookup table and % is the remainder after division.

Sprites

Smaller image overlays and updates are stored as flat images in the additional materials files. They are pictures in the same MCP (compressed picture) format as the room pictures.

The coordinates and parameters for which parts of the image data are used, as well as animation timing, live in the executable file (see Object data).

R00B stores the sprite image data for room 0, but not all rooms have such image data. Room 1 has none at all, while room 31 has several separate images for different sprites: R31B (stick), R31C (Delbert throwing), R31D (dog), R31E (Delbert walking and drinking), and R31F (Delbert standing).

The image data for player walking sprites is stored in the resource file W1 (light world) and W2 (dark world). Likewise, the image data for the player falling is stored in resources F1 (light world) and F2 (dark world).

The styled font used for the opening credit sequence is a sprite too, stored in N03A. The main font for message text in the game is stored in the same file as the inventory pictures: I1 (light world) and I2 (dark world).

Object data

The Amiga game executable contains some of the same animation information that is called "Objt" in the Macintosh port.

• Byte: sprite number
• Byte: x
• Byte: y
• Byte: count1
• Byte: count2

Then a series of:

• byte: xdelta
• byte: ydelta

Sound and music

Rooms

The "R01A" file holds the static picture for room 1 in the same format as the other game graphics.

String lists

The Amiga editions do not store string lists in separate files, but rather as data in the game executable file.

There are two string lists:

• a big one with response messages (?-997), matching the efx speech
• a small one with item names and credits (0-301)

Both the string lists are in the same "hunk" of the executable, the final hunk.

A string list is stored as a big block of strings are provided concatenated together without any dividing marker. After the strings have finished, there is a separate numerical list of each string's starting position within that concatenated block.

NothingBoxHandQuestionCtrlcrowbarjournalscotch
^      ^  ^   ^       ^   ^      ^      ^
0      7  10  14      22  26     33     40

Movies

The four resources called M00B, M01B, M02B, M03B each have the signature MDA and seem to represent full-screen animations.

These files have a header structure not unlike MCP.

The low-order nybble of the fourth byte (offset 3) is used for the number of bitplanes. (All four files have the value 4 here, for 4 bitplanes). The higher-order nybble (always 1 in these files) is used to calculate bytes ber bitplane with the following algorithm: (x + 1) * 2

The next four bytes are interpreted as 16-bit integers (big-endian) are width and height. Always 320 width and 400 width.

The rest of the file is structured as follows:

• MSB word, COUNT, count of the upcoming chunk of data bytes
• one byte indicating which bitplanes to update
• another byte (padding, seemingly ignored)
• COUNT bytes of difference data for the frame in the format described below

Each frame is structured as follows:

• changes for bitplane 0
  • five bytes (40 bits)
  • a series of byte-column row changes
• changes for bitplane 1
  • five bytes (40 bits)
  • a series of byte-column row changes
• changes for bitplane 2
  • five bytes (40 bits)
  • a series of byte-column row changes
• changes for bitplane 3
  • five bytes (40 bits)
  • a series of byte-column row changes

Each bit in the five-byte stretch at the start of each bitplane represents a "byte column" (8 pixels) in the picture. If there are no changes to this bitplane in this frame, these bits will all be clear. If the first (highest-order) bit is set, the leftmost "byte column" has changes in this frame -- that is, some of the left-most 8 pixels have changed value.

For each column bit set, there will be a set of row updates. These follow in order directly after the byte column change summary.

• count of upcoming row updates, each of which has:
  • byte (uint8) for row count which is is split:
    • high bit clear means changes are included
    • high bit set means no changes to row count rows
    • remaining bits are the actual row count (RC)
  • Series (length RC) of bytes of of data to be XORed

Files

Many of the files are exactly the same between the Amiga floppy disk version and the CD32 version. There may be some language-specific changes in pictures (like the newspaper, the note from the movers, etc).

Resources in Dark Seed

A credit image says "Darkseed Macintosh developed and programmed by Brian Fitzgerald", and that name appears in other credits.

It seems to have been built with "THINK C" and AppMaker, and some debugging/development information seems to have been left behind. (A happy accident for digital preservationists.) An icon says "THIS SPACE FOR RENT", presumably as a joke.

Templates

Macintosh resource management tools like ResEdit and the third-party Resorcerer use template resources (with the ResType "TMPL") to provide a convenient user interface for resource data.

The format of TMPL resources is documented in the official Macintosh ResEdit Reference from Apple, and the Resorcerer Template Information has information on some extended structures that Resorcerer provides.

Pictures

Dark Seed uses at least four different resource types for graphic data ("PicL", "PicD", "Fram", "Room"), but they all seem to be encoded in the same way.

It presumably uses compression, perhaps similar to the compression used in Dark Seed for DOS (nybble-based run-length encoding) or Dark Seed for Amiga (LZSS).

The window frame pictures ("Fram" resources) come in two sizes, one default and one for 12-inch displays (presumably targeting a 512x384 resolution instead of the default 640x480).

Palettes

Many resources with ResType "pltt" have names closely tied to the DOS version of Dark Seed ("ROOM04.PAL", "LIB-BABE.PAL"). The format seems to be a 16-bit big endian count of entries, then 16 bytes for each entry. An entry is mostly zeroes. Three of the bytes are not zero, and I presume then to be a byte each for red, green and blue.

Most of the palettes seem quite similar to each other, or even exactly the same.

Sprites

The resources with ResType "Sprt" are sprite animations.

They have names quite closely tied to the DOS version of Dark Seed ("ASPIRIN.NSP", "RM10STAIRS.NSP", "ROOM04.NSP") and are often similar in size to the DOS editions too. They presumably represent much the same data as the DOS ".NSP" files but have such different byte values that the data must be structured differently.

Rooms

The "Room" resources appear to hold the per-room static picture in the same format as the other game graphics.

000000020129013700BC000C000C002900BD01BE006C0038006E000000040140008200FD00AF00FD01B8014001E5

0000 one-based count of links
     (no links)

    0002 one-based count of objects

        01 object 1 type
          29 object 1 number (ITEM_TIN_CUP)
            0137 object 1 x
                00BC object 1 y
                    000C object 1 width
                        000C object 1 height
                            00 object 1 depth
                              29 object 1 sprite

                                00 object 2 type
                                  BD object 2 number (ITEM_CELL_BARS)
                                    01BE object 2 x
                                        006C object 2 y
                                            0038 object 2 width
                                                006E object 2 height
                                                    00 object 2 depth
                                                      00 object 2 sprite


                                                        0004 one-based count of polygon points

                                                            01400082 point 1 (320, 82)
                                                                    00FD00AF point 2 (253, 175)
                                                                            00FD01B8 point 3 (253, 440)
                                                                                    014001E5 point 4 (320, 485)

0002000200000000 41 05 0000 0000 42 05 0001 0000 0000 00 05

0002 count of objects

    0002 count of object 1's frames

        0000 x vector for object 1 frame 1
            0000 y vector
                41 sprite number
                  05 ticks

                    0000 x vector for object 1 frame 2
                        0000 y vector for object 1 frame 2
                            42 sprite number
                              05 ticks

                                0001 count of object 2's frames
                                    0000 x vector for object 2 frame 1
                                        0000 y vector for object 2 frame 1
                                            00 sprite number
                                              05 ticks

String lists

The game contains string lists as standard Macintosh "STR#" resources.

One list (resource ID 301, named "English item strings") contains the names of game objects in what seems to be the same order as code (crowbar=5, journal=6, scotch=7).

The credits mention separate teams for "IBM" and Macintosh. The game strings include some leftover DOS-specific values like mentioning "Soundblaster".

Movies

The resources with the ResType "Movi" are presumably the bigger animations.

They have somewhat descriptive names ("Nightmare 1a", "SpaceLetters d"), with only a few kinds of name:

• Nightmare
• SpaceLaunch
• SpaceLetters
• SpaceLand

In addition, one of the "Movi" resources (ID 131) seems to have been blanked out. It is named "-- Nightmare 2 --" and has a single byte (0xDD) as its entire content.

Sound and music

Speech and sound effects are stored as AIFF "snd " resources, as are the instrument samples that are arranged into music. Two codecs are used: raw unsigned 8-bit PCM (codec identifier "raw ", with the space) and the less-common Macintosh Audio Compression/Expansion 3:1 (codec identifier "MAC3").

The sequence and timing of notes to play is stored as standard MIDI data in "Midi" resources. The selection of instruments are stored in "Inst" resources.

The resource templates tell us the structure to interpret "Inst" instrument data:

• one-based count for list of instrument definitions, where each item has:
  • 'snd ' resource (DWRD, decimal word) - presumably resource ID
  • Fixed pitch (0=none) (DWRD)
  • Loop enable (BOOL, boolean byte)
  • Voice enable (BOOL)

Strings

The strings are in the same format as Macintosh "STR#" resources: a 16-bit count for the number of strings, followed by a length byte for the first string, followed by the first string's characters, then the length byte for the second string, then the second string's characters, and so on. The text is encoded with Shift-JIS, a widely-used standard for Japanese text at the time. The Japanese PlayStation resource ST301.STR corresponds with "STR#" resource number 301 (named "English Item Strings" in the English Macintosh release):