Производительность Bad SpriteBatch при рендеринге tilemap [LibGDX]

Question

Итак, я создаю tilemap (просто двумерный массив с MapTiles), называемый WorldGeneration, используя класс изометрического рендеринга, который я создал. Используемая камера использует 64 пикселя на метр, поэтому ее высота, например, равна: (высота окна игры)/64. SpriteBatch, используемый в изометрическом рендерере, имеет матрицу проекций, установленную для этой камеры. (batch.setProjectionMatrix (cam.combined)

Проблема заключается в том, что при рендеринге текстур на этом SpriteBatch возникает ужасная производительность. Я не уверен, вызвана ли она матрицей проекции тем, чем она является (требуется масштабирование мои 64x64 текстуры до 1x1 в размерах партии) или что-то еще.

Я пробовал запустить программу, не выполняя вызов batch.draw в рендерере (см. код ниже), и все работает нормально. проблема или дать мне несколько советов

Соответствующие фрагменты кода:?

метод визуализации изометрической визуализатора:

public void render(WorldGeneration gen) { 
    //TODO compensate for elevation 
    int x1 = (int) (cameraIso.x - 23); // TODO compensate for zoom 
    int x2 = (int) (cameraIso.x + 23); 
    int y1 = (int) (cameraIso.y - 23); 
    int y2 = (int) (cameraIso.y + 23); 

    if(x1 < 0){ 
     x1 = 0; 
    }else if(x1 >= gen.getLengthX()){ 
     x1 = gen.getLengthX() - 1; 
    } 

    if(y1 < 0){ 
     y1 = 0; 
    }else if(y1 >= gen.getLengthY()){ 
     y1 = gen.getLengthY() - 1; 
    } 

    if(x2 < 0){ 
     x2 = 0; 
    }else if(x2 >= gen.getLengthX()){ 
     x2 = gen.getLengthX() - 1; 
    } 

    if(y2 < 0){ 
     y2 = 0; 
    }else if(y2 >= gen.getLengthY()){ 
     y2 = gen.getLengthY() - 1; 
    } 

    batch.begin(); 
    for (int x = x2; x >= x1; x--) { 
     for (int y = y2; y >= y1; y--) { 
      tiles = gen.getTiles(x, y); 
      if(tiles == null){ 
       continue; 
      }else if(tiles.size <= 0){ 
       continue; 
      } 
      for(MapTile tile: tiles){ 
       if(tile.getOpacity() < 1){ 
        batch.setColor(batchColor.r, batchColor.g, batchColor.b, tile.getOpacity()); 
       }else{ 
        batch.setColor(batchColor.r, batchColor.g, batchColor.b, 1); 
       } 
       //TODO only visible (not underneath several tiles) 
       pos.x = x; 
       pos.y = y; 

       //As you can see the texture is scaled to 1x1 because of batch: 
       batch.draw(textures[tile.getId()], translateCartToIso(pos).x, 
         translateCartToIso(pos).y + tile.getZ(), 1f, 1f); 

      } 
     } 
    } 
    batch.end(); 
} 

Как вы можете видеть, я даже создал поз Vector2 вне метода визуализации для повышения производительности, но я не уверен, что это даже необходимо. Также стоит отметить, что плитки блокируются сеткой xy, но их значение z не является, поэтому массив необходим.

Редактировать: Каким-то образом производительность отличная, если камера уменьшена, понятия не имею, почему это так. Это определенно имеет отношение к размерам камеры.

Answer 1

Я не совсем уверен во всем, что делает ваш код, но похоже, что самый внешний цикл имеет время автономной работы O (56), внутренний цикл цикла имеет другое время выполнения O (56), а затем самый внутренний foreach loop имеет время автономной работы O (# элементов в плитке>), что дает вам общее количество: около 3000 обратных вызовов, при условии, что один элемент в плитки.

Это уже довольно немного рисунка, не говоря уже о масштабировании снижения производительности, которое часто можно придать. Невозможно ли это оптимизировать?

Answer 2

Нашел ответ, на самом деле это было связано с графикой за всем. Я заметил, что когда я проводил стресс-тесты, мой компьютер (mac) закрывался из-за проблемы с графикой.

В основном это дошло до этой строки: cfg.useHDPI = true;

Где я сделал мое использование LwjglApplicationConfiguration HD пикселей, я предполагаю, что мой компьютер не может справиться с этим, когда он должен был обрабатывать слишком много HD пикселей (именно поэтому он работал, когда я увеличенной камерой вне, меньше пикселей)

Наверное, сейчас мне придется иметь дело с некоторыми искаженными пикселями, это проблема, которую мне придется решать позже!