#android #opengl-es #image-scaling
#Android #opengl-es #масштабирование изображения
Вопрос:
Вопрос о поддержке нескольких экранов был задан до смерти, но я не видел большого обсуждения в отношении разработки игры (с хитбоксами, проверкой столкновений и т.д.).
В настоящее время моя игра работает в «режиме совместимости», что приводит к очень плохому отображению на устройствах более высокого класса из-за масштабирования. Я ищу советы и рекомендации о том, что сделали другие, чтобы графика в их играх хорошо смотрелась на экранах всех размеров.
Включают ли разработчики по 2 копии каждого ресурса (средней и высокой плотности) или ресурсы высокой плотности просто уменьшены для устройств с меньшей плотностью?
Используются ли в ваших расчетах пиксели, не зависящие от плотности?
Ответ №1:
Включают ли разработчики по 2 копии каждого ресурса (средней и высокой плотности) или ресурсы высокой плотности просто уменьшены для устройств с меньшей плотностью?
Это один из способов справиться с ситуацией, я видел, как делается следующее:
- Включите растровые изображения для каждого разрешения, которое вы хотите поддерживать
- Включите растровые изображения для самого высокого разрешения, которое вы хотите поддерживать, и уменьшите масштаб для других разрешений.
- Если вы используете таблицу листов (т. Е. несколько маленьких растровых изображений в более крупном растровом изображении), вам нужно быть осторожным с билинейной фильтрацией, то есть смешиванием граничных пикселей со смежными ресурсами. Если это произойдет, вы получите строки / артефакты в своих активах. Здесь есть обсуждение: http://developer.anscamobile.com/forum/2011/06/03/lines-between-my-tiles что касается этой проблемы.
- Используйте векторную графику для получения самого высокого разрешения, которое вы хотите поддерживать.
При использовании метода 2. или 3. вот как я с этим справляюсь:
- Создавайте ресурсы, ориентированные на размер экрана 960 x 1600.
- 480 x 800 — масштаб вдвое
- 320 x 400 — масштабирование на треть
Это дает мне значение плотности экрана, которое мне нужно для будущих вычислений.
Я предпочитаю метод 3.
В настоящее время я работаю над изометрическим 2d игровым движком, который загружает ресурсы .svg с диска, а затем «превращает их в растровое изображение» во время «загрузки» части этапа. Делая это, я получаю преимущества небольшого размера на диске (.svg) и более высокой производительности (растровые изображения) при запуске моей игры.
Рабочий процесс заключается в следующем:
- Проанализируйте необходимый игровой ресурс для уровня
- Загрузите связанный svg-ресурс с диска
- Нарисуйте содержимое .svg в виде растрового изображения
- Выбросьте загруженный файл .svg
- Повторите для всех ресурсов
- Начальный уровень
Используются ли в ваших расчетах пиксели, не зависящие от плотности?
Да, я использую его следующим образом:
sprite.x = new_x_position * screen_density;
Ответ №2:
Многие разработчики включают две копии ресурсов или загружают копии с высоким разрешением при первом запуске. Если они загружаются при первом запуске, значит, они не используют для них диспетчер ресурсов Android.