По роду своей деятельности приходилось программировать на разных языках и платформах, включая промышленные контроллеры ScadaPack. Казалось бы, привык к различным подходам программирования. Но тут мне попался Flash. Задача стояла портировать сетевую библиотеку с JAVA. И началось… Бедные флешеры, как вы вообще программируете на таком языке? Я понимаю, что раньше было еще хуже, но и сейчас ситуация очень далека от идеальной, а точнее от удобной.

Полное отсутствие типов — byte, short, long. Вряд ли их поддержка усложнила бы виртуальную машину. Но еще хуже то, что нет нормальных коллекций, а есть универсальный супер комбайн Array и неплохой Dictionary. Я допускаю, что Array ввели для флешеров старой закалки, но могли же добавить и нормальные коллекции. Из-за Array флеш-программист чаще всего не понимает разницы между примитивным массивом, ассоциативным и сетом. Если уж AS3 был скопирован с JAVA, то почему не скопировали самое главное — структуру коллекций? Даже если бы дали доступ только к примитивным массивам, то можно было бы реализовывать нормальные List, Map, Set. Какой был бы простор для повышения быстродействия.

Убогая и тормозная оболочка программирования. И нет тут вины Eclipse, вина только разработчиков Flex, которые в спешки не подумали о скорости и удобстве работы. Сколько времени и сил было потрачено на борьбу с глюками и зависаниями, сейчас только надежда на разработки третьих лиц. Ждем с нетерпением!

И в заключении — FLASH жив только своей виртуальной машиной, как язык он из себя мало что представляет. И хотя графические возможности поражают, но над языком надо работать и работать.

Тестируем поддержку 3D-многоугольников.

Трижды переписывали алгоритм сравнения полигонов.
Всё успешно разрулили, причём ещё остались возможности для будущей оптимизации.

Появились нюансы — сортировка точек и рёбер с самим телом объекта.

Серверные кодеры для отслеживания 3D-мира сделали себе консоль.
У каждой камеры задаются свои параметры (поля внизу или с помощью мыши). Справа дерево объектов мира.

Реализовано на Java с использованием SWT/OpenGL. Консоль может работать автономно или получать данные с игрового сервера посредством RMI.

Photoshop в настоящее время стандарт де-факто для дизайнеров. Но для игры, кроме, собственно, изображения, нужна дополнительная информация. Например, точки привязки, разбивка на спрайты и так далее. Было принято решение, для удобства дизайнеров, задавать дополнительную информацию используя возможности Photoshop-а. То есть точки привязки — в отдельном слое, деление на спрайты — слайсами и так далее. Для обработки сервером этой информации нам потребовался парсер PSD-формата. Стали искать готовые парсеры, нашли, но довольно убогие, например, нет поддержки множественных слоев, слайсов и так далее. Пришлось найти документацию по формату и потратить неделю на написания парсера.

Пример использование парсера:

PSDParser parser = new PSDParser(new FileInputStream("image.psd")); 
PSDLayerAndMask layerAndMask = parser.getLayerAndMask();  
 
List layers = layerAndMask.getLayers(); 
List images = layerAndMask.getImageLayers(); 
int i = 0; 
for (PSDLayerStructure layer : layers) { 
    PSDLayerPixelData pixelData = images.get(i); 
    BufferedImage image = pixelData.getImage(); 
    if (image != null) 
	ImageIO.write(image, "png", new File(layer.getName() + ".png")); 
	    i++; 
}

Исходники проекта

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

psd_parser.7z

Получены первые результаты по честной Z-сортировке полигонов с учётом геометрии объектов. Для этого применяется пространственное сравнение каждого полигона с другими и выстраивание иерархии «кто за кем». Применили несколько оптимизаций, но уже сейчас понятно, что скорость сортировки всё равно будет ниже, чем у сортировки по средним Z. Другой вопрос — на сколько?

За первые месяцы работы мы уже пережили 2 версии 3D-движка, но последние эксперименты с ландшафтом и мягким текстурным освещением подталкивают нас на новую кардинальную переделку движка. Тому есть несколько причин:

• Простая Z-сортировка имеет серьёзные ограничения. Например, если один полигон находится перед другим более крупным, но его Z-центр чуть дальше, большой его перекроет. Или у перемещающегося по ландшафту персонажа ноги периодически будут проваливаться под землю. Дробление полигонов на более мелкие снижает вероятность глюков, но не решает проблему полностью. Да и отсчёт большего числа полигонов сильно снизит производительность.
• Высокая зависимость математики и визуализации, что снижает способность движка к быстрой модернизации.
• Сложная и медленная система освещения полигонов — на каждый накладывается засветляющий, затемняющий, да ещё и GI(Global Illumination) полигон.
• Невозможность внедрить текстурное освещение (как на ландшафте) для всех объектов из-за ограничений структуры движка.
• Необходимость расчётов GI — мягкого рассеянного света — в сторонних пакетах 3D-визуализации.
• Невозможность быстрой коррекции текстур на объектах. Например, добавления следа от взрыва на стене дома.

Принято тяжёлое решение переписать 3D-движок с нуля. Надеюсь, что все вышеперечисленные проблемы нам удасться решить.

Список задач:

• Честный Z-буфер с анализом геометрии полигонов, что решит глюки Z-буферизации и позволит сократить количество полигонов на порядок.
• Поддержка полигонов, т.е. точек, отрезков, треугольников, квадов и т.д.
• Вынесение алгоритмов рендера отдельно от объектов, что позволит легко модифицировать визуализацию и создавать новые методы.
• Мягкие тени на всех объектах и авто-расчёт GI на клиенте
• Произвольное текстурирование 3D-объектов текстурными объектами

Ландшафт — уникальный 3D-объект. Он не имеет границ и размеров. Для интернет-игры крайне важна загрузка только видимой части ландшафта. Также ландшафт невозможно смоделировать раз и навсегда, он постоянно меняется и дорисовывается. Поэтому в первую очередь мы занялись разработкой 3D-редактора ландшафта (далее он перерос в полноценный редактор всех объектов).

Первая версия редактора:

Управление:

• Мышь — поворот камеры. С нажатым Shift — поворот по третьей оси.
• Колёсико — зум.
• T/B/L/R — вид сверху/снизу/слева/справа
• F4 — переход в режим редактирования
  • Можно двигать точки, при этом работает авто-объединение точек (может глючить).
  • Драг/клик+Ctrl — дробление:
    • На полигоне — дробление полигона в месте клика.
    • На грани между полигонами — деление их в этой точке.
  • Драг+Alt — вытаскивание полигона из грани.
  • S — прилипание по координатам (не очень удобное).

Читать полностью »

Возникла следующая задача: допустим я в Eclipse занимаюсь программированием кода, правлю файлы в различных проектах. Но сервер работает совершенно на другом компьютере. То есть мне надо все свои измененные проекты перенести на сервер, а запоминать какие проекты я изменил, а какие нет не очень удобно. Для решения задачи потратили два часа и написали два плагина, один для серверных программистов, второй для клиентских. Плагины следят за проектами и записывают изменения, первый плагин формирует XML файл с изменениями для ant, второй копирует изменные swf файлы в один каталог, который позже переносится в SVN одной командой.

change_project_flash.7z
change_project.7z