java - 迷宫绘图(更好的性能)libgdx

Question

在我的游戏中，我使用 ShapeRenderer 类来绘制迷宫。基本上，我使用矩形函数(在 ShapeRenderer 类中)绘制小黑线。过去，我在调试游戏性能方面没有问题(fps = 60)。但是最近，我遇到了一些性能问题。简而言之，我拿出了我在游戏中绘制的所有 Sprite 和 Actor ，并决定只绘制迷宫。每次我通过桌面启动器调试游戏时，fps 性能都会降低一半(基本上在 33、34 fps 左右)。然而，当我运行它时，它会上升到 60 fps。

我相信这清楚地表明 ShapeRenderer 类不是我绘制迷宫性能的最佳选择。我尝试过使用带有纹理 png 图像(矩形)的 spritebatch，这并没有改变任何事情。我想知道是否有更好的选择来绘制迷宫并仍然将 fps 性能保持在 60(在 Debug模式下)，或者调试游戏会使我的 fps 性能降低一半是正常的吗？

P.S: 这是我在 render 方法中绘制迷宫的代码:

for(int x = 0; x < rows; x++){
     for(int y = 0; y < columns; y++){

         if(this.grid[x][y].north.hasWall){ //NORTH BORDER LINE
             shapeRenderer.rect(22+((GENERIC_WIDTH_HEIGHT_MAZE+10)*x), 450-((GENERIC_WIDTH_HEIGHT_MAZE+10)*y), GENERIC_WIDTH_HEIGHT_MAZE+10, 0, color1, color2, color3, color4); 
         }
         if(this.grid[x][y].west.hasWall){ //WEST BORDER LINE
              shapeRenderer.rect(22+((GENERIC_WIDTH_HEIGHT_MAZE+10)*x), 450-((GENERIC_WIDTH_HEIGHT_MAZE+10)*y), 0, -GENERIC_WIDTH_HEIGHT_MAZE-10, color1, color2, color3, color4);
         }
         if(this.grid[x][y].east.hasWall){ //EAST BORDER LINE
                  shapeRenderer.rect(22+((GENERIC_WIDTH_HEIGHT_MAZE+10)*(x+1)), 450-((GENERIC_WIDTH_HEIGHT_MAZE+10)*y), 0, -GENERIC_WIDTH_HEIGHT_MAZE-10, color1, color2, color3, color4);

         }
         if(this.grid[x][y].south.hasWall){ //SOUTH BORDER LINE
              shapeRenderer.rect(22+((GENERIC_WIDTH_HEIGHT_MAZE+10)*x), 450-((GENERIC_WIDTH_HEIGHT_MAZE+10)*(y+1)), GENERIC_WIDTH_HEIGHT_MAZE+10, 0, color1, color2, color3, color4);
         }
     }
 }

如有任何见解，我们将不胜感激。是以下值:

GENERIC_WIDTH_HEIGHT_MAZE = 26 (Integer)
rows = 9
columns = 12
color1 = color2 = color3 = color4 = Color.BLACK

Answer 1

如果你运行它时渲染速度足够好，那么我就不会担心调试时的性能。

但总的来说，这看起来可以大大优化:

1. 由于它是一个迷宫，您可以通过生成“blob”显着减少绘制调用的数量。您可以连接墙壁，甚至可以使用三角形条纹来绘制整个 block 。
2. 您是否使用人脸剔除来减少 fragment 数量？ (你应该)
3. 无论如何，您很可能不需要绘制所有的墙。创建一个系统以仅查找不在其他墙后面的墙(应该很容易，因为它看起来像一个普通的二维网格)。
4. 减少冗余调用:我假设您一直在为绘制的每个矩形设置颜色等内容。尝试仅在需要更改时才这样做。
5. 迷宫很可能是静态的或很少变化。在加载时生成包含所有顶点的 GPU 缓冲区，然后继续重复使用该缓冲区以减少 GPU 的流量。

同样，这些只是您可以优化的一些提示，但我会尝试尽可能晚地优化它，并且仅在需要时才进行优化。调试速度太慢通常不是开始优化的好理由。

由于调试缓慢的原因可能有很多，您可能希望有一个系统来检查您当前的实际绘图 FPS。您可以通过将场景绘制到与屏幕大小相同的 FBO 来测试这一点，并尝试在 for(或)while 循环中继续绘制场景并测量 FPS。这使您可以粗略估计自己离极限有多近。