Коротко резюмирую тут трюки по борьбе со сборщиком мусора виртуальной машина Flash Player. Иследования проводились только для версии 11.1 standalone debugger for win32. В следующих версиях Flash Player могли как улучшить работу с памятью так и ухудшить, но скорее всего всё осталось также. Итак, garbage collector (GC) исключительно хреново работает с памятью. Он её попросту не очищает во многих случаях или выделяет в разы больше чем требуется.

Вы наверняка знаете, что такое сильные и слабые ссылки и как GC их считает чтобы понять нужен этот объект или нет... Всё это написано во многих местах, в т.ч. в документации по AS3. Я всё это повторять не буду. Здесь описано как всё должно хорошо очищаться: http://help.adobe.com/en_US/as3/mobile/flashplatform_optimizing_content.pdf
Но нифига оно так не работает к сожалению. При соблюдении всех этих правил моя программа всё равно жрала память как сумасшедшая при загрузке, а потом Flash Player просто падал, когда кончалась физическая память в операционной системе. Вот так он работает на самом деле.

Всё началось вот с этой темы в Juick: http://juick.com/eugene20237@ya.ru/2009006 и моего вопроса на StackOverflow: http://stackoverflow.com/questions/11833009/as3-bitmapdata-memory-leaks
Почитайте, если хотите, узнаете много нового о флеше. А ещё почитайте вот эту статью о том что надо реально сделать для оптимизации по памяти на флеше.

Дальше уже обнаружились другие интересные особенности. Моя оптимизация касалась в основном выделения памяти для множества картинок, на которых у меня строятся кадры анимации. Далее я просто резюмирую выводы, к которым пришел в ходе многочасовых экспериментов с BitmapData.

• Loader в дефолтном своем применении порождает утечки памяти. Поэтому если через него загружается картинка, то надо брать её BitmapData и делать bitmapData.clone(), сохраняя в другую переменную. А потом диспозить существующую картинку в Loader, а затем делать loader.unload(). Ещё на всякий случай можно cacheAsBitmap=false.
  

  PHP:
  
  
  var bitmapData:BitmapData = (loader.contentLoaderInfo.content as Bitmap).bitmapData.clone();
  
  (loader.content as Bitmap).cacheAsBitmap = false;
  
  (loader.content as Bitmap).bitmapData.dispose();
  
  (loader.content as Bitmap).bitmapData = null;
  
  (loader.contentLoaderInfo.content as Bitmap).bitmapData = null;
  
  loader.unload();
  font>
  

  
  Только тогда он работает нормально. И то с учетом, что память очищается секундой позднее. Но очищается. Во всех остальных случаях можно сушить вёсла... При этом Loader остаётся единственным способом загружать картинки без утечек памяти.


• C Embed ресурсами всё гораздо хуже. Под них выделяется всегда в разы больше памяти (в 2 раза обычно) и далее она не очищается никогда. Поэтому просто так Embed ресурсы использовать нельзя. Причина заключается в том, что они построены на Flex-компонентах, а в них много неоптимальной фигни. Юзайте Loader. А если нужно встроить ресурс в приложение, то делайте бинарный Embded, а затем Loader.loadBytes(...). Другого пути пока не найдено.
  

  PHP:
  
  
  [Embed(source="../media/128.png", mimeType="application/octet-stream")]
  
  static private const EmbedBMP:Class;
  
  ..............
  
  loader.loadBytes(new EmbedBMP() as ByteArrayAsset);
  font>
  

  
  


• Использовать много мелких картинок - плохая идея. Флеш будет выделять больше памяти чем требуется. Если же для большой группы картинок (допустим 100 шт.) вызывается dispose(), то их память будет очищена, но не сразу, а как повезет: может через минуту или как угодно Богу Мусорщику. Если же использовать десяток больших картинок (допустим 4096x4096), то память под них будет выделять и очищаться абсолютно корректно и сразу же.


• Выделение памяти под BitmapData происходит не при создании объекта BitmapData, а при первой операции рисования на ней или копирования данных пикселей в неё. Это внутренняя оптимизация BitmapData.


• Говорят, что BitmapData иногда выделяет памяти больше чем надо из-за внутреннего мипмеппинга. Этот мипмеппинг отключить никак нельзя. Также есть информация, что он отключается, если задать размеры картинки не являющиеся степенью двойки. У меня на практике это совсем не подтвердилось, так что никакой возможности управления мипмеппингом скорее всего уже нет.


