6
我们如何解决2D游戏中大视频存储需求？
我们如何解决2D游戏中大视频存储需求？ 我们正在开发使用Allegro C / C ++的2D游戏（Factorio），并且随着游戏内容的增加，我们面临视频存储需求增加的问题。 目前，我们收集了有关将首先使用的图像的所有信息，尽可能地裁剪所有这些图像，并尽可能紧密地将它们组织成大图册。这些地图集存储在视频内存中，视频内存的大小取决于系统限制。目前，它通常是2张图像，最高可达8192x8192，因此它们需要256Mb至512Mb的视频内存。 这个系统对我们来说非常不错，因为通过一些自定义优化以及拆分渲染和更新线程，我们能够以60 fps的速度在屏幕上绘制成千上万的图像。我们在屏幕上有许多对象，因此允许大缩放是一项关键要求。由于我们要添加更多内容，因此视频内存要求会出现一些问题，因此该系统无法容纳。 我们想要尝试的一件事是拥有一张包含最常见图像的地图集，而第二幅则作为缓存。图像将根据需要从内存位图移到那里。这种方法有两个问题： 从内存位图到视频位图的绘制速度非常缓慢。 在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中执行此操作的方法。