Главная » Программирование игр под Android » Концепция связывания вершин – РАЗРАБОТКА ИГР ДЛЯ ОС ANDROID

0

Можем ли мы еще что-то оптимизировать? Еще раз посмотрим на наш текущий метод present  (с убранными glRotatef  и gl Seal ef ):

Выглядит гораздо лучше, не правда ли? Но на самом деле метод еще не идеален. Для начала мы можем переместить вызов gl .glMatrixMode в метод resume, однако это не даст значительных улучшений. Вот что еще можно оптимизировать.

Мы используем класс Vertices для хранения и визуализации моделей Бобов. Помните метод Verti ces. draw? Вот он:

Теперь давайте снова рассмотрим предыдущий цикл. Ничего не заметили? Для каждого Боба используем одни и те же свойства вершин снова и снова с помощью glEnableClientStateO. На самом деле нам нужно всего лишь установить их один раз, поскольку каждый Боб применяет одну и ту же модель, которая всегда задействует одни и те же свойства вершин. Следующая проблема связана с вызовом gl XXXPoi nter  для каждого экземпляра Боба. Поскольку эти указатели также являются состояниями OpenGL, нам нужно установить их всего один раз, так как после установки они уже не меняются. Как мы можем это исправить? Немного перепишем метод Verti ces. draw:

Видите, что мы здесь сделали? Мы можем обращаться с нашими вершинами и другими указателями так же, как и с текстурой. Привязываем указатели вершин с помощью одного вызова Vert i ces. bi nd . С этого момента каждый вызов Verti ces. draw будет работать с этими привязанными вершинами так же, как вызов рисования всегда использует текущую привязанную текстуру. Когда мы закончили визуализацию с экземплярами класса Vertices, вызываем Vertices.unbind, чтобы отменить все свойства вершин, которые не нужны другим экземплярам класса Vertices. Целесообразно не вносить лишней информации в состояние OpenGL ES. Вот как теперь выглядит наш метод present (я также переместил вызов glMatrixMode(GL10.GL MODELVIEW) в resume):

Фактически мы вызываем методы gl XXXPoi nter и gl Enabled ientStateC только один раз за кадр. Таким образом мы сэкономили около 100-6 вызовов OpenGL ES. Это должно значительно повлиять на работу устройств, правильно? Действительно.

Теперь все устройства примерно сравнялись. Droid работает лучше всех, за ним следует Nexus One. Наш маленький Него также работает весьма неплохо. Мы можем гордиться собой. Наш оптимизированный тест Боба теперь достаточно хорош.

Новый привязываемый класс Vertices, правда, не лишен некоторых ограничений.

Мы можем устанавливать данные вершин и индексов только тогда, когда экземпляры класса Verti ces не привязаны, поскольку загрузка информации о вершине осуществляется в Vertices .bind.

Мы не можем одновременно привязать два экземпляра класса Vertices. Это значит, что в каждом моменте мы можем визуализировать только один экземпляр класса Vertices. Как правило, это не большая проблема, особенно если учесть значительные улучшения в работе, так что давайте смиримся с этим.

В заключение

Есть еще один вариант оптимизации, который можно применить и при программировании 20-графики в планиметрии – в частности, прямоугольников. Об этом мы поговорим в следующей главе. Ключевой аспект такой оптимизации – объединение в группы (batching), а следовательно, и сокращение количества вызовов gl DrawEl ements /glDrawArrays. Аналогичный процесс применяется и в 3D -графике, он называется клонированием (instancing), однако в OpenGL ES 1.x он не работает.

Я хочу упомянуть еще две вещи. Прежде всего, когда вы запускаете BobText или Optimi zedBobTest (который содержит супероптимизированный код, который мы только что написали), обратите внимание, что Бобы перемещаются по экрану с характерным подергиванием. Это объясняется тем, что местоположение фигурок передается методу glTransl atef  в формате чисел с плавающей точкой. Проблема с попиксельной визуализацией связана с тем, что среда OpenGL ES действительно очень чувствительна к месторасположению вершин, чьи координаты имеют дробные значения. Мы не можем достаточно эффективно обойти эту проблему, однако в игре такой эффект будет несущественным или по крайней мере не слишком выраженным. В этом мы сможем убедиться далее, при разработке нашей следующей игры. Чтобы еще сильнее сгладить данный эффект, можно использовать более разнообразный фон.

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

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

Источник: Mario Zechner / Марио Цехнер, «Программирование игр под Android», пер. Егор Сидорович, Евгений Зазноба, Издательство «Питер»

По теме:

  • Комментарии