他们是如何做到的：Terraria中的数百万块瓷砖

我一直在开发类似于Terraria的游戏引擎，这主要是一个挑战，尽管我已经弄清了其中的大部分内容，但我似乎并没有真正为它们如何处理数百万个可交互/可收割的图块而费心游戏一次完成。在我的引擎中，创建约500.000个图块，这是Terraria可能生成的图块的1/20，导致帧速率从60下降到约20，即使我仍然只在视图中渲染图块。请注意，我没有对磁贴做任何事情，只是将其保留在内存中。

更新：添加代码以显示我的操作方式。

这是类的一部分，它处理并绘制图块。我猜想罪魁祸首是“ foreach”部分，该部分会迭代所有内容，甚至是空索引。

...
    public void Draw(SpriteBatch spriteBatch, GameTime gameTime)
    {
        foreach (Tile tile in this.Tiles)
        {
            if (tile != null)
            {
                if (tile.Position.X < -this.Offset.X + 32)
                    continue;
                if (tile.Position.X > -this.Offset.X + 1024 - 48)
                    continue;
                if (tile.Position.Y < -this.Offset.Y + 32)
                    continue;
                if (tile.Position.Y > -this.Offset.Y + 768 - 48)
                    continue;
                tile.Draw(spriteBatch, gameTime);
            }
        }
    }
...

这里也是Tile.Draw方法，它也可以进行更新，因为每个Tile使用对SpriteBatch.Draw方法的四个调用。这是我的自动平铺系统的一部分，这意味着根据相邻的图块绘制每个角。texture_ *是矩形，在创建关卡时设置一次，而不是在每次更新时设置。

...
    public virtual void Draw(SpriteBatch spriteBatch, GameTime gameTime)
    {
        if (this.type == TileType.TileSet)
        {
            spriteBatch.Draw(this.texture, this.realm.Offset + this.Position, texture_tl, this.BlendColor);
            spriteBatch.Draw(this.texture, this.realm.Offset + this.Position + new Vector2(8, 0), texture_tr, this.BlendColor);
            spriteBatch.Draw(this.texture, this.realm.Offset + this.Position + new Vector2(0, 8), texture_bl, this.BlendColor);
            spriteBatch.Draw(this.texture, this.realm.Offset + this.Position + new Vector2(8, 8), texture_br, this.BlendColor);
        }
    }
...

欢迎对我的代码提出任何批评或建议。

更新：解决方案已添加。

这是最终的Level.Draw方法。Level.TileAt方法只是检查输入的值，以避免OutOfRange异常。

...
    public void Draw(SpriteBatch spriteBatch, GameTime gameTime)
    {
        Int32 startx = (Int32)Math.Floor((-this.Offset.X - 32) / 16);
        Int32 endx = (Int32)Math.Ceiling((-this.Offset.X + 1024 + 32) / 16);
        Int32 starty = (Int32)Math.Floor((-this.Offset.Y - 32) / 16);
        Int32 endy = (Int32)Math.Ceiling((-this.Offset.Y + 768 + 32) / 16);

        for (Int32 x = startx; x < endx; x += 1)
        {
            for (Int32 y = starty; y < endy; y += 1)
            {
                Tile tile = this.TileAt(x, y);
                if (tile != null)
                    tile.Draw(spriteBatch, gameTime);

            }
        }
    }
...

渲染时是否要遍历所有500,000个图块？如果是这样，那很可能会造成部分问题。如果渲染时循环遍历一百万个图块，而对它们执行“更新”勾时则遍历五十万个图块，那么每帧将遍历一百万个图块。

显然，有解决方法。您可以在渲染的同时执行更新更新，从而将遍历所有这些图块的时间节省一半。但这将您的呈现代码和更新代码绑定到一个函数中，通常是BAD IDEA。

您可以跟踪屏幕上的图块，并仅遍历（并渲染）这些图块。根据瓦片大小和屏幕大小等因素，这可以轻松减少您需要遍历的瓦片数量，从而节省大量处理时间。

最后，也许最好的选择（大多数大型世界游戏都这样做）是将地形分成多个区域。将世界划分为512x512的块，并在玩家靠近或远离某个区域时加载/卸载区域。这也使您不必遍历遥远的图块即可执行任何类型的“更新”刻度。

（很明显，如果您的引擎未在磁贴上执行任何类型的更新刻度，则可以忽略此答案中提到这些的部分。）

我在这里看到一个巨大的错误，没有任何答案可以解决。当然，您永远不应该绘制和迭代更多的图块，而您也需要。不太明显的是您如何实际定义图块。如我所见，您创建了一个tile类，我也经常这样做，但这是一个巨大的错误。您可能在该类中具有各种功能，并且创建了许多不必要的处理。

您只应迭代处理真正需要的内容。因此，请考虑您实际需要的瓷砖。要绘制'm，您只需要一个纹理，但是您不想在实际图像上进行迭代，因为要处理的图像很大。您可以只创建一个int [，]甚至是一个无符号字节[，]（如果您不希望有更多的255个图块纹理）。您需要做的就是遍历这些小数组，并使用switch或if语句绘制纹理。

