Коротко резюмирую тут трюки по борьбе со сборщиком мусора виртуальной машина 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 просто падал, когда кончалась физическая память в операционной системе. Вот так он работает на самом деле.
Дальше уже обнаружились другие интересные особенности. Моя оптимизация касалась в основном выделения памяти для множества картинок, на которых у меня строятся кадры анимации. Далее я просто резюмирую выводы, к которым пришел в ходе многочасовых экспериментов с 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(...). Другого пути пока не найдено.
Использовать много мелких картинок - плохая идея. Флеш будет выделять больше памяти чем требуется. Если же для большой группы картинок (допустим 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." Это очень радует.
Воскресенье, 04 Декабря 2011 г. 20:44
+ в цитатник
Мы закончили работу над демкой игры Optimus online!
Если этот пост вдруг прочитает потенциальный инвестор , добро пожаловать на партнёрский сайт, где выложена демка, скриншоты и инфа об игре.
Мы готовы раскрыть карты :) В настоящее время наша команда занимается разработкой компьютерной игры космической тематики. Мы решили сделать процесс разработки открытым и постоянно его освещать! Теперь каждый желающий может присоединиться к разработке игры и внести в неё свой творческий вклад. Поклонники Космических Рейнджеров, Вселенной X, старенькой Элиты и Master Of Orion — объединяйтесь!
Мы собираемся сделать небывалую космическую леталку жанра Elite (вселенная живёт, а ты делай в ней что хочешь) и сдвинуть с места прогресс в этой области! Мы взялись за это из чистого интереса, потому что в деталях знаем как сделать лучше, но в новых играх этого не делается. Почему такие космические цели? А всё остальное просто скучно. Так или иначе, проект уже профинансирован и в любом случае будет завершен. Команда профессионально занимается этой игрой и тратит на неё всё время. Запуск бета-версии намечается в июле 2011г.
Я предлагаю всем творческим людям, интересующихся космической тематикой присоединиться к сообществу разработчиков игры! Игра называется «Optimus». Сообщество разработчиков представляет собой группу ВКонтакте, вот здесь: http://vkontakte.ru/club26470591 — там Вы найдёте всю информацию об игре и ответы на свои вопросы. В группе можно выкладывать свои творения и мы включим их в игру.
Интересных дел в проекте полно. Есть задачи по дизайну, задачи по рисовке, моделирование в 3dmax, озвучка, музыка, придумывание квестов. Ну и программирование конечно. Молодая команда разработчиков просит у Вас помощи. Включи своё творчество, вступай в Optimus!