пятница, 3 августа 2012 г.

Шаблон проекта HaxeFlixel для FlashDevelop

Одной из особенностей FlashDevelop, упрощающих жизнь разработчика, является возможность создания собственных шаблонов проектов. Я давно хотел создать такой для HaxeFlixel, но руки дошли только сегодня (шаблон доступен здесь).
Сам процесс оказался несложным, пришлось лишь немного погуглить и покопаться во внутренностях стандартных шаблонов. За основу были взяты следующие материалы:
Интересным фактом оказалось то, что установочный файл шаблона (файл с расширением .fdz), является простым zip-архивом, у которого изменено расширение.


воскресенье, 29 июля 2012 г.

NME и HTML5: ready or not?

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

В начале этой недели я в очередной раз попытался скомпилировать простую демку для HaxeFlixel в html5 и сразу же наткнулся на проблему: метод draw() класса BitmapData не учитывал параметры matrix (трансформация положения и формы) и colorTransform (цветовая трансформация), в то время как отрисовка графики в движке полностью строится на двух методах (draw() и copyPixels()). Но за что я люблю NME, так это за отзывчивость разработчиков, и буквально за три дня описанная проблема была исправлена. После этого я занялся непосредственно попыткой скомпилировать демку FlxInvaders в js-код. Сам процесс занял около 6 часов и состоял в основном в дописании параметров условной компиляции (ничего сложного), сам код практически не изменился. И вот, наконец, мне удалось запустить ее, но результат не впечатлил: всего 15-16 фпс против желаемых 30.
После этого началось небольшое исследование + экспериментрирование:
  • где-то полгода назад я услышал о Jangaroo -- специальном SDK, позволяющем компилировать AS3-код в JS, примерно тогда же встретил демку Jumper -- платформер, написанный на AS3 с использованием Flixel и портированный с помощью Jangaroo на html5. То есть успешные попытки портирования Flixel на html5 уже есть, и довольно давно. Так вот, вспомнив об этой технологии, решил поискать еще примеров по ней. Гугл выдал мне следующую страницу, содержащую несколько ссылок по данному предмету, в том числе и на демку FlxInvaders, которая у меня в Хроме выдает в среднем 42-43 фпс, т.е. почти в три раза быстрее.
  • увидев такую разницу в производительности, у меня возникло две мысли: а) мой порт тормозной и б) Jeash тормозной. С первой я спорить не стану, т.к. Flixel использует отрисовку всей графики в одну битмапдату (что является аналогом использования только одного элемента Canvas в JS), а это не самая эффективная техника (но Jangaroo умудряется выдавать при этом гораздо лучший результат), то вторая требовала более подробного изучения.
  • и один день я посвятил данному вопросу. Написал несколько пару простых демок, суть их такова: имеем приложение размером 800х600, в него рисуются спрайты, в каждый из которых вложена битмапа с одним и тем же изображением (30х30 px). В итоге имеем, что при 30 фпс я могу отрисовать 110-120 таких спрайтов, а при 60 — только 45. И это в Хроме, в ФайрФоксе и IE все хуже. Мне такие результаты совсем не нравятся, и Jeash (я так считаю) еще не готов для написания "серьезных" игр (под серьезными здесь я понимаю игры с большим количеством движущихся и трансформируемых объектов).
В итоге родилась следующая, так сказать, "мысль": переписать под себя класс BitmapData (ориентируясь на его текущую реализацию и версию Jangaroo), т.к. практически весь вывод графики в HaxeFlixel зависит от него. Но это, опять же, в отдаленной перспективе, т.к. в приоритете система слоев для C++, которая все так же находится в ранней стадии разработки, а затем stage3D-версия.

UPD: Совершенно забыл приложить скомпилированную версию демки и исходники теста производительности отрисовки спрайтов

среда, 25 июля 2012 г.

Happy Birthday to HaxeFlixel

В этот день год назад я создал на гитхабе репозиторий для HaxeFlixel. За прошедшее время было многое сделано, но в планах на будущее проекта у меня запасено еще на столько же времени, и даже больше. Спасибо Адаму Солтсману за оригинальный Flixel, спасибо Николя Каннасcу за язык Haxe и спасибо Хью Сандерсону, Джошуа Гранику и другим разработчикам за библиотеку NME!!!

среда, 18 июля 2012 г.

О возможном решении проблемы порядка отрисовки графики в HaxeFlixel