• Сюда же поделюсь опытом использования трюка с local connection. Так вот, в исходном варианте этого хака LocalConnection создаётся два раза внутри try. Мои эксперименты показали, что надо вписать там три строчки, а не две. Вот так:
  

  PHP:
  
  
  public static function freeMemoryGC(): void
  
  {
  
    // the GC will perform a full mark/sweep on the second call.
  
    try
  
    {
  
      new LocalConnection().connect('foo');
  
      new LocalConnection().connect('foo');
  
      new LocalConnection().connect('foo');
  
    }
  
    catch (e:*)
  
    {
  
    }
  
    //System.gc();
  
  }
  font>
  

  
  В этом случае вероятность очистки памяти сразу гораздо выше (почти всегда сразу очищается). Если сделать два раза эту инструкцию, но вызвать тоже самое хотя бы через 100 мс, то память также очиститься. System.gc() не использую потому что он работает только AIR или только в отладочной версии Flash Player. Кроме того советую почитать эту тему о способах принудительного пинания GC. В частности в ней есть ссылка на такой способ.

Хочу поделиться совсем небольшим, но всё таки опытом создания графических спец-эффектов для игр. Я имею в виду всякие вспышки, магию и всё что угодно, что делается системами частиц. Но в первую очередь это конечно взрывы :)

На выходе мне нужны были наборы PNG файлов, которые затем я экспортировал специальной своей тулзой.

• Сначала делал их в 3dmax. Но это долго и сложно. Также есть плагин FumeFX для 3dmax, который всё это упрощает. Обратите на него внимание, если собираетесь заняться спецэффектами взрывов профессионально.
  


• Затем нашёл такую русскую фиговину как Magic Particles 3D. Это фактически бесплатная программа, которая позволяет создавать системы частиц и экспортировать их как в простые PNG файлы, так и в нечто большее. Помимо экспорта итоговой картинки там есть множество API для разных популярных игровых движков, что позволяет использовать разработанные системы частиц в играх, вычисляя их в realtime. В программе есть большое количество встроенных готовых эффектов (samples). Среди них парочка вменяемых взрывов.
  


• Совсем недавно обнаружил программку Particle Illusion. Стоит денег. На сей момент: $389. Выглядит более солидно чем Magic Particles. Пресетов для неё, судя по всему, очень много. Взрывы более качественные. Экспорт есть во что пожелаешь. Буду делать всё в ней теперь. API для игр правда нет, но мне и не надо.
  


• Ещё есть Adobe After Effects, но готовых взрывов для него я не нашёл, а изучать всё это долго. Но это средство предназначено именно для спецэффектов, так что если кто-то взялся за это серьёзно, есть смысл изучать After Effects. Стоит $175 на текущий момент.
  

Вот такой скупой обзорчик получился для тех кто не в курсе.

У меня появилась идея: экспортировать персонажей из Poser/DAZ и вставлять в свой игровой движок. Если такая возможность существует, то перспектива очень заманчивая, потому что моделей для Poser/DAZ существует дофигища. Это бы решило проблему поиска или создания нужных персонажей для игр. Но экспортировать надо в low-poly. Сразу же погуглил на эту тему и нашёл вот это обсуждение на англоязычном форуме. Там много интересного. Короче, выходы есть и так действительно можно.

В середине этой темы есть ссылка на утилиту под названием Decimator for DAZ Studio. Она может создавать низкополигональные модели из стандартных дазовских. А именно умеет:
"Decimator for DAZ Studio allows users to create any number of lower polygon versions of a high resolution model known as Levels of Detail (LODs). Use LOD features in DAZ Studio to automatically switch between models depending on factors such as distance from the camera.
Features:
- Create Levels of Detail (LODs)
- Remove invisible Nodes following decimation.
- Remove invisible Surfaces following decimation.
- Prepare to Decimate – (Convert polygons to triangles).
- Decimate complete model including all objects in scene.
- Decimate only selected objects.
- Decimate by percentage.
- Decimate to fixed number of faces."

Кроме того: "In Poser you have high poly meshes and low poly meshes. No need to use some plugin. the low poly meshes are like 2000 polys... perfect." Это очень радует.

Мы закончили работу над демкой игры Optimus online!
Если этот пост вдруг прочитает потенциальный инвестор , добро пожаловать на партнёрский сайт, где выложена демка, скриншоты и инфа об игре.

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

Есть утилита, которая называется "SpriteImage Composer", очень старая и глючная. Она делает именно то, что требуется и до недавнего времени я пользовался ей. Она сохраняет коллекцию спрайтов в один большой PNG файл. Однако проблема в том, что эти файлы слишком много весят, если хранить в них длительную анимацию. Например, 4 секундный ролик размером 128x128 в таком формате занимает уже более 1 Мб. Если таких анимаций будет много, то суммарный размер данных для игры уже является неприемлемо большим.

Решение придумал следующее. Для анимационных эффектов не особо важна точность деталей картинки, поэтому её можно сжимать с потерями, т.е. в JPEG. Но JPEG не поддерживает прозрачность. Как же быть? А вот как: собираем все спрайты в большую картинку, а потом сохраняем её в виде двух частей. Первая часть - сама картинка анимаций в виде JPG-файла, а вторая - альфа канал, тоже в виде отдельного JPG-файла. Затем в целевом приложении загружаем оба файла, компонуем в единую картинку с прозрачностью и разбиваем по кадрам. Преимущество такого подхода в том, что суммарный размер пары JPG-файлов в несколько раз меньше, чем единая PNG-картинка.

