File format description


This page describes the format of Prehistorik 2's data files. Only for the brave!
You can use this information as you wish, but don't forget to mention where it came from :-).

Jump to:
Main
Decompression
Level files


Main

Prehistorik 2 data file format
By Jesses (mail at pre2 dot mine dot nu) and Dorten
Visit http://pre2.mine.nu for more Prehistorik 2 stuff

Main file, v0.9.
Version history:
  0.9 - initial version

This set of files describes the file format of the Titus the Fox / Moktar data
files.

Included files:
  main.txt        This file
  compress.txt    Describes how to decompress .SQZ and .TRK files
  format.txt      Format of uncompressed level files
  SPRSIZE.BIN     Sprite size table
  PRE2.PAL        Palette information

SQZ files are compressed with either DIET or ZIV (the Moktar/TTF compressor).
The COMPRESS.TXT file explains how to uncompress them.

This is what the various files are; all are compressed with DIET, unless
otherwise mentioned (e.g. ZIV).

Music (regular .MOD format):
*.TRK

320*200*4 pics:
BACK*.SQZ    - Level backgrounds
GAMEOVER.SQZ - Game over screen
MOTIF.SQZ    - Background during beginner/expert choice and level code entry
MENU2.SQZ    - Background during the demo

640*200*4 pics:
MAP.SQZ      - The between-levels scrolling map

320*200*8 pics:
MENU.SQZ     - Menu
TITUS.SQZ    - Titus logo. ZIV-compressed.
CASTLE.SQZ   - "To enter you must be an expert eater!". ZIV-compressed.
THEEND.SQZ   - End screen. ZIV-compressed.

320*(200+93.2)*8 pics:
PRESENT.SQZ  - Title screen. ZIV-compressed.

640*415*(2+2) pics:
LEVELH.SQZ   - Together, these two files contain the developer's photo. It
LEVELI.SQZ     uses a grayscale palette.

tiles:
FRONT.SQZ    - Contains 163 tile sprites for masked tiles
UNION.SQZ    - Contains 544 shared tile sprites

levels:
LEVEL*.SQZ (except LEVELH and LEVELI)

sprites:
SPRITES.SQZ

misc:
ALLFONTS.SQZ - Contains... all fonts!
KEYB.SQZ     - Unknown, probably used as input for the demo. ZIV-compressed.
SAMPLE.SQZ   - Unknown. Likely the SFX samples, but not in an obvious audio
               encoding. Probably needs another decoding step.


The bitmap format used for the 4-bit pics is planar; so, you get 4 monochrome
pictures one after the other, one per plane.
One special case: the pic in LEVELH+LEVELI has planes 0/1 in LEVELH and planes
2/3 in LEVELI, so in effect these two files need to be treated as if they were
concatenated.

8-bit pics are simply packed pixel format, with an included palette. The
palette comes first at offset 0, and consists of 256 RGB triplets where each
component is in the range 0 to 63. After that, at offset 768, comes exactly
65536 bytes of pixel data, as it would appear in VGA memory. It's 320*200 plus
some padding.
Here there is also a special case: in PRESENT.SQZ, an additional 320*93.2
image is stored after the first 65536 bytes. It contains the part of the image
with the title "Prehistorik 2", which is faded in during the game. 93.2 lines
means that it contains 93 full lines and 64 pixels on the last line, which
covers exactly the title logo part of the image.


The bitmap format used for the tiles and sprites:

The format of a tile (and a sprite too) is 4-bit planar. I.e. for a 16*16
image (like a tile) it goes like this:
  32 bytes of monochrome 16*16 bitmap for plane 0
  32 bytes of monochrome 16*16 bitmap for plane 1
  32 bytes of monochrome 16*16 bitmap for plane 2
  32 bytes of monochrome 16*16 bitmap for plane 3

Each monochrome image is as you'd expect a monochrome image to be: a simple
w*h array with each byte holding 8 pixels.


Sprites always have a multiple-of-8 width. They also have a transparent
color, 0, which makes for easy ANDing/XORing them on screen. The file
SPRITES.SQZ holds them, but only the images; the (variable) sprite sizes are
stored in the exe. You'll need a table to display then, which can be found
in the file SPRSIZE.BIN. It contains 2 bytes for each sprite: width and height.
However, for sprite #156 (the game boy) the height actually is 19! The other
values are correct however.