那么，您需要更新什么？类型，健康状况和损害似乎足够。所有这些都可以以字节存储。那么为什么不为更新循环创建这样的结构：

struct TileUpdate
{
public byte health;
public byte type;
public byte damage;
}

您实际上可以使用该类型来绘制图块。因此，您可以从结构中分离该结构（使其自己组成一个数组），以免重复绘制循环中不必要的运行状况和损坏字段。为了进行更新，您应该考虑比屏幕更宽的区域，以便游戏世界更加活跃（实体在屏幕外更改位置），但是对于绘制事物，您只需要可见的图块即可。

如果保留上述结构，则每个图块仅占用3个字节。因此，出于保存和存储目的，这是理想的。对于处理速度，如果使用int或byte，或者如果使用64位系统，则使用long int并不重要。

您可以使用不同的编码技术。

RLE：因此，您从坐标（x，y）开始，然后计算沿着其中一个轴并排（长度）存在的相同图块的数量。示例：（1,1,10,5）表示从坐标1,1开始，有10个并排的图块类型5。

大规模数组（位图）：数组的每个元素都保留在该区域中的图块类型。

编辑：我只是在这里遇到了一个很好的问题： 地图生成的随机种子函数？

Perlin噪声发生器看起来像是一个很好的答案。

您可能应该已经按照建议对tilemap进行分区。例如，使用四叉树结构来摆脱不必要（非可见）图块的任何潜在处理（例如，甚至简单地循环通过）。这样，您仅处理可能需要处理的内容并增加数据集（平铺图）的大小不会造成任何实际的性能损失。当然，假设树平衡良好。

我不想通过重复“旧的”来听起来平淡无奇，但是在进行优化时，请始终记住使用工具链/编译器支持的优化，您应该尝试一下。是的，过早的优化是万恶之源。相信您的编译器，在大多数情况下，它比您知道的多，但始终，永远两次测量，永远不要依靠猜测。只要您不知道实际的瓶颈在哪里，就不必快速执行最快的算法。这就是为什么您应该使用探查器来查找代码中最慢的（热）路径，并专注于消除（或优化）它们的原因。对目标体系结构的低级了解通常对于挤出硬件必须提供的所有内容至关重要，因此请研究这些CPU缓存并了解分支预测器是什么。查看您的探查器告诉您有关缓存/分支命中/未命中的内容。正如使用某种形式的树数据结构所显示的那样，拥有智能数据结构和愚蠢算法要比采用其他方法更好。在性能方面，数据是第一位的。:)

难道不是所有抽奖电话太多了吗？如果将所有地图的贴图纹理放入单个图像-贴图集，则渲染时将不会切换纹理。而且，如果将所有图块批处理为一个网格，则应在一次绘制调用中绘制它。

关于动态调整...也许四叉树并不是一个坏主意。假设将瓦片放置在叶子中，并且非叶子节点只是其子对象的成批网格，则根应包含所有成一个网格的瓦片。删除一个图块需要节点更新（网格划分）直到根。但是在每个树级别上，只有1/4网格划分的网格不应该那么多，4 * tree_height网格连接吗？

哦，如果您在裁剪算法中使用这棵树，您将不总是渲染根节点，而是渲染其某些子节点，因此，您甚至不必更新/重新分批将所有节点更新为根节点，而无需更新/重新分批复制您的节点（非叶节点）目前渲染。

只是我的想法，没有代码，也许是胡说八道。

@到达是正确的。问题是抽奖代码。您正在构建每帧4 * 3000 +个绘制四边形命令（24000+个绘制多边形命令）的数组。然后，这些命令将被处理并通过管道传输到GPU。这很糟糕。

有一些解决方案。

• 将大块瓷砖（例如，屏幕尺寸）渲染为静态纹理，并在一次调用中将其绘制。
• 使用着色器绘制图块时，无需每帧将几何图形发送到GPU（即将图块图存储在GPU上）。

您需要做的是将世界划分成多个区域。Perlin噪声地形生成可以使用通用种子，因此即使世界尚未预先生成，种子也将构成噪声算法的一部分，从而将较新的地形很好地缝合到现有部分中。这样，您无需一次在玩家视图之前计算出更多的小缓冲区（当前屏幕周围只有几个屏幕）。

在处理诸如植物生长在远离播放器当前屏幕的区域中之类的事情时，您可以使用计时器。这些计时器将遍历存储有关植物及其位置等信息的文件。您只需要读取/更新/保存计时器中的文件。当玩家再次到达世界的那些地方时，引擎将正常读取文件，并在屏幕上显示较新的植物数据。

我在去年制作的类似游戏中使用了这项技术，用于收割和耕种。玩家可以离开田野，返回时，物品已更新。

我一直在思考如何处理这么多的块，而唯一想到的就是Flyweight设计模式。如果您不知道，我强烈建议您阅读以下内容：在节省内存和处理方面可能会有所帮助：http : //en.wikipedia.org/wiki/Flyweight_pattern