Именно этот подход использует моя крохотная утилитка, написанная под Adobe AIR. Скачать её и использовать может каждый разработчик, столкнувшийся с этой элементарной проблемой: http://code.google.com/p/fire-starter/
Программа является OpenSource'ной - берите и делайте с ней всё, что хотите.

Моё коллега недавно перевел статью о том как организовано сетевое взаимодействие в игре Counter Strike. Если кому интересно, можете почитать с комфортом: на русском языке и с картинками: http://gamecrafta.ru/blog/6.html

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

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


Нетрудно догадаться, что при прямом real-time моделировании внутренних процессов всех подсистем задача не имеет решения.

Существующие методы
Неизвестны. Реализаций таких не видел. Если кто-то знает какие-либо научные работы на эту тему, прокомментируйте плз.

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



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



Как же синхронизировать упрощенные вычисления и детальные "внутренние" процессы для одной такой подсистемы? Предлагается мыслить в обратном направлении. Сначала описать мат. модель и алгоритмы упрощенных вычислений для каждой подсистемы и считать их выходные данные эталонными. Затем описывать и реализовывать детальное моделирование внутренних процессов таким образом, чтобы выходные данные (кол-во хлеба на прилавке) точно соответствовали результату упрощенного моделирования. Внутренние процессы подсистемы также должны зависеть от внешних атрибутов. В этом направлении есть куда копать! Таким образом, в обоих случаях подсистема выдаёт один и тот же результат, поэтому ведёт себя с точки зрения наблюдателя совершенно честно.

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

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

Автор будет благодарен за конструктивную критику и за использование этих идей в любой сфере.

Уважаемые любители компьютерных игр!

Мы готовы раскрыть карты :) В настоящее время наша команда занимается разработкой компьютерной игры космической тематики. Мы решили сделать процесс разработки открытым и постоянно его освещать! Теперь каждый желающий может присоединиться к разработке игры и внести в неё свой творческий вклад. Поклонники Космических Рейнджеров, Вселенной X, старенькой Элиты и Master Of Orion — объединяйтесь!

Мы собираемся сделать небывалую космическую леталку жанра Elite (вселенная живёт, а ты делай в ней что хочешь) и сдвинуть с места прогресс в этой области! Мы взялись за это из чистого интереса, потому что в деталях знаем как сделать лучше, но в новых играх этого не делается. Почему такие космические цели? А всё остальное просто скучно. Так или иначе, проект уже профинансирован и в любом случае будет завершен. Команда профессионально занимается этой игрой и тратит на неё всё время. Запуск бета-версии намечается в июле 2011г.

Я предлагаю всем творческим людям, интересующихся космической тематикой присоединиться к сообществу разработчиков игры! Игра называется «Optimus». Сообщество разработчиков представляет собой группу ВКонтакте, вот здесь: http://vkontakte.ru/club26470591 — там Вы найдёте всю информацию об игре и ответы на свои вопросы. В группе можно выкладывать свои творения и мы включим их в игру.

Интересных дел в проекте полно. Есть задачи по дизайну, задачи по рисовке, моделирование в 3dmax, озвучка, музыка, придумывание квестов. Ну и программирование конечно. Молодая команда разработчиков просит у Вас помощи. Включи своё творчество, вступай в Optimus!

Присоединяйтесь.
Разработчики игры.

Хочу игру без кача. Хочу исследовать пространство и каждый раз натыкаться на что-нибудь новое. Хочу охотится на опасных врагов, чтобы каждый новый трофей доставался иначе чем предыдущий. А потом хвалиться этими трофеями. Вот такой была идеальная игра для настоящего меня. Увы, таких игр пока не существует.

Вот Сталкер. К нему много нареканий. Я считаю игра неправильно сбалансирована. В итоге там вообще ничего не нужно чтобы пройти основной сюжет. При желании его можно пройти голым и с пистолетиком. Вообще очень глупо что они этот мир бояться вовсю использовать в игре и делают какие-то дибильные квесты. Вот слабо им было сделать хотя бы автгенератор новых видов аномалий или других премудростей Зоны? Была киллер фича, но это уже для игр будущего, а сейчас им и так хорошо. Меня это просто бесит в современном игростроительстве. Везде именно так. Можно сделать реально круто, но это не делается.

Есть целый вагон научных областей, в первую очередь в математике, где описаны интереснейшие алгоритмы, пригодные для использования в играх. В будущем они станут элементами ИИ, но для нас это не важно. Важно то, что это даже уже придумано, но людям то ли лень в этом копаться, то-ли вообще плевать на интересность игры. Я вот больше склоняюсь ко второму. Но даже если моя игра зашибает кучу денег, я всё равно не остановлю прогресс. Это противоестественно для меня.