Tiles are always 16*16, luckily :-)

About the palettes, they're in the exe file. There are 10 palettes to choose
from, which you can find in the file PRE2.PAL. Each palette contains 8-bit
B, G, R, 0 values for each of the 16 colors in a palette. Here's a string
showing which level uses which palette (i.e. palette for level 2 is 1):
0134568899222298

Decompression

Prehistorik 2 level format
By Jesses (mail at pre2 dot mine dot nu) and Dorten
Visit http://pre2.mine.nu for more Prehistorik 2 stuff

SQZ decoding explanation, v1.0.
Version history:
  1.0 - initial version

The data files of Prehistorik 2 are compressed, so before you can do anything
with them they must be unpacked.

Some of the files are compressed using ZIV, the compressor from Moktar/Titus
the Fox.
For more details on that, see: http://ttf.mine.nu/techdocs.htm#compress

The majority of the files are compressed with DIET, which can also be used to
decompress them. Version 1.45f of DIET can be found here:
  http://www.vector.co.jp/soft/dl/dos/util/se000305.html
or here for the Japanese-challenged:
  http://translate.google.com/translate?sl=ja&tl=en&u=http://www.vector.co.jp/soft/dl/dos/util/se000305.html

DIET 1.45f has some issues though. When run, the program may give the error
"Abnormal program termination" and refuse to do anything. If that happens,
try running it in DOSBox. Alternatively, try running it from a FAT16
partition, or from a floppy disk. On today's floppy-deprived systems Virtual
Floppy Drive (http://vfd.sourceforge.net/) might be a very useful tool in this
regard.

To decompress a file with DIET, use the following command:
DIET -R filename.SQZ

Level files

Prehistorik 2 level format
By Jesses (mail at pre2 dot mine dot nu) and Dorten
Visit http://pre2.mine.nu for more Prehistorik 2 stuff

Level file format, v0.8.
Version history:
  0.8 - initial version

This file explains the format of LEVEL*.SQZ, after decompression.

All levels are 256 tiles wide, but their height varies. Unfortunately, you
need to know this height, but it's not stored in the file but in the
executable. Here is a table with the heights for each level:
1   2    3   4   5    6    7    8   9    A   B   C   D   E   F    G
49, 104, 49, 45, 128, 128, 128, 86, 110, 12, 24, 51, 51, 38, 173, 84

The level file starts with a tile map, sized 256*height bytes. Each byte is
actually an index in a lookup table of 256 16-bit values. This table is
placed directly after the tilemap. The table contains 3 types of numbers:
less than 256, equal to 256 and greater than 256. Tile 256 is transparent
and shows the background picture. Tiles 0..255 are level-specific tiles,
while tiles 257+ are shared among the levels. You need to determine the
maximum value among the level-specific tiles, so this maximum will be in the
range 0..255; let's call this SmallNum. For these small numbers, a total of
SmallNum 4-bit 16*16-sized tile bitmaps can be found directly after the lookup
table (at byte offset number*128; 128 is the size in bytes one tile takes),
while for the larger numbers, the shared tiles are in the (compressed) file
UNION.SQZ at offset (number-256)*128.

An example to clarify: let's say we have a hypothetical level that's only one
tile high. Then at offset 0 in the level file, there's a 256*1 byte tilemap.
Let's say the first four bytes in the tilemap are 2, 1, 0, 3, and the rest of
the tilemap bytes are all 1.
After the tilemap, at offset 256, there is a lookup table sized 512 bytes.
Let's say the 16-bit values in this table at offsets 0, 1, 2, 3 are
respectively 270, 256, 214, 68. This means that the first(214) and fourth(68)
tile bitmaps are stored in the level file at offsets 256*1 + 512 + 214*128
and 256*1 + 512 + 68*128, the third(270) tile bitmap is stored in UNION.SQZ at
offset 14*128 and the rest of the tiles are transparent (256), i.e. show the
background picture. Now SmallNum is the maximum of the values less than 256,
so the maximum of 214 and 68, which is 214. The remainder of the level file is
stored at offset 256*1 + 512 + 214*128.

This remaining part of the level file is not yet completely clear. It starts
at offset 256*levelheight + 512 + SmallNum*128, or more conveniently put at
filesize - 5029. Let's call this position offset 0 from now on to keep things
simple.

Here's a table showing the remaining level structure, as far as it's known:

Offset  Size      What it is ("field: x" means that that field takes x bytes)

0       256       Tile properties byte 1
256     256       Tile properties byte 2
512     256       Tile properties byte 3
768     2         ????
770     2         X start
772     2         Y start
774     1         If tile with this x coord is the leftmost on screen, it
                  won't scroll right any further.
                  To get actual horizontal level size add 20.
775     1         ???? (in original levels always 0)
776     1         Scrolling behavior
777     256*2     For tile opacity: number of overlaying sprite for each tile.
1289    20*7      Gates:
                    xin: 1
                    yin: 1
                    xscreen: 1
                    yscreen: 1
                    xout: 1
                    yout: 1
                    scroll: 1
1429    15*10     Shifting tile blocks:
                    x: 1
                    y: 1
                    width: 1
                    height: 1
                    xact: 1
                    yact: 1
                    FFFF: 2 (constant)
                    dist: 1
                    00: 1 (constant)
1579    2048      Enemy records: (size of each record varies)
                    length: 1 (length of this record)
                    type/expert: 1
                    sprite: 2
                    unknown1: 1
                    hitpoints: 1
                    pause: 1
                    unknown2: 1
                    score: 1
                    x: 2
                    y: 2
                    type-specific: variable length (remainder of record)
3627    2         Item/platform sprite number offset
                  Actual_sprite_number = stored_sprite_number + 53 - offset
3629    2         Enemy sprite number offset
                  Actual_sprite_number = stored_sprite_number + 312 - offset
3631    80*5      Secrets:
                    FromTile: 1
                    ToTile: 1
                    Bonus/health: 1
                    x: 1
                    y: 1 
4031    256       Tile properties byte 4
4287    70*7      Items:
                    posx: 2
                    posy: 2
                    sprite: 2
                    00: 1 (constant)
4777    16*15     Platforms:
                    posx: 2
                    posy: 2
                    sprite: 2
                    behavior: 1
                    speed: 1
                    ????: 1 (always FF)
                    drop delay: 1
                    distance: 2
                    ????: 1 (always 0)
                    drop1?: 1
                    drop2?: 1
5017    2         Left border of Kong movement
5019    2         Right border of Kong movement
5021    1         ???? Kong-related, 2, 3 or -1. When set to 1, Kong starts
                  jumping on sight, when 5, he awakes only after a couple of
                  blows in the head. NOT sure about this one.
5022    2         Kong health
5024    1         ????  0 or -1 (if -1 => no Kong)
5025    2         Kong x coord
5027    2         Kong y coord


Now a detailed description for the above fields.


Tile properties: offsets 0, 256, 512, 4031
  Four bytes per tile, in four 256-byte tables.

  First byte (plain value) - Horizontal properties
    Value Meaning
    1     Solid sides
    2     Deadly from the sides

  Second byte (plain value) - Vertical properties
    Value Meaning
    1     Solid top, some of these tiles have different 'height', the player
          is forcing down through them a little (sample is bone rubbish at
          level E)
    2     Slightly slippery
    3     Slippery
    4     Not used in original levels, AFAIK, but if set makes floor VERY
          slippery (like in ttf)
    5     When standing on it and pressing down, becomes non-solid
          (hatches on level 2)
    6     Deadly from the top

  Third byte (bitfield) - misc
    Bit Meaning
    0   Solid bottom
    1   Deadly from the bottom
    4   Seen only in combo with bit 6 on level 3. Flies are going out of it.
    5   When stepped on, switches to next tile
    6   Player is partially hidden behind the tile, see offset 777.
    7   Tile is animated, using current and next two tiles (next two tiles are
        also animated, even if their third byte doesn't have bit 7 set)

  Fourth byte (bitfield) - slope information
    Bit  Meaning
    0..3 Reversed height of left corner. Height of right corner depends on
         adjacent tile if not horizontal.
    4    If set, tile is a slope going downright
    5    If set, tile is a slope going upright

    If bits 4..7 are 0, the tile is a horizontal floor.

  About Partially transparent tiles: it must be a mask, because you can find
  both transparent and non-transparent pixels of the same color on one tile.
  Also, some tiles, like slopes on level 7 have variable height, but their
  properties are not different from simple ice...

Unknown: offset 768

Start: offset 770, 772
  Here you start the level.

Scrolling limit: offset 774
  The screen won't scroll further to the right than this position, unless
  the player is to the right of it. In tiles, so multiply by 16 to get pixels.

Unknown: offset 775

Scrolling behavior: offset 776
  Bit Meaning
  0   Works with vertical scrolling. When not set, game tries to keep minimal
      distance between player and up/bottom of screen at about 2 tiles, when
      set, it's 4 tiles.
  1   When set, no horizontal scrolling. going to the right => death, more
      than 1 screen to left => also death
  2   When set, screen scrolls down by itself, going up => death

  So, in level 6 you get the value 6, but this behavior is forgotten as soon
  as the boss is awakened... If set to 0 or 1, the boss awakes at level start.
  This trick does not work with level 3's or level 9's bosses (i.e. the screen
  continues to descend)

Opacity masks: offset 777
  When player/enemy goes near "masked" tile, the sprite from FRONT.SQZ with
  the corresponding number pops out and closes him.

Gates: offset 1289
  In/out are the entrance/exit, screen is the screen's position after exiting
  the gate, scroll indicates whether the screen can scroll after going through.

Shifting tile blocks: offset 1429
  No description yet.

Enemies: offset 1579
  This one is a bit complicated: "length" is the number of bytes this enemy
  record contains; each enemy record is variable-length.

  Length:
    Length of record
  Type/expert:
    Bits 0..6 contain the enemy type. If bit 7 is set then this enemy is only
    present in expert mode.
  Sprite:
    Sprite number
  Unknown1:
    Not yet known, somehow affects behavior of type 9
    (0 - ignores gravity, 8 - not)
    type 2 spiders always have 1
    Type 0 have 3
    all others have 0
  Hitpoints:
    Enemy hitpoints (if not mistaken, throwing stoneaxe does 10 damage, club
    and hammer do damage, which depends on distance or even random
  Pause:
    Pause before activating actions in tenths of second (or something like
    that), for example a pause between jumps of jumping dino, or between death
    and spawn of type 0 and 10 enemies. Max value is 63. Anything more equals
    to eternity
  Unknown2:
    ????? seen only 00 or FF, maybe internally used
  Score:
    Score value: 0=>100, 1=>200 ... 11=>8000 (see sprite sequence)
  X, Y:
    Coordinate in pixels (if not type 0 or type 10)
  Type-specific:
    0: Falls from the sky, after landing walks, affected by gravity and walls.
       Active, when player is in The Area
      Length 13
      Bytes 9,10  - x,y coordinates of upper left corner of The Area
                    (instead of X, Y coordinates of the enemy)
      Bytes 11,12 - width and height of The Area
    1: Does not move, attack or die... Just a plain decoration (Spiderwebs)
      Length 13
    2: Moves up and down on a web (Spiders)
      Length 15
      Byte  13    - maximum web length
      Byte  14    - speed  
    3: Spawning spiders
      Length 14
      Byte  13    - Distance (in tiles?) at which it becames active.
    4: Pendulum spiders
      Length 17
      Byte  13    - Radius
      Byte  14    - Angle. Don't know in what units.
      Bytes 15,16 - always FF?
    5: Stands still, until player is on the line of sight, then moves
      diagonally down, when on the one horizontal with player - changes
      direction to horizontal (some bees at third and seventh levels)
      Length 16
      Byte  13    - width of rectangle, counted as line of sight (tiles)
      Byte  14    - height of rectangle, counted as line of sight (tiles)
      Byte  15    - Speed
    6: Clever flying enemy
      Length 21
      Byte  13    - distance of activating (horizontal) in tiles
      Other       - always FF?
    7: Stands still, until player is on the line of sight, then
       moves diagonally down
      Length 15
      Byte  13    - distance of activation (horizontal) in tiles
      Byte  14    - Speed
    8: Jumps (Dinos, leopards, little wormies...)
      Length 17
      Byte  13    - x  distance in tiles. When player is closer, starts
                    jumping (but waits some time at first, depending on its
                    'pause' value)
      Byte  14    - Vertical jump power. Height = VJP*(VJP+1)/2 pixels
      Byte  15    - Horizontal jump power.
      Byte  16    - like byte 13, but for vertical distance
    9: Goes left-right, ignoring walls (ignoring walls depends on byte 4
      (unknown1), in the case of penguins at level 7, can go by the slopes...
      But in other cases, not affected by gravity.)
      Length 19
      Bytes 13,14 - left border
      Bytes 15,16 - right border
      Byte  17    - always FF?
      Byte  18    - speed? (not clear, like with the next type)
    10: Spawns from the ground, walks some time, then goes underground again
      Length 14
      Bytes 9-12  - are used like in type 0
      Byte  13    - Not quite clear. Something like speed limit. (when set to
                    1, the enemy always stands still. Setting to 2 results in
                    sometimes_standing_but_sometimes_slowly_moving enemy, 
                    setting to 10 gives always_slowly_moving enemy, setting to
                    150 produces very_fast enemy. Needs further investigation)
    11: Flying squirrels. They can spawn at several different points, in a
      range of about 6 tiles (or maybe 100 pixels) up from x,y position
      Length 16
      Byte  13    - Horizontal speed
      Byte  14    - starting jump power (like in type 8)
      Byte  15    - Vertical speed
    12: Fast running penguins and cavemans 
      Seems, that they are activating, when x,y is about one screen away. Then
      they spawn at the edge of a screen. Nasty...
      Length 15
      Byte  13    - speed
      Byte  14    - always FF?

  Not sure about sprites. There may be hardcoded sprite sequences for 
  different enemy types. Setting sprite property to anything inappropriate 
  results in unpredictable behavior: when setting sprite of up-down moving 
  spider to 317 (spiderweb), there's a WASP, instead. When trying to create a
  jumping spider, there's jumping bears, transforming into leopards in the
  air, and SEVERE graphical artifacts (?!?). Setting the sprite of spawning
  spiders to 318 gives funny results :)
  Setting the sprite to an item sprite makes level not loadable.

Sprite offsets: offsets 3627, 3629
  These need to be used to convert stored sprite numbers to actual sprite
  numbers.
  Actual_item_sprite_number = stored_item_sprite_number + 53 - item_offset
  Actual_enemy_sprite_number = stored_enemy_sprite_number + 312 - enemy_offset

Secrets: offset 3631
  FromTile: Initial tile
  ToTile: Not used, tile changes to the tile on the map
          (in original levels tileTo=tile on the map, changing does no effect).
  Bonus/Health:
    00 to 3F: 1 to 64 small bonuses
    40 to 7F: 1 to 64 hits needed. Stars, dirt bits etc go out, depending on
              the level (maybe stored somewhere, maybe in exe, not yet known)
    80 to FF: Big bonus, hitpoints=(value-127)*x (or so) x is about 5 or 6
  If several such tiles are adjacent, they all change.
  If one of them changes and you hit several of them at one time, Bonus/Health
  of rightmost of the lowest row (from the ones you hit) is used (needs to be
  checked).

Items: offset 4287
  Should also be clear. The level exit is also among the items.
  The last byte in the items records is always zero; if set to anything else,
  nothing changes ingame.

Platforms: offset 4777
  Behavior:
    Bit  Meaning
    0..2 Direction of moving
         7 0 1
         6 * 2
         5 4 3
         I.e. when 5, moves downwards towards the left.
    3    Dropdown
    7    If set, then platform works by itself; if not set, starts moving when
         player is on and stops at end of the cycle when he steps off
  Speed:
    Max speed of movement. If speed = zero and behavior = 08, then if stepped
    on platform drops down quickly until it hits solid ground (or into the
    abyss, if there is none) and waits, until player steps off
  Drop delay:
    If not dropdown - then FF
    If dropdown, the delay before dropping
  Distance:
    Time of moving on max speed if not dropdown, else zero
    Distance of moving: speed*(time+speed-1). Additional speed^2-speed is due
    to accelerating and braking.
  Drop1?:
    If not dropdown - zero, else = drop delay
  Drop2?:
    If not dropdown - zero, else = FF

Kong: offsets 5017, 5019, 5021, 5022, 5024, 5025, 5027
  Yeah, that's him: big dumb monkey. Tried to place him on 6th level. That was
  strange, you should try it yourself ;)


Value of unknown entries in the original levels:
  Level    768(int) 775(byte) 
  ---------------------------
    1         38       0
    2         93       0
    3         93       0
    4         38       0
    5         38       0
    6        113       0
    7        124       0
    8         38       0
    9          3       0
    A        180       0
    B         93       0
    C         93       0
    D         93       0
    E          8       0
    F          0       0
    G        124       0

That's all for now... several bytes are still not clear. If you can tell me
something about them, please do.