Компонент для работы с растровыми шрифтами

Продолжая работу над портом движка Flixel на Haxe, столкнулся с необходимостью оптимизации работы с текстом. Проблема заключается в следующем: стандартный класс движка FlxText сильно завязан на использование метода draw(), и при обновлении текста создается новый экземпляр класса BitmapData, еще одним недостатком является то, что для каждого такого текстового объекта создается свой экземпляр класса TileSheet (если в качестве целевой платформы установлен c++, neko или android). В общем видно, что такая реализация класса для отображения текста довольно неудачна и нужно искать другие решения. И тут на сцену выходят растровые шрифты -- каждый символ такого шрифта представляет собой по-сути простое изображение и работать с ними можно точно также, как и с обыкновенными изображениями. В наборе классов Flixel Power Tools как раз есть такой класс FlxBitmapFont и я его уже давно портировал, но в нем также присутствует довольно раздражающее меня ограничение -- он поддерживает только моноширинные шрифты (все символы таких шрифтов должны иметь одинаковую ширину), а мне же хотелось чего-нибудь более универсального. И недавно мне на глаза попался движок Pixelizer (упоминал его в одном из предыдущих сообщений), в котором очень понравилась реализация такого компонента: в нем уже был такой функционал, как изменение цвета шрифта, обводка и тени, поддержка многострочного текста и др. Встала задача по переводу этого добра на другие рельсы:

1. Реализация в виде отдельного компонента, не завязанного ни на какой из движков -- такой класс нужен был для того, чтобы наконец-то закончить портирование прелоадера Flixel.
2. Реализация в виде плагина для Flixel, которую можно использовать непосредственно в играх.

Самая первая версия порта была готова через 1-2 дня, но сразу же вылезли проблемы с производительностью: для отрисовки текста использовался метод draw(), позволяющий задавать тексту цветовую трансформацию и прочие параметры. Нужно было искать другой способ отрисовки. Подумав немного и посмотрев на реализацию спрайтов в Flixel, пришел к следующему решению: на входе имеем набор растровых изображений, представляющих собой исходные изображения символов растрового шрифта, а для того, чтобы отображать масштабированный и "окрашенный" текст создается дополнительный массив трансформированных изображений символов, таким образом, мы можем использовать уже гораздо быстрый метод copyPixels() (после такого преобразования нагрузка на процессор при отрисовке текста снизилась в 2-4 раза).
Завершив с оптимизацией, я приступил к реализации дополнительных "фишек":

• настройка размера шрифта
• настройка расстояний как между символами, так и между строками текста
• настройка переноса слов

На это ушло еще несколько дней, скачать и посмотреть что получилось можно со странички репозитория - https://github.com/Beeblerox/BitmapFont [...]
Читать дальше: Компонент для работы с растровыми шрифтами

Динамическая генерация текстурных атласов

Давно задумываюсь: "А не попытаться ли перевести Flixel на Stage3D?" Сам автор движка обещал, что когда новая версия flash-плеера с аппаратной поддержкой 3D получит достаточно широкое распространение, то он добавит эту фичу. Но новостей от него пока не слышно; тема на форуме фликселя, посвященная планам по разработке новой версии, тоже довольно давно не обновлялась. Поэтому и мысли такие. Кроме того, в сети появилось несколько очень хороших уроков по stage3D, в которых рассматривается использование нового API для разработки двумерных игр. Из них можно вынести очень полезные сведения, связанные с оптимизацией графики:

• необходимо минимизировать количество вызовов метода drawTriangles(), т.к. он довольно ресурсоемок;
• также следует использовать как можно меньше текстур, т.к. размеры текстур могут иметь строго определенные значения (64х64, 128х128, 256х256, 512х512, 1024х1024 или 2048х2048). И если в Вашей игре используется множество маленьких изображений, для каждого из которых Вы будете создавать новую текстуру, то видеопамять будет расходоваться нерационально (в каждой такой текстуре будет много "пустого места") и довольно быстро закончится.

 Для решения этих проблем рекомендуется использовать "пакетный рендеринг" (не знаю, правильный ли я использую термин, на английском он пишется batch-rendering), при котором мы за один вызов метода drawTriangles() пытаемся отрисовать все полигоны, использующие одну и ту же текстуру. Для этого нам и понадобится генерация текстурных атласов, вынесенная в заголовок статьи и позволяющая значительно уменьшить количество текстур (о пакетном рендеринге я скорее всего напишу в следующей статье). Суть его в следующем: на входе мы имеем множество мелких изображений, а на выходе -- одно (это в идеале) большое. На русском языке уже есть, по крайней мере, одна статья от flash-сообщества, посвященная этому вопросу -- класс для генерации текстурных атласов, в ней дается исходник класса, использующий рекурсивный метод построения атласа. Данный класс мне показался не слишком понятным, а так хотелось самому разобраться в алгоритме, благо что в статье приведена ссылка на англоязычную статью по данному вопросу, из которой и становится ясен общий принцип.
Читать дальше: Динамическая генерация текстурных атласов

Создание порта движка для создания двухмерных игр Flixel на Haxe

1. Что такое Haxe?
Haxe – это объектно-ориентированный язык для кроссплаторменной разработки, в настоящее время в качестве целевых платформ для него выступают flash, javascript, php, c++ (в начале 2012 года ожидаются c# и java). Если Вы раньше писали программы на ActionScript 3, то синтаксис Haxe покажется Вам знакомым (еще один немаловажный плюс). При этом для haxe существует множество различных библиотек, существенно облегчающих различные задачи. Одной из таких библиотек является NME (Neko Media Engine), позволяющая пользоваться flash api при разработке графических приложений для Windows, Mac, Linux, Android, iOS, WebOS, HTML5 и, конечно, flash (куда же без него), это означает, что Вы пишете один код (ну, почти что один), и он работает на всех перечисленных платформах. Кроме того, программы под Windows, Mac, Linux, Android, iOS и WebOS используют аппаратное ускорение графики (через OpenGL, OpenGL ES), что на данный момент дает значительное преимущество в производительности перед флэшом (аппаратное ускорение в котором есть на персоналках, но на мобильных платформах его пока только обещают).

Читать дальше: Создание порта движка для создания двухмерных игр Flixel на Haxe