Советы по поддержке нескольких экранов в 2D игре opengl?

#android #opengl-es #image-scaling

#Android #opengl-es #масштабирование изображения

Вопрос:

Вопрос о поддержке нескольких экранов был задан до смерти, но я не видел большого обсуждения в отношении разработки игры (с хитбоксами, проверкой столкновений и т.д.).

В настоящее время моя игра работает в «режиме совместимости», что приводит к очень плохому отображению на устройствах более высокого класса из-за масштабирования. Я ищу советы и рекомендации о том, что сделали другие, чтобы графика в их играх хорошо смотрелась на экранах всех размеров.

Включают ли разработчики по 2 копии каждого ресурса (средней и высокой плотности) или ресурсы высокой плотности просто уменьшены для устройств с меньшей плотностью?

Используются ли в ваших расчетах пиксели, не зависящие от плотности?

Ответ №1:

Включают ли разработчики по 2 копии каждого ресурса (средней и высокой плотности) или ресурсы высокой плотности просто уменьшены для устройств с меньшей плотностью?

Это один из способов справиться с ситуацией, я видел, как делается следующее:

  1. Включите растровые изображения для каждого разрешения, которое вы хотите поддерживать
  2. Включите растровые изображения для самого высокого разрешения, которое вы хотите поддерживать, и уменьшите масштаб для других разрешений.
    • Если вы используете таблицу листов (т. Е. несколько маленьких растровых изображений в более крупном растровом изображении), вам нужно быть осторожным с билинейной фильтрацией, то есть смешиванием граничных пикселей со смежными ресурсами. Если это произойдет, вы получите строки / артефакты в своих активах. Здесь есть обсуждение: http://developer.anscamobile.com/forum/2011/06/03/lines-between-my-tiles что касается этой проблемы.
  3. Используйте векторную графику для получения самого высокого разрешения, которое вы хотите поддерживать.

При использовании метода 2. или 3. вот как я с этим справляюсь:

  • Создавайте ресурсы, ориентированные на размер экрана 960 x 1600.
  • 480 x 800 — масштаб вдвое
  • 320 x 400 — масштабирование на треть

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

Я предпочитаю метод 3.

В настоящее время я работаю над изометрическим 2d игровым движком, который загружает ресурсы .svg с диска, а затем «превращает их в растровое изображение» во время «загрузки» части этапа. Делая это, я получаю преимущества небольшого размера на диске (.svg) и более высокой производительности (растровые изображения) при запуске моей игры.

Рабочий процесс заключается в следующем:

  1. Проанализируйте необходимый игровой ресурс для уровня
  2. Загрузите связанный svg-ресурс с диска
  3. Нарисуйте содержимое .svg в виде растрового изображения
  4. Выбросьте загруженный файл .svg
  5. Повторите для всех ресурсов
  6. Начальный уровень

Используются ли в ваших расчетах пиксели, не зависящие от плотности?

Да, я использую его следующим образом:

 sprite.x = new_x_position * screen_density;
  

Ответ №2:

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