我们如何解决2D游戏中大视频存储需求？

我们如何解决2D游戏中大视频存储需求？

我们正在开发使用Allegro C / C ++的2D游戏（Factorio），并且随着游戏内容的增加，我们面临视频存储需求增加的问题。

目前，我们收集了有关将首先使用的图像的所有信息，尽可能地裁剪所有这些图像，并尽可能紧密地将它们组织成大图册。这些地图集存储在视频内存中，视频内存的大小取决于系统限制。目前，它通常是2张图像，最高可达8192x8192，因此它们需要256Mb至512Mb的视频内存。

这个系统对我们来说非常不错，因为通过一些自定义优化以及拆分渲染和更新线程，我们能够以60 fps的速度在屏幕上绘制成千上万的图像。我们在屏幕上有许多对象，因此允许大缩放是一项关键要求。由于我们要添加更多内容，因此视频内存要求会出现一些问题，因此该系统无法容纳。

我们想要尝试的一件事是拥有一张包含最常见图像的地图集，而第二幅则作为缓存。图像将根据需要从内存位图移到那里。这种方法有两个问题：

1. 从内存位图到视频位图的绘制速度非常缓慢。
2. 在Allegro中，除了主线程之外，无法使用视频位图，因此实际上是不可用的。

这是我们还有的一些其他要求：

• 游戏必须是确定性的，因此性能问题/加载时间永远不能改变游戏状态。
• 游戏是实时的，并且很快也会成为多人游戏。我们需要不惜一切代价避免甚至最小的结结巴。
• 游戏的大部分是一个连续的开放世界。

该测试包括批量绘制1万个精灵，大小从1x1到300x300，每种配置几次。我在Nvidia Geforce GTX 760上进行了测试。

• 当源位图在各个位图之间没有变化时（图集变体），视频位图到视频位图的绘制每个子图花费0.1us。大小没关系
• 视频位图到视频位图图形，而源位图在图形之间切换（非图集变体），每个子图形花费0.56us；大小也没关系。
• 内存位图到视频位图的绘制确实令人怀疑。从1x1到200x200的大小每个位图要花0.3us，所以速度并不是那么慢。对于较大的尺寸，时间开始急剧增加，201x201的时间为9us，291x291的时间为3116us。

使用Atlas可将性能提高5倍以上。如果我有10ms的渲染时间，则使用Atlas将每帧限制为100000个精灵，如果没有它，则限制为20000个精灵。这将是有问题的。

我还试图找到一种方法来测试阴影的位图压缩和1bpp位图格式，但是我无法找到在Allegro中执行此操作的方法。

我们的RTS（KaM Remake）也有类似情况。所有单位和房屋都是精灵。我们为单位，房屋和地形提供了18 000个精灵，另外为团队颜色提供了约6000个（用作蒙版）。经过长时间拉伸，我们在字体中还使用了约3万个字符。

因此，针对您使用的RGBA32地图集进行了一些优化：

• 首先将子画面池分成许多较小的地图集，并按其他答案所述按需使用它们。这还允许针对每个地图集分别使用不同的优化技术。我怀疑您会少浪费一些RAM，因为打包成如此大的纹理时，通常在底部有未使用的区域；

• 尝试使用调色板纹理。如果使用着色器，则可以在着色器代码中“应用”调色板。

• 您可能会考虑添加使用RGB5_A1而不是RGBA8的选项（例如，如果棋盘阴影适​​合您的游戏）。尽可能避免使用8位Alpha，并使用RGB5_A1或精度较低的等效格式（如RGBA4），它们占用一半的空间；

• 确保将精灵紧密地包装到地图集中（请参阅Bin Packing算法），在必要时旋转精灵，并查看是否可以重叠菱形精灵的透明角；

• 您可以尝试使用硬件压缩格式（DXT，S3TC等）-它们可以大大减少RAM的使用，但可以检查压缩伪像-在某些图像上，差异可能并不明显（您可以如第一个要点所述选择性地使用它），但在某些方面-非常明显。不同的压缩格式会导致不同的失真，因此您可能会选择最适合您的艺术风格的失真。

• 研究将大精灵（当然不是手动，而是在纹理地图集打包程序中）拆分为静态背景精灵和用于动画零件的较小精灵。

首先，您需要使用更多，更小的纹理图集。您拥有的纹理越少，存储管理就越困难和严格。我建议地图集的大小为1024，在这种情况下，您将拥有128个纹理而不是2，或者在2048中将拥有32个纹理，可以根据需要加载和卸载。

大多数游戏通过具有级别边界来进行资源管理，而显示加载屏幕时，将卸载下一级不再需要的所有资源，并加载需要的资源。

