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

0

Добавим классы TextureRegi on и Spri teBatcher в наш пример с пушкой. Я скопировал пример TextureAtl as и переименовал его в SpriteBatcherTest. Классы, содержащиеся в нем, теперь называются SpriteBatcherTest и SpriteBatcherScreen.

Первое, что я сделал, – избавился от членов класса Vertices в классе экрана. Нам они больше не нужны, ведь для исполнения всей черной работы у нас теперь есть SpriteBatcher. Вместо них я добавил следующие члены:

Теперь у нас есть TextureRegion и SpriteBatcher для каждого из трех объектов в нашем атласе. Далее я видоизменил конструктор экрана. Избавился от кода реализации и инициализации класса Verti ces и заменил его одной строкой кода:

Она поместит член batcher в новый экземпляр класса SpriteBatcher, который может рендерить 100 спрайтов в одном пакете.

Области TextureRegion будут инициализированы в методе resume, так как они зависят от Texture:

Здесь нет ничего нового. Нам также нужно изменить метод present. Вы удивитесь, насколько чистым и красивым он вам теперь покажется:

Совсем просто, правда? Единственные вызовы OpenGL ES, которые мы используем, предназначены для очистки экрана, активации смешивания и текстурирования и для задания функции смешивания. Все остальное – только SpriteBatcher и Came га 2D. Поскольку все наши объекты находятся в одном атласе текстур, мы будем отображать их в одном пакете. Мы вызываем batcher. begi nBatch  с атласом текстур, отображаем всех Бобов-мишеней, используя просто метод отрисовки, х отображаем ядро (снова простым методом отрисовки) и наконец пушку, используя метод отрисовки, который может вращать спрайт. Мы заканчиваем метод вызовом batcher end Batch, который, собственно, переносит геометрию наших спрайтов в графический процессор для отображения.

Измерим производительность

Насколько же быстрее метод SpriteBatcher по сравнению с методом, который мы использовали в BobTest? Я добавил в код FPSCounter и засек время на Hero, Droid и Nexus One, как мы делали в случае с BobTest. Кроме того, увеличил количество мишеней до 100 и задал равным 102 максимальное количество спрайтов, которые SpriteBatcher может обрабатывать за раз. Ведь мы отображаем 100 мишеней, 1 ядро и 1 пушку. Вот результаты:

Прежде чем переходить к выводам, протестируем и старый метод. Поскольку наш пример не эквивалентен старому BobTest, я также изменил TextureAtl asTest, который почти не отличается от нашего нынешнего примера – единственная разница в том, что он использует старый метод BobTest для отображения. Вот результаты:

Него работает с нашим новым методом Spri teBatcher гораздо хуже по сравнению со старым вариантом, использовавшим glTranslateO и другие похожие методы. Droid лучше работает с новым методом, a Nexus One особо не различает, что мы применяем. Если бы мы увеличили количество мишеней еще на 100, вы бы увидели, что новый метод SpriteBatcher также был бы быстрее и на Nexus One.

Так что же с Него? Проблема BobTest была в слишком большом количестве вызовов OpenGL ES, так почему же новый метод работает хуже, хотя вызовов OpenGL ES в нем меньше?

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

По теме:

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