Безперервна візуалізація в потоці користувача інтерфейсу – РОЗРОБКА ІГОР ДЛЯ ОС ANDROID

Все, що ми зробили до цього моменту, – забезпечили зміна тексту в TextView при необхідності Перемальовування здійснюється самим TextView Створимо наш власний View, єдиним завданням якого буде надання нам можливості малювати на екрані Нам необхідно, щоб цей View оновлювався якомога частіше Нам також потрібен простий спосіб виконувати малювання якимось чарівним способом

Хоча на слух це може здаватися досить складним завданням, насправді Android забезпечує легкість в реалізації таких завдань Все, що нам треба, – створити клас, наслідуваний від View, і перевизначити його метод ViewonDraw Цей метод викликається системою Android кожен раз, коли View вимагається перерисовка Виглядає він приблизно так:

Ще не так вже все складно, чи не так Ми передаємо методу onDraw екземпляр класу Canvas У найближчих розділах він стане нашою робочою конячкою, дозволяючи нам малювати фігури і зображення в іншому зображенні або Vi ew (або на поверхні екрану, про що ми поговоримо трохи пізніше)

Використовувати обєкт RenderView можна так само, як TextView, – ми просто встановлюємо його в якості контейнера вмісту нашої активності й обробляємо всі процеси, які нам потрібні Однак поки цей клас не дуже корисний для нас з двох причин: по-перше, насправді він нічого не малює по-друге, навіть коли зможе, то буде робити це тільки тоді, коли активність отримає запит на перемальовування (Тобто при її старті або поновленні або після зникнення перекриває її діалогового вікна) Як нам змусити його перемальовуватись самостійно

Ось так:

Виклик методу ViewinvalidateO наприкінці onDrawO повідомить Android про необхідність перемальовування RenderView при першій можливості Все це як і раніше відбувається в призначеному для користувача потоці, який зазвичай злегка неквапливий Проте у нас вже є безперервна перерисовка в методі onDraw, хоча і не дуже швидка Ми виправимо це пізніше поки для наших завдань цього достатньо

Отже, тепер пора повернутися до загадкового класу Canvas Це досить потужний інструмент, обгортають низкоуровневую бібліотеку Skia, призначену для виконання 20-візуалізації центральним процесором Клас Canvas пропонує нам безліч методів малювання для фігур, зображень і навіть тексту

Де ми будемо використовувати ці методи Це залежить від поставлених цілей Canvas може перемальовуватись в екземпляр Bitmap – іншого класу, пропонованого 2D API Android (ми розглянемо його пізніше) У даному випадку промальовування відбуватиметься для частини екрану, займаної View Звичайно, це досить значне спрощення: насправді промальовування проводиться не на самому екрані, а в якесь зображення, яке система пізніше буде використовувати в комбінації з зображеннями від усіх інших View активності, щоб скласти з них кінцеву підсумкову картинку Вийшло зображення передається графічному процесору, отображающему його на екрані ще більш загадковими шляхами

Взагалі, у нас немає необхідності піклуватися про такі деталі У даному випадку наш Vi ew займають всю площу дисплея, тому може перемальовуватись також під фреймбуфер системи До кінця обговорення уявімо, що ми виробляємо перерисовку безпосередньо під фреймбуфер, залишаючи системі робити всю нудну роботу начебто вертикальної трасування і подвійний буферизації

Метод onDraw буде викликатися так часто, як це дозволяє система Для нас це дуже схоже на тіло нашого (теоретичного) головного ігрового циклу Якщо ми будемо реалізовувати гру за допомогою цього методу, в нього можна помістити всю ігрову логіку Однак ми не будемо робити цього з різних причин (однією з яких є продуктивність)

Давайте зробимо що-небудь цікаве Кожен раз, коли виходить нове API для малювання, я пишу маленький тест, що перевіряє частоту перемальовування екрану Єдине зміст викликається методу перемальовування – Заповнення екрану випадковим кольором Мені потрібно тільки знайти метод для даного API, який дозволить це зробити, не замислюючись про деталі реалізації Напишемо подібний тест для нашої реалізації RenderView

Метод класу Canvas, що заповнює мета промальовування певним кольором, називається CanvasdrawRGEK):

Аргументи г, g і b зберігають по одному компоненту кольору, яким ми хочемо заповнити екран Кожен з них приймає значення від 0 до 255, тому кольори визначаються у форматі RGB888 Якщо ви не памятаєте подробиць, стосуються кольорів

Лістинг 412 показує код нашого калейдоскопа

