За последние полгода редактор для создания игр и просто баннеров под HTML5 прилично пообтесался, упростился (в смысле концепции и интерфейса) и, в итоге, стал ближе к конечному пользователю. Пришла пора посмотреть, что есть в нём (в редакторе, а не в пользователе, конечно) интересного. Под катом — тяжёлые картинки и немного текста.

Эта статья написана по следам создания плагина для чтения SVG файлов для анимационного векторного редактора NanoFL. В ней вы найдёте некоторые особенности того, как устроены файлы SVG изнутри и какие проблемы возникают при их разборе и последующем выводе на HTML5/Canvas средствами JavaScript.

Восемь месяцев упорной разработки позади и вот — вторая версия популярного (в будущем — наверняка) векторного анимационного редактора и, по совместительству, среды для разработки игр увидела свет. Об этом релизе мне, наконец, не стыдно рассказать хабрасообществу. В этой статье пойдёт речь о некоторых особенностях NanoFL.

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

Давным-давно, в далёкой-далёкой галактике (т.е. больше года назад и за пределами дефолт-сити) один web программист решил написать свой Flash (был он не без мании величия, конечно). Задача тогда казалась непростой и очень интересной. В данной статье пойдёт речь об одной из проблем, которые встали у него на пути.
Те, кто рисовал во Flash знают, что в нём фигуры (закрашенные области) в пределах одного слоя никогда не перекрываются, а линии всегда рисуются поверх закрашенных фигур. У такого подхода есть, на мой взгляд, хороший плюс — ты имеешь на изображении то, что видишь. Однако, при написании векторного редактора это приводит к необходимости решения задачи корректного наложения рисуемых объектов (линий и закрашенных фигур) на уже существующие. Ниже я попытаюсь поэтапно показать, как это можно сделать.

В предыдущей статье я немного рассказал про haxe — простой и удобный язык общего назначения. Однако, кроме простоты и понятности, есть в нём и вещи глубокие — такие, как концепция макросов — кода, который выполняется в процессе компиляции. Почему в haxe нет традиционных Си-подобных макросов и какие возможности нам отрывают haxe-макросы, и пойдёт речь в статье.

Haxe — очень удобный и практичный язык, но маленькое сообщество и, как результат, небольшое количество библиотек заставляют меня немало времени тратить на подготовку «заголовочных файлов» для интеграции open source библиотек в haxe. Немного об этом языке и о путях преобразования исходного кода на разных языках мне бы и хотелось рассказать ниже.

Чуть больше года назад меня попросили поучаствовать в развитии одной известной в узких кругах (но не всегда с хорошей стороны) социальной сети. В то время я уже был фанатом языка Haxe, поэтому с тем на чём писать вопросов не возникало. А вот с БД они появились. Опыт использования MS SQL Server и MySQL говорили о том, что когда дело касается больших объёмов информации, то порой случаются сложности (практически невозможным становится изменение структуры БД, а когда-то быстрые запросы работают уже критически медленно). Посовещавшись с коллегами (у которых уже был опыт с Mongo), мы решили использовать именно эту СУБД. А о тех особенностях, которые всплыли в течение этого года я и расскажу ниже.