Outpost 2 のファイル形式 · bei.pm

Outpost 2で使用されるデータ形式は、JFIFやPNGに似た構造を持っています。各データブロックには常に8バイトのヘッダーがあります。そのため、各ヘッダーを特定の場所で文書化するのは省略し、そこでは異常のみを文書化します。

フォーマットは常に以下の通りです。その中に実際のデータが埋め込まれています：

ボリュームは、ゲームのためのデータコンテナで、アーカイブ形式のようなものです。例えば、タールボールのように。 少なくともアウトポスト2では、この形式はファイルだけを扱い、フォルダーはありません。 ただし、適切なファイル名を使うことで、これを模倣することができるでしょう。

ボリュームは、ボリュームヘッダーと、特定のファイルに対応するいくつかのボリュームブロックで構成されています。

「ボリューム」は、ゲームディレクトリ内の'vol'という拡張子を持つファイルです。

ボリュームヘッダーには、実際のデータは含まれていません。
これは単なるコンテナとして機能します。

ボリュームヘッダーの最初のデータにはボリューム文字列があり、その後にボリューム情報が続きます。

ボリューム文字列は、ボリューム内に含まれている ファイル名のリストです。

ボリューム情報は、ファイルに関する詳細な情報を含みます。 これは、ある意味でFAT（ファイルアロケーションテーブル）の ディレクトリエントリのようなものです。

ファイルの数は、ブロックサイズをディレクトリエントリの長さ（14バイト）で割ったものになります。

各ディレクトリエントリは、以下の構成を持っています：

ボリュームブロックは、ファイルを格納するコンテナです。 ブロック形式のため、ファイルサイズが冗長にもう一度含まれ、 その後に直接利用データが続きます。

タイルはOutpost-2特有のビットマップグラフィックフォーマットです。 それは13のタイルセット、つまり「ウェル」と呼ばれるもので構成されています (well0000.bmpからwell0012.bmpまで)、 これらはmaps.volのボリューム内にあります。

これらのタイルセット/ウェルには次のものが含まれています：

正確な実装のためには、日夜サイクルのデータをまだ処理する必要があるため、タイルを事前にレンダリングしてキャッシュしないことが推奨されます。そうしないと、非常に多くのデータが発生します。

タイルは32x32ピクセルの解像度を持つインデックス付きパレットの8bppグラフィックで、縦に配置されています。しかし、このように作成されたタイルセットには、さらに多くのものが含まれる可能性があります。

メインコンテナは2つのセクションで構成されています: head と data。

これらの情報に基づいて、標準化されたRIFF形式のパレットファイルが作成されます。正確な仕様は、パレットが他の場所にも存在するため、パレットの下にあります。

最後に、左上から右下に向かって行ごとに並んだ生のピクセルデータが続きます。
通常8bppビットマップとして存在するグラフィックのデータ値は、カラーパレット内の色のインデックスに対応しています。

ゲームエンジンはタイルを*おそらく*オンデマンドで描画します。
これは32段階のタイルがある昼夜サイクルに起因しているようです。その際、明るさの値から「少し」引かれているようです。正確な値はまだ特定できていませんが、計算の基準は

v *= (daylight / 48) + 0.25;

で、HSVデータを使ったピクセルの計算を行っています。ここで、daylightは0から31の値で、vは0から1の値です。さらに、マップの左右にはそれぞれ16タイルの境界が存在し（これはユニットの見えないスポーンに役立ちます）、その点も考慮する必要があります。

加えて、昼夜サイクルはゲームサイクルごとにマップの一列だけを更新するようです。
加速された昼夜サイクルは以下のようになります：

PRTが正確に何を意味するのかはわかりませんが、例えば 'パレットとリソーステーブル' のようなことが考えられます。このファイルは op2_art.prt として maps.vol に存在し、まさにそのようなものであり、この機能をよく説明していると思います。

このファイルにはパレットのリスト、使用されているビットマップのテーブル、すべてのアニメーション定義、そしていくつかの不明なデータが含まれています。データはこれまでのコンテナ形式に緩やかに従っており、すべてのデータセットがこのスキーマに従っているわけではありません。

CPALセクション（おそらくパレットコンテナを意味する）は、通常1052バイトの8ビットパレットの数を示すことによって、パレットデータだけを囲んでいます。

1052バイトの指定は必ずしも厳密ではなく、パレット形式は潜在的に異なるパレットサイズを考慮する可能性があります。これは、Outpost 2が配布されるデータセットにのみ適用されます。