УВАГА

Запуск цього коду призведе до швидкого заповнення екрану випадковими квітами Якщо у вас епілепсія або проблеми зі сприйняттям різких змін кольору, не запускайте його

Лістинг 412 Активність RenderViewTest package combadogiсandroidgames

Код для нашого першого графічного прикладу досить складний Ми визначаємо клас RenderView як внутрішній для активності RenderViewTest Цей клас успадковується від Vi ew і має обовязковий конструктор, також перевизначення метод onDrawO Крім того, він включає в себе внутрішній член типу Random (ми будемо використовувати його для генерації випадкових кольорів)

Метод onDraw гранично простий У ньому ми спочатку командуємо Canvas заповнити весь контейнер подання випадковим кольором Для кожного компонента кольору ми з допомогою методу Random, next Into визначаємо випадкове число від 0 до 255, після чого повідомляємо системі, що очікуємо перемальовування екрану (тобто виклику методу onDraw) якомога швидше

Метод onCreate активності включає повноекранний режим і встановлює примірник RenderView як контейнер подання Для збереження стислості прикладу в даному випадку я вирішив ігнорувати захист від блокування

Робити скріншот цього прикладу не має сенсу Все, що він робить, – заповнює екран випадковим кольором так часто, як це дозволяє система для потоку користувача інтерфейсу Тут нічим особливо хвалитися Замість цього виконаємо щось більш цікаве – порисуємо фігурки

ПРИМІТКА

Хоча описаний метод безперервної перемальовування є цілком працездатним, я настійно не рекомендую його використовувати У потоці користувача інтерфейсу потрібно робити якомога менше дій Скоро ми обговоримо, як помістити наші функції в окремий потік, в якому ми також зможемо реалізувати нашу ігрову логіку

Отримання дозволу екрану і координатної системи

Ви памятаєте, що фреймбуфер зберігає кольору пікселів, що показуються на екрані Кількість доступних нам пікселів визначається здатністю екрану (шириною і висотою в пікселах)

Тепер з нашою власною реалізацією View, ми не перемальовували фрейм-буфер безпосередньо Але оскільки наш View займає весь екран, ми можемо уявити, що це так Щоб дізнатися, де ми можемо розміщувати елементи нашої гри, нам потрібно дізнатися кількість пікселів по осях хіу (тобто ширину і висоту дисплея)

Клас Canvas містить два методи, що допомагають нам в цьому:

Вони повертають ширину і висоту елемента, для якого Canvas здійснює промальовування Зверніть увагу – залежно від поточної орієнтації активності ширина може бути більше або менше висоти Наприклад, в моєму Nexus One встановлено дозвіл 480 х 800 пікселів в портретному режимі, тому метод Canvas getWi dth Про поверне 480, a Canvas getHeight – 800 У ландшафтному режимі ці значення міняються місцями

Друга частина необхідної інформації – координатна система, використовувана для візуалізації Насамперед, значення мають тільки цілочисельні координати пікселів (існує так звана концепція субпикселов, але ми поки ігноруємо її) Ми вже також знаємо, що початок координатної системи завжди знаходиться в точці (0, 0) в лівому верхньому куті дисплея – неважливо, в портретному або ландшафтному режимі Вісь х завжди спрямована зліва направо, вісь у – завжди вниз На рис 412 показаний гіпотетичний екран з роздільною здатністю 48 х 32 пікселя в ландшафтному режимі

Рис 412 Координатна система екрану 48 х 32 пікселя

Зверніть увагу – початок координатної системи на малюнку збігається з лівим верхнім пикселом екрана Правий нижній піксель екрану має координати ні (48 32), як ми могли б очікувати, а (47 31) В цілому (Width – 1 height – 1) завжди є позицією правого нижнього пікселя екрана

Малюнок 412 демонструє координатну систему гіпотетичного дисплея в ландшафтному режимі Тепер ви можете уявити, як дисплей буде виглядати в портретному режимі

Всі методи промальовування Canvas діють всередині цієї координатної системи Зазвичай ми можемо оперувати з набагато більшою кількістю пікселів, ніж 48 х 32 (наприклад, 800 х 480) Тепер займемося малюванням пікселів, ліній, кіл і прямокутників

ПРИМІТКА

Ви, мабуть, помітили, що різні пристрої можуть мати різні дозволи екрану Ми розберемося з цією проблемою в наступному розділі, поки просто сконцентруємося на отриманні чогось на дисплеї

Джерело: 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>

*

*