Концепція зв’язування вершин – РОЗРОБКА ІГОР ДЛЯ ОС ANDROID

Чи можемо ми ще щось оптимізувати Ще раз подивимося на наш поточний метод 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, викликаємо Verticesunbind, щоб скасувати всі властивості вершин, які не потрібні іншим екземплярам класу Vertices Доцільно не вносити зайвої інформації в стан OpenGL ES Ось як тепер виглядає наш метод present (я також перемістив виклик glMatrixMode (GL10GL 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 1x він не працює

Я хочу згадати ще дві речі Насамперед, коли ви запускаєте BobText або Optimi zedBobTest (який містить супероптімізірованний код, який ми тільки що написали), зверніть увагу, що Боби переміщуються по екрану з характерним посмикуванням Це пояснюється тим, що місце розташування фігурок передається методу glTransl atef у форматі чисел з плаваючою крапкою Проблема з попіксельно візуалізацією повязана з тим, що середовище 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>

*

*