В одном из предыдущих сообщений я писал об одном из вариантов решения проблемы порядка отрисовки графики (draw order problem) -- для этого планировалось использование текстурных атласов и введение идеи слоев. Как уже было сказано, у данного решения есть существенное достоинство -- сокращение вызовов методов отрисовки графики, когда число вызовов таких операций за кадр будет равно числу слоев. Это значит, что если все используемые в игре изображения могут уместиться в одном атласе (размером, например, 1024*1024 пикселя), то метод drawTiles() будет вызываться только один раз за кадр. Кроме достоинств есть, конечно же, и недостатки -- повышенное потребление видеопамяти, т.к. 100% упаковка графики в атласы (когда используется вся площадь атласа и нет пустых "пятен") практически недостижима и требует от разработчиков дополнительного внимания (Возможно, что для упрощения работы с атласами, позже будут внедрены парсеры распространенных форматов, например, формат фреймворка Sparrow).
Для реализации данного способа решения уже имеются некоторые наработки -- класс для генерации текстурных атласов на лету я уже портировал на Haxe. Так что, скорее всего, данный метод будет реализован в первую очередь.
После некоторых экспериментов и размышлений я пришел ко второму возможному решению данной проблемы, не требующему использования текстурных атласов. Дело в том, что когда я только начинал портировать Flixel на Haxe, класс TileSheet у меня работал несколько иначе, чем сейчас. Возможно, что у меня тогда руки были кривее и я неправильно его использовал, или что поведение данного класса действительно изменилось. Но факт остается фактом: открылись некоторые новые для меня стороны данного класса, а именно то, что за один кадр можно неоднократно вызывать метод drawTiles() для одного и того же экземпляра TileSheet без появления артефактов. А когда я пытался сделать так в конце прошлого года, то переставали работать цветовые трансформации тайлов.
Теперь же есть возможность вызывать для каждого из изображений в слое метод drawTiles(), и, таким образом, достичь (или почти достичь) желаемого эффекта. Конечно же, при таком решении будет использоваться пакетная отрисовка графики, но в пределах каждого из слоев, иначе эффект от использования класса TileSheet будет равен нулю (т.к. чем больше вызовов метода drawTiles(), тем ниже производительность).
Возможно, что конечный результат будет комбинировать оба решения проблемы, я еще не решил окончательно. Но в первую очередь, как уже писал, я займусь вариантом с использованием атласов.

UPD:  Вспомнил еще об одной особенности работы класса TileSheet, о которой я раньше не знал (или она появилась позже, чем я с ней экспериментировал). Оказывается, что после создания экземпляра TileSheet, возможно изменять его битмапдату-источник, и данные изменения будут отображаться при отрисовке. Раньше же я такого не мог достичь (может быть это было еще одним проявлением моей криворукости). Эта особенность значительно упрощает работу с атласами, т.к. теперь нет необходимости пересоздавать их каждый раз при добавлении в них новых изображений (здесь, конечно же, опять возникает проблема неэффективного использования атласов, т.к. при создании атласов желательно сортировать по размеру входящие в них изображения, иначе в атласе будет полно "белых пятен").

вторник, 17 июля 2012 г.

Хорошее начало недели

Вчера, в понедельник, вышла новая версия Haxe 2.10. Главными ее нововведениями являются:
- поддержка языков C# и Java (пока что в состоянии бета-версии);
- уменьшение размера сгенерированного Javascript-кода;
- C++ дебаггер, о котором авторы обещают скоро написать поподробнее;
- переработка макросов, которые должны стать более понятными новичкам;
- множество улучшений в языке;
- и, конечно же, багфиксы.
Интересным фактом, связанным с этой версией, является то, что за период ее разработки (примерно 3 месяца) было сделано 693 ревизии.
Что ж, теперь будем ждать следующего релиза, на этот раз уже версии 3.0.
А сегодня, во вторник, вышла новая версия библиотеки NME 3.3.4 с улучшенной поддержкой BlackBerry, iOS и HTML5, а также с множеством исправлений ошибок.
К этим событиям я решил приурочить выход небольшого обновления для HaxeFlixel, содержащего:
- новый логотип;
- порт плагина FlxKongregate, позволяющего работать с API данного сервиса (только для Flash);
- порт плагина StarfieldFX - эффект звездного неба (фона);
- исправление нескольких ошибок.
И теперь я с уверенностью могу сказать, что HaxeFlixel поддерживает Haxe 2.10.
Скоро напишу о том, что я пытаюсь улучшить в движке. А пока что это все, о чем хотел рассказать вам сегодня.