Книга: Программирование мобильных устройств на платформе .NET Compact Framework

Пример 2: предварительная визуализация объектов для сюжетной игры

Любопытно отметить, что оптимизация визуализации изображений для сюжетных игр имеет много общего с оптимизацией этого процесса, которую мы рассмотрели на примере диаграмм. На рис. 11.10 представлено изображение для сюжетной игры, которую я написал для .NET Compact Framework, чтобы продемонстрировать концепции графики.

Рис. 11.10. Сюжетная игра, написанная для .NET Compact Framework

Существует три слоя изображений для игр, которые должны визуализироваться на экране:

1. Фоновая картинка. В играх предусматривается статическая фотография, используемая в качестве фонового изображения.

2. Статический передний план. К этой категории относятся изображения, находящиеся на переднем плане, которые не изменяются от кадра к кадру. На нашем игровом поле такими элементами являются настилы и лестницы. Эти изображения являются важными элементами переднего плана и изменяются при переходе с одного уровня игры на другой, но не изменяются при смене кадров при визуализации игры.

3. Динамический передний план. К этой категории относятся активные экранные изображения, которые могут изменяться от кадра к кадру. В нашей игре они представляют пещерного человека, пещерную женщину, два валуна, птицу и четыре факела. Эту разновидность графических элементов обычно называют "спрайтами". Кроме того, к динамическому переднему плану относятся индикатор запаса энергии, который находится в верхней части игрового поля слева, и индикатор Score/Bonus (Счет/Бонус), расположенный в верхней части игрового поля справа. В программе все эти элементы представлены объектами одной коллекции

Циклу визуализации предшествует загрузка фонового изображения и создание на нем рисунка настилов и лестниц. Эти изображения комбинируются в памяти и xpaнятся как наше фоновое изображение. Настилы и лестницы не изменяются при переходе от кадра к кадру, поэтому нет смысла визуализировать их вместе с каждым кадром. Поскольку фоновое изображение уже и так должно загружаться, мы не занимаем лишнюю память, рисуя на нем статическое игровое поле.

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

Когда выполняется визуализация кадра, то сначала в целевую битовую карту копируется фоновое изображение. После этого каждому из объектов визуализируемой коллекции направляется запрос на то, чтобы он визуализировал себя на целевой битовой карте. Некоторые из этих объектов являются текстовыми; такие объекты для прорисовки своего текста на целевой битовой карте вызывают метод Graphics.DrawString(). Одним из нетекстовых объектов является "энергетическая шкала", которая состоит из двух прямоугольников — внешней рамки и внутреннего закрашенного прямоугольника. Остальные объекты являются многокадровыми растровыми изображениями, то есть несколько таких изображений представляют различные возможные состояния спрайта; это обеспечивает возможность анимации объектов путем быстрого переключения между их различными изображениями.

С Хэнком (пещерным человеком) ассоциированы 8 изображений; 2 — для бега влево, 2 — для бега вправо, 2 — для подъема и 2 — для спуска. Для каждого спрайта предусмотрена внутренний конечный автомат, который следит за тем, какое изображение должно отображаться в процессе визуализации. Изображения имеют небольшие размеры; размеры изображения Хэнка составляют 21?35 пикселей, или, округляя в большую сторону до ближайшего кратного 4 (чтобы учесть возможное выравнивание границ размещения объектов в памяти), 24?36 = 864 пикселя. Всего для одного изображения требуется 864?4 байт/пиксель, что составляет примерно 3,5 Кбайт. Для загрузки всех 8 изображений Хэнка в память потребуется порядка 28 Кбайт, что вполне приемлемо.

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

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

Оглавление книги