Outpost 2 文件格式 · bei.pm

Outpost 2使用的数据格式具有类似于JFIF / PNG的结构 - 每个数据块都有一个8字节的头部。因此，我省略了在相应特定位置记录每个头部的细节，只记录偏差。

格式始终是以下内容；实际的有效数据嵌入其中：

卷是游戏的数据容器，类似于档案格式，如 Tarball。 至少在 Outpost 2 中，该格式仅包含文件——没有文件夹。 不过，这些可能可以通过相应的文件名来模拟。

一个卷由卷头和多个卷块组成，这些卷块对应具体的文件。

“卷”是游戏目录中以 'vol' 结尾的文件。

卷头本身不包含任何有效数据。
它仅仅作为一个容器。

卷头中的第一个数据应该是卷字符串；接下来是卷信息。

卷字符串是一个包含在卷内的文件名列表。

卷信息包含了更详细的文件信息。在某种程度上，这是一种FAT目录项（FAT = 文件分配表）。

文件的数量是通过将块大小除以目录项的长度（14字节）得出的。

每个目录项的结构如下：

卷块是一个容器，能够容纳文件。它仅仅是由于块格式而冗余地包含了文件大小，随后紧接着是实际数据。

这些图块是针对Outpost-2的特定位图图形格式。它们分为13个图块集，称为“wells”（well0000.bmp到well0012.bmp），这些文件位于maps.vol中。

这些图块集/Wells包含以下内容：

为了准确的实现，建议不要提前渲染瓷砖以进行缓存，因为日夜循环的数据仍需处理，并且会产生大量数据。

这些瓷砖是8bpp的图形，具有32x32像素分辨率的索引调色板，并且是相互排列的。然而，在这样形成的瓷砖集中，可以有更多的内容。

主容器由两个部分组成：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交付的数据集。

在调色板列表之后，紧接着没有引导头部的位图列表；随后是动画列表。
这两者都由一个uint(32)（或者是uint24+uint8标志？）开始，包含记录的数量。

调色板信息非常容易读取。
它们通常由一个头部和一个数据段组成。

数据部分包含了各个托盘条目。 托盘条目的数量由块长度 / 4 得出。

每个条目的结构如下所示；

关于调色板，还有以下几点需要说明， 用于动画的调色板遵循以下规则：

• 第一个颜色始终是透明的，无论那里指定的值是什么。
• 调色板条目1-24在调色板1-8中作为玩家颜色使用。
  除了玩家1以外的颜色具体来源我不太清楚。
  我猜其余的颜色是硬编码的。

PRT文件的数据结构指示了用于精灵的位图是如何构建的。这些位图作为单个组件，用于组合多个精灵的动画帧。

具体的图像数据则隐藏在游戏目录中的 op2_art.BMP文件中。
为什么这个位图文件具有一个（大部分情况下正确的）RIFF位图头目前尚不清楚。Outpost 2可能使用系统API加载图形，暂时采用该头并覆盖相应的可变字段。

像素数据在BMP文件中的位置是 Offset + uint32-Offset， 这个Offset可以在BMP文件的地址0x000A找到（RIFF位图数据偏移），并且是从左上角到右下角的逐行排列。

单色1bpp图形可以被绘制成： 颜色0表示完全透明，而颜色1表示半透明的黑色/灰色，因为单色图形通常用于动画中的车辆和建筑阴影。

因此，可以组合许多图形。

现在我们来到了Outpost 2数据格式中最高级别的学科：
动画。

动画列表以一个全球头部开始，该头部主要用于数据验证。 随后是具体的动画定义，这些定义分为3个层次：

1. 动画
   动画是最高级别的实例；它表示单位、建筑或“粒子动画”（陨石撞击、天气、爆炸）在特定起始状态下的动画。
2. 帧
   帧是动画中的单个图像。一段动画可以包含一个或多个帧。
3. 子帧
   子帧是关于在帧的特定位置以特定条件绘制特定位图的信息。一个帧可以包含一个或多个子帧。

接下来是各个动画定义。

最高层的数据，即动画，主要是管理数据 - 边界框 指的是在选择车辆/建筑物时标记的坐标，并同时指明哪个区域可以点击。

偏移量主要确定“零点”；即需要在游戏内部坐标上进行加或减的点。可以更加数学地说：这里的偏移量指定了坐标原点。

窗口与偏移量一样，每个窗口都有4个 uint(32) 值，表示可用于单个子帧的区域。除非位图特别指定，否则不应在窗口外绘制。

这样我们就可以将单个帧以及完整的动画进行组合，下面以索引 500 的复杂动画为例进行演示。

动画500展示了如何卸载一辆装载普通矿石的普利茅斯运输车。这是少数利用窗口功能的动画之一。

因此，完整的动画可以组合在一起。
遗憾的是，上方的装载舱门仍然存在问题，因为在图形类型信息中没有设置相应的位。

这里还有一些游戏中的其他美丽动画精灵：

现在还缺少游戏的用户界面，采用了拉丝金属的外观设计。

但在这里也可以看出，Dynamix并不需要重新发明轮子；这里不仅仅是简单地使用了Windows提供的User32和GDI32 API，特别是还利用了User32的资源管理。

例如，可以通过Angus Johnson开发的免费软件Resource Hacker来提取这些资源，或者如果在Linux / Mac OS下不想使用Wine，可以利用icoutils中的wrestool来提取。