Використовуємо клас SpriteBatcher – РОЗРОБКА ІГОР ДЛЯ ОС ANDROID

Додамо класи 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», пров Єгор Сидорович, Євген зазноби, Видавництво «Пітер»

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*