パレットリストの後には、すぐに前置きのヘッダーなしでビットマップのリストが続き、その後すぐにアニメーションリストが続きます。
どちらも、それぞれ< i>uint(32)（または再びuint24+uint8フラグ？）で始まり、データセットの数を含んでいます。

パレット情報は非常に読みやすいです。
それぞれヘッダーとデータセグメントで構成されています。

データセクションは各パレットエントリを受け取ります。 パレットエントリの数はブロックの長さを4で割ったものから決まります。

各エントリは以下のようなシンプルな構造を持っています；

パレットについては、アニメーション用のパレットには以下のルールが適用されることを付け加えます：

• 最初の色は常に透明であり、そこに指定されている値に関係なくそうです。
• パレットのエントリ1-24は、パレット1-8でプレイヤーの色として扱われます。
  プレイヤー1以外の色がどこから来ているのかは不明です。
  残りの色はハードコーディングされていると思われます。

このPRTファイルのデータ構造は、スプライトに使用されるビットマップの構成を示しています。これらのビットマップは、スプライトのアニメーションフレームを構成するための単一の要素として機能します。

具体的な画像データは、ゲームディレクトリ内の op2_art.BMPに隠れています。
なぜこのビットマップファイルが（主に正しい）RIFFビットマップヘッダーを持っているのかは不明です。おそらく、Outpost 2はグラフィックを読み込むためにシステムAPIを使用しており、このヘッダーが一時的に取得され、対応する変化するフィールドが上書きされています。

ピクセルデータは、BMPファイルの オフセット + uint32オフセットの位置にあり、 BMPファイルのアドレス0x000A（RIFFビットマップデータオフセット）に見つかります。これは再び、左上から右下への行単位の配置に対応します。

モノクロ1bppグラフィックは、色0が完全な透明で、色1が半透明の黒/灰色として描画されることがあります。モノクログラフィックは、アニメーション内の車両および建物の影に通常使用されます。

これにより、多くのグラフィックを組み合わせることができます。

さて、Outpost 2のデータフォーマットの中で最も重要な分野に来ました:
アニメーションです。

アニメーションリストは、主にデータの検証のためのグローバルヘッダーで始まります。 その後、具体的なアニメーション定義が3つの段階に分かれて続きます:

1. アニメーション
   アニメーションとは、ユニット、建物、または「パーティクルアニメーション」（彗星の衝突、天候、爆発）を特定の状況で表す最上位のインスタンスです。
2. フレーム
   フレームとは、アニメーション内の1つの画像です。アニメーションには1つ以上のフレームが含まれることがあります。
3. サブフレーム
   サブフレームとは、特定のビットマップを特定の条件でフレームの特定の位置に描画する情報です。フレームには1つ以上のサブフレームが含まれることがあります。

その後、すぐに各アニメーション定義が続きます。

最上層のデータ、アニメーションのデータは主に管理データです - バウンディングボックスは、車両や建物を選択した際のマークの座標を示し、 同時にクリック可能な領域も示します。

オフセットは主に「ゼロポイント」を決定します；ゲーム内の座標に対して加算または減算される点です。 数学的に言うと、オフセットはここで座標の原点を示します。

ウィンドウは、オフセットと同様に、それぞれのウィンドウに対して4つのuint(32)値を持ち、 それにより個々のサブフレームに使用可能な領域を指定します。ビットマップに適切に指定されている限り、 ウィンドウの外側には描画してはいけません。

これにより、個々のフレームや完全なアニメーションを組み合わせることができ、ここではインデックス 500 の複雑なアニメーションを例に示します。

アニメーション500は、通常の鉱石を積んだプリマスのトランスポーターが荷降ろしされる様子を示しています。このアニメーションは、ウィンドウ機能を利用した数少ないアニメーションの一つです。

これで完全なアニメーションを組み合わせることができます。
残念ながら、上の荷物のハッチには問題があり、グラフィックタイプ情報に対応するビットが設定されていません。

ここに、ゲームからの他の美しいアニメーションスプライトをいくつか紹介します：

今、ゲームのユーザーインターフェースが必要です。これはブラッシュメタルの外観になっています。

しかし、ここでもDynamixは新しいものを考え出す必要はなかったことがわかります。ここでは、Windowsが提供するUser32およびGDI32 APIを単に利用しているだけでなく、特にUser32のリソース管理も使用されています。

これらのリソースは、Angus Johnsonによってフリーウェアとして開発されたResource Hackerのようなプログラムを使って抽出することができます。また、LinuxやMac OSでWineを使いたくない場合は、icoutilsに含まれているwrestoolを利用することもできます。