另一种选择是按需加载，如果不需要级别边界或什至单个级别太大而无法容纳到内存中，则按需加载是必需的。在这种情况下，游戏将尝试预测玩家将来会看到什么并将其加载到后台。（例如：当前距离播放器2个屏幕的东西。）同时，不再使用了较长时间的东西也将被卸载。

但是，有一个问题，当游戏无法预见的意外事件发生时会发生什么？

• 惊慌并显示一个加载屏幕，直到所有必需的东西都加载完毕。这可能会破坏体验。
• 对于预加载的所有内容都具有低分辨率精灵，继续游戏并在高分辨率精灵完成加载后立即替换它们。对玩家来说，这看起来很便宜。
• 使其影响游戏玩法，并在必要时延迟事件。例如，在加载图形之前不要生成该敌人。在加载该战利品的所有图形之前，请勿打开宝藏箱，等等。

哇，我想是从3D模型生成的大量动画精灵？

您真的不应该在原始2D模式下制作这款游戏​​。有了固定的视角，就会发生一件有趣的事情，您可以将预先渲染的精灵和背景与实时渲染的3D模型无缝地混合在一起，而这些3D模型在某些游戏中已经大量使用。如果您想要如此精美的动画，那似乎是最自然的方式。获取一个3D引擎，对其进行配置以使用等轴测透视图，然后将继续使用精灵的对象渲染为带有图像的简单平面。您可以将纹理压缩与3D引擎一起使用，这仅是向前迈出的一大步。

我认为加载和卸载对您没有多大帮助，因为您可以同时在屏幕上显示几乎所有内容。

首先，找到最有效的纹理格式，同时仍然对游戏的视觉效果感到满意，无论是RGBA4444还是DXT压缩等。如果您对DXT alpha压缩图像中生成的伪像不满意，是否可行？使图像不透明，使用DXT1压缩的颜色结合alpha的4或8位灰度蒙版纹理？我想您会在RGBA8888上使用GUI。

我主张使用您决定的任何格式将其分解为较小的纹理。确定始终在屏幕上并因此始终加载的项目，这可能是地形和GUI地图集。然后，我将尽可能多地分解通常一起渲染的其余项目。我不认为即使在PC上进行多达50-100次抽奖，您也不会损失太多性能，但是如果我错了，请纠正我。

下一步将是生成这些纹理的Mipmap版本，如上文所述。我不会将它们存储在单个文件中，而是分开存储。因此，您最终将获得每个文件的1024x1024、512x512、256x256等版本，而我将执行此操作，直到达到我想显示的最低详细级别为止。

现在，您已经拥有了单独的纹理，您可以构建一个详细程度（LOD）系统，该系统为当前缩放级别加载纹理，并在未使用时卸载纹理。如果要渲染的项目不在屏幕上或当前缩放级别不需要，则不使用纹理。尝试将纹理加载到与更新/渲染线程分开的线程中的视频RAM中。您可以显示最低的LOD纹理，直到加载所需的纹理。有时这可能会导致低细节/高细节纹理之间的可见切换，但是我想这只有在您在地图上移动时执行极快的缩小和放大时才会发生。通过尝试预加载您认为该人将在当前内存限制内尽可能多地移动或缩放并加载的位置，可以使系统智能化。

我会测试一下是否有帮助。我想获得极端的缩放级别，您将不可避免地需要一个LOD系统。

我相信最好的方法是将纹理分割成许多文件并按需加载。可能是您的问题是您正在尝试加载较大的纹理，而这些纹理是完整3D场景所需的，而您正在为此使用Allegro。

对于要应用的大缩小，必须使用mipmap。Mipmap是纹理的较低分辨率版本，当对象离相机足够远时使用。这意味着您可以将8192x8192保存为4096x4096，然后另存为2048x2048，依此类推，如果您在屏幕上看到的精灵越小，则切换到较低的分辨率。您既可以将它们保存为单独的纹理，也可以在加载时调整它们的大小（但是在运行时生成Mipmap会增加游戏的加载时间）。

适当的管理系统会按需加载所需文件，并在没人使用文件时以及其他情况下释放资源。资源管理是游戏开发中的重要主题，您正在将管理简化为映射到单个纹理的简单坐标，这几乎完全没有管理。

我建议创建更多的地图集文件，这些文件可以使用zlib压缩并从每个地图集的压缩流中流出，并且通过拥有更多的地图集文件和更小尺寸的文件，您可以限制视频内存中活动图像数据的数量。此外，请实现三重缓冲机制，以便您更快地准备每个并条机，并有机会更快地完成装帧，从而使装配件不会出现在屏幕上。