почему игра тормозит в libgdx?

Есть несколько лазеек, которыми мы пренебрегаем при программировании. Процессоры настольных компьютеров намного мощнее, поэтому игра может работать плавно на рабочем столе, но может замедляться на мобильном устройстве.

Вот несколько ключевых замечаний, которым вы должны следовать для оптимального игрового процесса:

1. Нет операций ввода-вывода в методе рендеринга.
2. Избегайте создания объектов в методе рендеринга.
3. Объекты должны использоваться повторно (например, если в вашей игре 1000 платформ, но на текущем экране вы можете отобразить только 3, вместо создания 1000 объектов сделайте 5 или 6 и повторно используйте их). Вы можете использовать класс Pool, предоставляемый LibGdx, для объединения объектов.
4. Старайтесь загружать только те активы, которые необходимы для отображения на текущем экране.

Попробуйте проверить свой logcat, если вызывается сборщик мусора. Если да, то попробуйте использовать метод finalize класса объекта, чтобы определить, какой объект класса собирается как мусор, и попытаться улучшить его.

Удачи.

У меня есть несколько дополнительных советов по повышению производительности:

1. Постарайтесь свести к минимуму привязки текстур (или вообще привязки, например, при создании 3D-игры) в цикле рендеринга. Используйте атласы текстур и старайтесь использовать одну текстуру после связывания как можно чаще, прежде чем связывать другой текстурный блок.
2. Не отображайте то, чего нет в области усечения/окна просмотра. Сначала вычислите, виден ли нарисованный объект активной камерой или нет. Если он не виден, просто не загружайте его на свой GPU при рендеринге!
3. Не используйте spritebatch.begin() или spritebatch.end() слишком часто в цикле рендеринга, потому что каждый раз, когда вы начинаете/завершаете его, он сбрасывается и загружается в GPU для рендеринга.
4. НЕ загружайте активы во время рендеринга, за исключением случаев, когда вы делаете это один раз в другом потоке.
5. The latest versions of libgdx also provide a GLProfiler where you can measure how many draw calls, texture bindings, vertices, etc. you have per frame. I'd strongly recommend this since there always can be situations where you would not expect an overhead of memory/computational usage.
   6. Use libgdx Poolable (interface) objects and Pool for pooling objects and minimizing the time for object creation, since the creation of objects might cause tiny but noticable stutterings in your game-render loop

Кстати, без какой-либо дополнительной информации никто не даст вам хорошего или точного ответа. Если вы считаете, что не стоит писать достаточно текста или информации для вашего вопроса, то почему стоит ответить на него?

Чтобы действительно понять, почему ваша игра работает медленно, вам нужно профилировать свое приложение.

Для этого есть бесплатные инструменты.

На рабочем столе вы можете использовать VisualVM. На Android вы можете использовать Android Monitor.

С помощью профилирования вы точно узнаете, какие методы занимают больше всего времени.

Вероятная причина подтормаживаний - привязка текстур. Вы часто переключаетесь между разными страницами упакованных текстур? Попробуйте нарисовать все с одной страницы, прежде чем переключаться на другую страницу.

Ответ, вероятно, немного больше, чем просто «Компьютер быстрый, телефон медленный». Скорее, важно отметить, что виртуальная машина Java вашего компьютера, скорее всего, является очень хорошо оптимизированной JVM Oracle, в то время как виртуальная машина Java вашего телефона, вероятно, является Dalvik, которая, не говоря уже о ее производительности, не имеет такой же оптимизации для создания объектов и управления ими.

Как уже говорили другие, libGDX предоставляет класс Pool именно по этой причине. Посмотрите здесь: https://github.com/libgdx/libgdx/wiki/Memory-management

Одна очень важная вещь в LibGDX заключается в том, что вы должны убедиться, что иногда загрузка ресурсов из памяти не может происходить в методе render(). Убедитесь, что вы загружаете активы в нужное время, и они не появляются в методе рендеринга.

Еще одна очень важная вещь заключается в том, что постарайтесь рассчитать свои математические расчеты и сделать их независимыми от рендеринга в том смысле, что ваш следующий кадр не должен ждать, пока произойдут вычисления...!

Это две основные вещи, с которыми я столкнулся, когда создавал учебник по игре в змей.
Спасибо,
Абхиджит.

Одна вещь, которую я обнаружил, это то, что рисование отстает. Это означает, что если вы рисуете закадровые элементы, то это использует много бесполезных ресурсов. Если вы просто проверите, отображаются ли они на экране перед рисованием, ваша производительность на удивление улучшится.

Вопросы для размышления (из личного опыта)

1. НЕ продолжайте вызывать функцию в методе рендеринга, которая обновляет что-то вроде времени, счета в HUD (выполняйте эти обновления только при необходимости, например, когда увеличивается ТОЛЬКО счет, затем обновляйте счет и т. д.)

2. Совершать звонки, ЕСЛИ конкретно (Выполнять обновления при определенных условиях, не все время), например. Вызов/обновление в методе рендеринга со скоростью 60 кадров в секунду - означает, что вы обновляете время 60 раз в секунду, когда его нужно обновлять только один раз в секунду)

Эти баллы сильно повлияют на производительность (большой палец вверх)

Вам необходимо проверить размер вашего изображения в игре. Если размер вашего изображения больше, уменьшите размер изображений, используя следующую ссылку "http://tinypng.org/". Это поможет вам.