Outpost 2 File Formats · bei.pm

The data formats used by Outpost 2 have a structure reminiscent of JFIF/PNG - each data block always has an 8-byte header. Therefore, I will refrain from documenting the individual headers at the respective specific points and will only document deviations there.

The format is always as follows; the actual payload is then embedded within it:

The volumes are a data container for the game, similar to an archive format like a tarball. At least in Outpost 2, the format recognises only files - no folders. However, these could probably be simulated through appropriate filenames.

A volume consists of the volume header as well as several volume blocks that correspond to the actual files.

"Volumes" are the files with the extension 'vol' in the game directory.

The Volume Header does not contain any user data.
It serves merely as a container.

The first entry in the Volume Header should be the Volume Strings, followed by the Volume Information.

The volume strings refer to a list of file names that are contained within the volume.

The volume information contains more detailed information about the files. In a way, it is a sort of FAT directory entry (FAT = File Allocation Table).

The number of files is determined by dividing the block size by the length of the directory entries - 14 bytes.

The individual directory entries each have the following structure:

A volume block is a container that holds files. It contains the file size redundantly once more - due to the block format - and is directly followed by the actual data.

The tiles are a Bitmap graphic format specific to Outpost-2. They span 13 tilesets, referred to as "wells" (well0000.bmp to well0012.bmp), which are located within the volume maps.vol.

The tilesets / wells contain the following:

It is advisable for an accurate implementation not to render the tiles in advance for caching purposes, as the data for the day/night cycle still needs to be processed - and an enormous amount of data would accumulate.

The tiles are 8bpp graphics with an indexed palette, each with a resolution of 32x32 pixels, which are arranged in a grid. However, a tileset created in this way can accommodate far more.

The main container consists of 2 sections: head and data.

Following this information, there will be a palette file available in the standardised RIFF format. The exact specification can be found - as the palettes appear elsewhere as well - under Palettes.

Finally, the raw pixel data follows, line by line from the top left to the bottom right.
The data value for graphics, which are usually in 8bpp bitmap format, corresponds to the index of the colour in the colour palette.

The game engine likely renders the tiles *on demand*.
This seems to be partly due to the day-night cycle, which has 32 gradations of individual tiles. It appears that a 'little' is subtracted from the brightness value. Exact values have not yet been determined; I am working on the calculation basis

v *= (daylight / 48) + 0.25;

using the HSV data of the pixels, where daylight is a value from 0-31 and v is a value between 0-1. Furthermore, it should be noted that there is an additional margin of 16 tiles on each side of the map (which serves the invisible spawning of units).

Additionally, the day-night cycle only updates one column of the map per game cycle.
A sped-up day-night cycle therefore looks as follows:

I am not sure what PRT stands for; one possibility might be 'Palette and Resource Table' - as this file, found as op2_art.prt in maps.vol, pertains to such a concept, or this would describe its function quite well.

This file contains a list of palettes, a table of all used bitmaps, all animation definitions, and a number of unknown data. It loosely follows the previous container format, as not all records adhere to this schema.

The CPAL section (likely stands for Palette Container) encompasses only the palette data, indicating how many of the typically 1052-byte large 8-bit palettes are present.

The 1052-byte specification is not considered binding, as the palette format could potentially allow for different palette sizes. It only applies to the data set supplied with Outpost 2.

Following the palette lists, the bitmap list immediately follows without an introductory header; likewise, the animation lists follow directly after.
Both are each preceded by a uint(32) (or possibly uint24 + uint8 flags?) that contains the number of records.

The palette information is very straightforward to read.
It consists of a header and a data segment.

The data section includes the individual pallet entries. The number of pallet entries is determined by the block length / 4.

The individual entries have the following simple structure;

Regarding the palettes, it can additionally be said that the following rules apply to palettes used for animations:

• The first colour is ALWAYS transparent, regardless of what value is specified there.
• Palette entries 1-24 are to be considered as player colours in palettes 1-8.
  Where the colours, apart from player 1, originate from is unclear to me.
  I suspect that the remaining colours are hardcoded.

This data structure of the PRT file specifies how the bitmaps used for the sprites are constructed. These bitmaps serve as individual components, from which several are assembled into an animation frame of a sprite.

The actual image data, on the other hand, is hidden in the op2_art.BMP in the game directory.
It is unclear why this bitmap file has a (mostly correct) RIFF bitmap header. It is likely that Outpost 2 uses system APIs to load the graphics by temporarily adopting this header and overwriting the relevant, varying fields.

The pixel data can be found in the BMP file at the position Offset + the uint32-offset, which can be found at address 0x000A in the BMP file (RIFF bitmap data offset), and again corresponds to the row-wise arrangement from the top left to the bottom right.

Monochrome 1bpp graphics can be drawn in such a way that colour 0 represents complete transparency, while colour 1 is a semi-transparent black/grey, as monochrome graphics are typically used for vehicle and building shadows in the animations.

This allows for a considerable amount of graphics to be assembled.

Now we come to the pinnacle of the disciplines within the Outpost 2 data formats:
The animations.

The animation lists begin with a global header, primarily serving data verification. Following this are the specific animation definitions, which are divided into three levels:

1. Animation
   An animation is the highest instance; it represents the animation of a unit, a building, or a 'particle animation' (meteor impact, weather, explosion) in a specific starting condition.
2. Frame
   A frame is a single image within an animation. An animation can contain one or more frames.
3. Subframe
   A subframe is the information indicating that a specific bitmap should be drawn at a particular position of a frame under certain criteria. A frame can contain one or more subframes.

Next, we will directly follow with the individual animation definitions.

The data from the top layer, the animation, primarily consists of administrative data - the Bounding box refers to the coordinates of the marker around the vehicle/building when it is selected and also indicates which area should be clickable.

The offset primarily determines the "zero point"; the point that needs to be added to or subtracted from the in-game coordinates. One could also say mathematically: the offset here refers to the origin of the coordinates.

The windows consist, just like the offset, of 4 uint(32) values per window, which specify an area that is considered usable for individual subframes. Drawing is not permitted outside the windows, unless it is specifically designated for the bitmap.

With this, we can now compose individual frames as well as complete animations accordingly, demonstrated here with a more complex animation, the animation with index 500.

Animation 500 shows how a Plymouth transporter, loaded with ordinary ore, is unloaded. This is one of the few animations that utilise the windowing functionality.

And so the complete animation can be assembled.
Unfortunately, there is still an issue with the upper loading hatch, as the corresponding bit in the graphic type information is not set.

Here are a few more beautifully animated sprites from the game:

Now, what remains is the user interface of the game, which features a brushed metal look.

However, it is also evident that Dynamix did not need to reinvent the wheel; they are simply utilising the User32 and GDI32 APIs provided by Windows—particularly, they are employing the resource management capabilities of User32.

These can be extracted, for example, using programs such as Resource Hacker, developed as freeware by Angus Johnson, or - if one is hesitant to use Wine on Linux / Mac OS - with the wrestool included in icoutils.