Тотальная растеризация

Спасибо, интересный пост!
Тоже пишу фреймвор.Правда он связан с физикой, но не связан с отрисовкой.
Думаю можно совмещать стандартный рендер и ручной. Стандартный для меню и прочего, ручной - для отрисовки объектов в игре.

Смотреть на ДРАКОНЧ�?КОВ очень завораживает)

Статья очень полезная, спасибо!

> а вот приделать кнопки, выводить тексты и вообще собрать полноценный интерфейс уже не получится привычными способами,

Антон, я все такие вещи вывожу поверх главного блиттингового битмапа обычными display object. Я не делал тестов, но каких-то мега просадок (просто отключив-включив временно все эти объекты) я не заметил. Ну и точно "по старому" можно делать неигровые экраны (меню-сеттинги).

антон, а кстати вот вопрос! можно ли нарисовать человечка в первом кадре и в последнем чтобы он просто сам перешел в последнее положеие? или вы и так легче используете покадровую анимацию? если да? то как же анимация формы?

ну и напоследок обычно я вижу отдельно аниматоров и програмистов, подумал "да уж статьи были правы чтоигры надо делать минимум двоем аниматор+скриптер"но увидев умение второго человека ( первый на сайте хитри) я понял что нет ничего невозможного, главное только захотеть, причем вы рисуете отлично, что странно для программиста! в голове вопрос " а не инопланетянин ли вы? че я хотел ? ах да! не зарывайте свой талант если что, лучше продолжайте учить новичков и делайте замечательные игры дальше, а то флеш игр навалом, а нормальных игр мало!
зы у меня даж из головы вылетели те глупые статьи, типачто нужен второй человек для игры...
зыы спасибо за внимание!

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

Тоже использую отрисовку сначала в буфер битмапдата, а затем в конце в передаю все битмапе. �?спользую draw только когда, что-то изменил в обьекте, для этого просто добавил флаг в обьект.
Такой способ остался еще с делфи, там без буферов никуда.

@don-andreas
Не обманывайте себя, Карлов и Хитри в нашем случае уникальные люди. (:

@Midnight и @Sergey Batishchev да, точно! Про совмещение ручного рендера с привычными спрайтами, кнопками и текстовыми метками для реализации игровых меню я уже подумал после того как написал запись :)

@don-andreas, вот тут на первое апреля один из товарищей пошутил на эту тему, рассказав про новый Tween Pro ;) К сожалению (или к счастью) такой возможности нет. Но если разобраться с Shape Tween то можно получить похожи эффект. Вот здесь есть хороший урок на эту тему...

@don-andreas, на самом деле я знаю еще много человек которые выступают одновременно художниками и программистами. Чаще всего такие люди делают тру инди игры о которых мы мало чего знаем :) Конечно код и графика получается у всех на разном уровне, но это не отменяет того факта, что над игрой работает один человек.

MineCraft вроде тоже изначально один человек создал. Это сейчас только вокруг этой игры собралась небольшая команда, если я не ошибаюсь конечно :)

В общем тут главное желание, стремление и понимание некоторых граней...

@genm, пока ковырялся с этими примерами и с пикселями, вспомнил как давным давно на Delphi пытался писать игры с использованием Canvas... Счастливое детство :)

@elmortem, на самом деле таких как мы не один и не два, нас больше! :)

Держи Антон:
http://blog.iainlobb.com/2010/11/bunnylandmark-new-flash-game-benchmark.html

Когда запустил последнюю демо, сразу понял о чем остальной пост =)

Отличная статья Антон. В скором времени мне понадобится тоже самое. Спасибо.

@krylover, зря не дочитал пост ;) По приведенной ссылки очень упрощенный бенчмарк. Там только copyPixels() и исключительно битмапы используются без каких либо анимаций и трансформаций.

Антон, еще можно подождать когда выйдет Molehill, наверняка ты видел демки с M2D ?
Там хоть 100000 объектов на 60 fps рендерится)

Во флешпанке автор позаботился о проблеме с интерфейсом и предоставил стейдж: :)
FP.stage.addChild(myWindow);

@neelts, во Flash Player 10.2 тоже есть аппаратная поддержка и что-то как-то не очень результаты. Хочется, конечно верить, что новый плеер с Molehill будет полноценно использовать аппаратное ускорение, например на уровне с Unity3D. Но Molehill выйдет в бета тестирование только в 2012 году, а когда еще случится релиз и сколько времени еще пройдет прежде чем его установит большая часть пользователей на свои компьютеры!? В общем очень долго ждать его... :(

@Dragosha, во Flixel тоже не сложно добавить указатель на stage в глобальное хранилище если нужно. В файле FlxG.as добавляем статическую публичную переменную:

public static var stage:Stage = null;

А в файле FlxGame.as в методе create(), сразу после строчки stage.frameRate = _framerate, добавляем строчку:

FlxG.stage = stage;

После чего в коде где угодно можно получить доступ к stage так же как и во FlashPunk ;)

FlxG.stage.addChild(myWindow);

Растеризация наше все =).

А проверял как быть с анимацией большого размера? Мы натолкнулись на проблему связанную с тем, что большие размеры (раза в 2-3 больше дракона), с большим объемом анимации (порядка 200 кадров) легко выйдут за придел 1gb, чем подвесят флеш. Конечно при условии, что таких объектов еще несколько на сцене.

Пока нашли 2 решения:
а) запретить аниматорам рисовать большие анимированные объекты;
б) растеризация на-лету;

более элегантного решения пока не подвернулось :(

@ant-karlov
Molehill уже в бете (я себе уже поставил). А в начале 2012 ожидается уже официальный релиз

@Hyzhak:
Мне кажется, проблема сильно преувеличена. В 1 гигабайт можно уместить изображение размером
32768 х 32768 пикселей в 32 битном ARGB формате. Это 2621 кадр размером 640х640 пикселей.
Естественно в реальности это изображение разбивается на несколько частей, ни одна видеокарта такую текстуру в памяти не создаст.

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

А аниматорам нужно руку жать, за желание рисовать большие анимированные объекты.

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

Эта граница получена несложным подсчетом (посчитайте сами), заголовок текстуры весит несколько байт, поэтому учитывались только пиксели текстуры.

А реальная игра может и больше выжирать, качество графики тут ни при чем. Вот только флеш игры разумно (а главное, всегда можно!) делать легковесными и не загружающими компьютер на полную катушку.
А не то любимый проигрыватель, так горячо любимого нами игрока перестанет ему играть его любимую песню группы Тутси (ибо все ресурсы сожрала пупер гама в соседней вкладке) и он обидится и не будет больше в вашу игру играть. Простите за тонны тафталогии. :)

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

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

@Zaphod, если я не ошибаюсь, то то что вы себе поставили - это не бета версия, это Incubator версия для публичной демонстрации новых возможностей будущего плеера. Сам же Molehill api в данный момент доступен только избранным разработчикам. �? если мне не изменяет память, то Антон Волков на последнем FlashGAMM говорил про выход бетаверсии нового плеера в начале 2012 года, а релиз еще через пол года.

@BuxomBerry большое спасибо за идею "решетки спрайтов", с удовольствием попробую ее воплотить =)

На самом деле уже можно работать с Molehill - есть справочник и библиотека для разработки (playerglobal.swc)
ссылка 1
ссылка 2

Другое дело, что пока не вышел релиз плеера это не очень актуально.

Для больших битмап встречалось несколько решений. Например BigAssCanvas

Очень интересная и актуальная статья, Антон. А я вот все никак не могу начать растеризировать обьекты в своей игре, поскольку их немного и вроде пока-что не тормозят.

@Ant.Karlov, я бы не спешил создавать фреймворк, где отрисовка всех объектов производится в буфер (ваш screen:Bitmap), а затем он выводится на экран. Мой совет - делайте его универсальным, чтобы он работал без буфера. Рано или поздно во флеше основным рендером будет рендеринг с использованием GPU. В этом случае по вашей методике флеш сначала нарисует все программно в буфер, а затем, когда его нужно будет отобразить на экране, загонит буфер в текстуру и текстуру передаст в видеопамять. Этот процесс передачи занимает кучу времени (поэтому и существуют пиксель-шейдеры) и ваш фреймворк в режиме GPU может работать в несколько раз медленнее, чем самые обычные MovieClip`ы (с cacheAsBitmap) просто добавленные на сцену, отрисовкой которых заботится сам флеш. Уже сейчас это заметно на мобильном флеш-плеере.

@Ant-Karlov:
А как дела обстоят с очень медленными движениями и поворотами клипов (смещения меньше чем на пиксель и поворот меньше чем на градус)? Движение рывками сохраняется? А в режиме низкого качества в плейере?

По демкам не смог определить.

Поддерживаю BuxomBerry:
�?нтересно посмотреть на медленное движение по горизонтали

@Flasher, справочника по ссылкам не нашел, может плохо искал? Есть много демок, сам плеер и несколько статей по которым можно лишь понять что и как работает. Но для глубокого изучения этого не достаточно. На мой взгляд информации по Molehill сейчас очень мало потому что API еще в глубокой разработке и API постоянно меняется.

@programmer, а без буфера куда спрайты рендерить? Вариант с растеризацией клипов и использованием стандартного Sprite для рендера — я как раз представил в этой записи для сравнения производительности. Так же в этой записи для тестирования я уже использовал плеер для тестов с аппаратной поддержкой.

Если под полной аппаратной поддержкой подразумевается Flash Player 11 с Molehill, то если я не ошибаюсь, для полной аппаратной поддержки прийдется уже работать с треугольниками и полигонами, а для этого в любом случае нужно будет писать совсем другой фреймворк или использовать сторонний. Adobe не обещала нативных инструментов для работы с Molehill API.

В любом случае до того счастливого момента когда вся эта аппаратная поддержка станет доступной, пройдет еще минимум год-полтора. А простецкий фремворк для быстрой работы с графикой написать можно за 2-3 недели и сделать на нем еще много игр ;)

Во второй ссылке:
http://download.../flashplayer_inc_langref_022711.zip

Ну и сейчас практически все основные 3Д движки молехилл-реди ;)

@BuxomBerry и @Flasher, да при смещениях меньше чем на пиксель попиксельные рывки остаются. �?деальную плавность можно получить только с аппаратной поддержкой, а в данном же случае мы все равно работаем с пикселями. Пример ссылка...

Код движения в примере такой:
velocity.x = Math.random();
angularVelocity = Math.random();
dragon.x += velocity.x;
dragon.angle += angularVelocity;
Поэтому жмите кнопку «Обновить» чтобы увидеть разную скорость движения ;)

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

Но при ручном рендере решается другая проблема: например у меня в Zombotron при использовании Sprite и Bitmap во время скролла карты все объекты дергаются — смещаются не синхронно. То есть смещаются они равномерно, но рендерятся по разному, как будто для одних спрайтов координаты округляются методом Math.ceil(), а для других Math.floor(). �?з-за этого получается эффект дрожания объектов :( Если смотреть внимательно ролик Зомботрона, то можно заменить как подергиваются ящики и бочки во время движения карты. Аналогичный эффект есть и в Mining Truck 2, но там он был менее заметен потому что скорость скролла карты большая, но можно видеть дрожание грузов или деталей моста если ехать медленно. �? это для меня на данный момент самая большая проблема стандартного рендера Flash которая никак не лечится стандартными средствами и именно из-за нее я начал ковырять эту тему.

@Flasher, спасибо за ссылку! Действительно плохо посмотрел. Документация — это уже намного интереснее, но все равно скорее всего до релиза еще не раз все поменяется :) На досуге почитаю.

Ant.Karlov@ Аналогично наблюдаю в своей новой игре асинхронное дерганье объектов. Особенно неприятно когда становиться видно составные части текстур.

@Ant.Karlov

Как применять MoleHill для 2D графике лучше смотреть на исходниках:

http://www.flashrealtime.com/m2d/

там есть кое какие хитрости с AGAL (Adobe Graphic Assembler Language), А в целом прав. Вывод любого спрайта осуществляется с помощью 2х треугольников.

Если заложить гибкость (к примеру шаблоном "Адаптер" http://en.wikipedia.org/wiki/Adapter_pattern) в фреймворк, то можно в любой момент переключаться между MoleHill и традиционными BitmapData.

@Ant-Karlov:
Но ведь при отрисовке методом draw все равно используется Flash vector render и получается, что для растеризации трансформированных изображений используются те же неточные алгоритмы. Почему же проблема со скролингом решилась? Ты проверял скролинг со скоростью смещения меньше одного пикселя?

Вообще довольно неприятная особенность, когда работаешь с графикой, ожидаешь что смещение на 0.5 пикселя будет выдавать результат только каждые 2 кадра. Т.е. картинка будет смещатся в любом случае на 1 пиксель, но просто не сразу. А тут растры рисуются с рывками, да еще и в разные стороны. А если вырубить интерполяцию (поставить качество плейера на низкое) то вообще ужас начинается, рывки фантастические (особенно при поворотах). Мне кажется рендер Flash`а использует для трансформации растров хоть и быстрые алгоритмы, но сильно в ущерб точности вычислений и это печально.

По идее рывки в такой ситуации могут исчезнуть только если использовать целые числа для координат. �? не применять масштабирования и поворотов ни в каком виде, кроме заранее разстеризованных в страйп или последовательность изображений. (Масштабирование в 2n раз и повороты на 90 градусов не в счет).

@Hyzhak, по приведенной ссылке представлен простой фремворк m2d который использует Molehill API для рендера 2D графики. Демки и исходники я правда еще не смотрел, но из описания и так все понятно :) То есть когда Molehill API станет более доступным, все равно прийдется смотреть на него под новым углом и писать отличающийся движок от того как мы сейчас работаем с битмапами.

За ссылку на паттерн «Адаптер» спасибо! :)

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

На самом деле, мне кажется, что проблема асинхронного смещения отдельных объектов кроется не столько в Flash рендере сколько где-то в реализации объектов DisplayObject. Но с уверенностью мне сейчас что-то утверждать очень сложно. Нужно экспериментировать, а у меня со временем туго, так как уже выбиваюсь из срока разработки новой игры :( Обязательно займусь плотно этим вопросом когда немного разделаюсь с игрой :)

@Ant.Karlov
очень интересно Ваше мнение о nape, по тестам ведь он будет пошустрее Box2D.

@Ant.Karlov
и еще такой вопрос.
как бы утроить обсчет физики в игре платформере с 2.5D видом. (как в double dragon, герои могут ходить вниз-вверх и еще прыгать).
мне пока на ум приходит только сделать вручную разбивку на слои. но это как-то глупо наверное.

Во flixel доступ к stage, осуществляется через FlxG.stage он там сразу есть, добавлять не надо. Еще FlxState наследуюется от Sprite, можно ChildAdd использовать.
Но, честно говоря я сильно расстроился во стандартном флешевском рендере, когда попробовал сделать простенькую анимацацию большего интерфейса. Хочу выдрать flixelовский рендерер, чтобы он для простых Sprite рисовал, и я мог сделать несколько слоев.. Но это все мечты :)
Насчет обрисовки рамкой - незнал, сейчас пойду выдерну этот код из движка :). У меня весь фликсел порезаный на куски, с кучей закоментированного кода :). А еще недавно подключил Box2D и Nape ^_^. Правда, подумываю отказаться от этого, и использовать поверх буффера flixel простые векторные модельки. Может быстрее заработает.

Удачке Антоха! Надеюсь получится что нибудь типа Flixel и ты дашь в свободное пользование свой движек. Я бы, честно говоря, помог в написании

Небольшой вопрос. При использовании copyPixels и draw неизбежен pixelSnapping, то есть копируемое изображение будет подгоняться попиксельно и сдвиг на float координаты невезможен, так? или возможно это как то побороть?

@nodoxi, я не пробовал Nape и не тестировал его производительность по сравнению с Box2D поэтому ничего определенного по этому поводу не могу сказать. Знаю только, что в Nape есть радикальные отличия от Box2D за счет чего ведет он себя иначе и судя по отзывам в некоторых случаях производительнее, но есть и свои недостатки.

@nodoxi можно сделать сортировку по глубине, в flixel для этого есть даже команда.

@nodoxi, для реализации такого вида на Box2D можно использовать фильтры для разделения объектов на физические группы, за приделами которых физ объекты не будут сталкиваться друг с другом. Только вот мне не доводилось менять фильтр для проверки столкновений после создания физического тела и я не уверен, что это можно сделать в runtime. Но даже если нельзя менять фильтр для проверки столкновений после создания физ.тела, то тут можно обойтись и без этого.

@WeslomPo, скорее всего я просто не заметил переменной с указателем на stage во FlxG.as :)

Кстати, судя по всему ты плохо расковырял Flixel так как в нем существует возможность создавать сколько угодно слоев! Просто в классе FlxState.as используется стандартная группа объектов defaultGroup:FlxGroup но на самом деле тебе никто не мешает создать подобных групп сколько угодно в игре и процессить/рендерить их в нужной тебе последовательности ;) Например:

var _frontLayer:FlxGroup = new FlxGroup();
add(_frontLayer);

var frontSprite:FlxSprite = new FlxSprite();
// ... здесь инициализируем графику спрайта
_frontLayer.add(frontSprite);

Так же я не вижу никакой проблемы в том чтобы использовать FlxSprite для рендера физики Box2D или Nape без использования «векторных моделек» :)

Если таки доберусь до движка своего и из этого получится что-то интересное, то конечно поделюсь с общественностью :)

@zaynyatyi, да в любом случае получается привязка к пикселям и если двигать спрайт со скоростью менее чем 1pix, то двигаться он будет все равно по пиксельно.

Но только что, в ходе эксперимента я обнаружил маленький трик который позволяет получить абсолютную плавность при движении объектов со скоростью менее 1pix, смотрим пример...

velocity.x = Math.random();
smoothing = true;
angle = 0.0001;
Для отрисовки используется метод draw().

Весь трик заключается в небольшом угле поворота и включенном сглаживании. Но если включить низкую настройку графики в плеере, то будет ОЙ :)

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

Сомнительная польза от этого трика. Проблема вращения не решена и для спрайтов побольше он вовсе не работает.
Я где-то даже видел из подобных соображений предлагали рисовать спрайт два раза за кадр, первая отрисовка делалась на 0.5 пикселя левее (или правее в зависимости от направления движения) следующей из-за чего создавался эффект похожий на интерполяцию (или слабый моушен блюр). Но это все пустая возня.

Ant.Karlov можно урок по рисованию Зомби из Zombotron?
Очень нравится ваш стиль*

@TRaY, что вас интересует в рисовании зомби? Скетч персонажа сделан на бумажке, потом отсканирован и обводка с раскраской уже делалась во Flash, в целом подход к рисованию используется точно такой же как и к рисованию грузовика/домика/дерева. Видео процесса рисования зомби я к сожалению не записывал.

@BuxomBerry, польза безусловно сомнительная, просто случайно обнаружил такую вот странность :) Думаю, что идеальную плавность мы получим только с полной аппаратной поддержкой.

@Ant.Karlov, да я в курсе про FlxGroup, как никак основной инструмент :) пишу на фликселе с сентября прошлого года).

Я имел в виду, чтобы можно было сделать несколько FlxState-ов, которые бы могли жить паралелльно. Сейчас, например, чтобы перейти из одного State в другой, нужно их создавать заново, и передавать управление, а хочется чтобы они были статическими, и могли быть оба активными. Это позволило бы делать переходы между уровнями и меню плавными простым изменением alpha или положения в пространстве flash, вставлять flixel в любое flash приложение как Sprite. Думаю, это нашло бы применение в каких нибудь проектах, где нужны миниигры, но сам проект приследуют другие цели (например приложение вконтакте).

кстати Adam `Atomic` Saltsman, как раз сейчас взялся за модернизацию flixel-а, думаю его можно попросить пофиксить проблему с рамками.

"Весь трик заключается в небольшом угле поворота и включенном сглаживании."

Если присмотреться, то видно, что картинка при перемещении немного меняется (четче, видимо, на целых пикселях)

Насколько я помню, еще можно использовать не угол, а масштабирование (scaleX = scaleY = 1.0001);

@Ant.Karlov
да, для простейшей реализации 2.5d можно раскидать всё по FlxGroup/фильтрам коллизий. но собственно сколько это будет слоев. я сделал прототип с тремя слоями. но пока не очень доволен результатом.

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

Вот умеют же люди! =) http://www.newgrounds.com/portal/view/567520

Ant.Karlov меня интересует раскраска!
Можете хотя бы сделать видеоурок по рисованию какого нибудь персонажа (наподобие главного героя из Zombotron) в вашем стиле?
Тоесть заснять процесс раскраски.

@WeslomPo, вначале показалось что там очень просто сделать поддержку нескольких FlxState`ов одновременно. Но внимательно по размышляв на эту тему оказалось что не все так просто из-за общего буффера. �? на деле чтобы добавить такую возможность нужно хорошенько поработать над изменением архитектуры всего движка.

Кстати в базовом классе FlxState.as есть свой screen, в комментарии к которому написано, что вы якобы можете работать с ним, но я не очень понял как и зачем его использовать. Может быть его можно использовать как скрин для каждого отдельного State?

@Hyzhak, проблему с рамками можно и самостоятельно исправить в течении 5 минут. Тут просто может быть что еще где-то в движке создаются отладочные ресурсы всегда.

@Flasher,

> Если присмотреться, то видно, что картинка при перемещении немного меняется (четче, видимо, на целых пикселях)

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

@nodoxi, по физике Flixel мне сложно что-то однозначно посоветовать. Я подумал, что для реализации игры с таким видом будет использоваться Box2D :)

@Если есть, Nitrome вообще большие молодцы! У них почти все игры отличные :)

@TRaY, с персонажами у меня всегда много возьни поэтому процесс их создания и анимации я не разу не записывал. Хотя в последнее время вроде все быстрее стало получатся. Подумаю еще над тем стоит ли записывать процесс создания персонажа.

Ant.Karlov давай!

@Ant.Karlov
так Box2D и используется )
просто выше был предложен вариант с FlxGroup. я и использовал эту терминологию.

@nodoxi
Многослойную фильтрацию можно сделать через связку categoryBits и maskBits, таким образом будет доступно 32 уровня глубины. При перемещении объекта между слоями соответствующие им биты выставляются в единицы, также при таком способе фильтрования очень просто сделать объект находящийся одновременно в нескольких слоях. При смене фильтрации на лету нужно вызывать метод Refilter у b2World (2.0.2)

Антон, посмотри, какое чудо нашел на фгл:

http://www.flashgamelicense.com/view_game.php?game_id=1482 5

Не знаю, в курсе ты или нет, на всякий случай выкладываю.

Заимствованный арт, геймплей, даже левелдизайн. Чистый клоняра.

Автор некто illia dneprov.

Сорри, что-то линк покоробился. Правильная ссылочка:
http://www.flashgamelicense.com/view_game.php?game_id=14825

@Platon Skedow, чесно говоря в чем тут клон? графа другая уровни другие общего то что мужик бегает и чето двигает. Я думаю не клон это. Что теперь все игры в жанре платформер с мужиком каторый чето двигает и чето собирает клоны грибника чтоли? Тогда уж и грибник клона санты :)))

2 �?ван.
Ого как 0_о
Советую запустить рядом грибника и этого вот дровосека.

�?гры действительно очень похожи механикой. Очевидно автор ориентировался на грибника. Но все же эту поделку до уровня грибника еще пилить и пилить. В ней нет жилки, которая заставит снова и снова нажимать "next level"

@Platon Skedow, Woodcutter я уже видел ранее. С точки зрения клонирования игры, претензий к разработчику я не имею. Графика нарисована с нуля, код тоже свой, а что до игровой механики то на её авторство я не претендую. Любая другая схожесть с Mushroomer уже на совести автора.

@Ant.Karlov
а очищение экрана как у тебя реализовано? каждый фрейм заливка прозрачным цветом?

@zaynyatyi, прозрачным цветом бесполезно заливать ;) Варианта два:

1. Рисовать прямоугольник с заданным цветом и размерами с рабочий буффер (размер экрана);

2. Не очищать экран вообще — это быстрее и удобнее если каждый кадр вместе с задниками рисуется целиком заново.

connectionBitmapData.fillRect(connectionBitmap.rect, 0x00000000); - я вот так делаю, в принципе очищает, но производительность падает, если каждый фрейм делать. Но тут я весь фон заливаю, сейчас попробую переделать только на видимую область. Что то сегодня голова не варит совсем.
А если не очищать, то углы (edges) у изображений с прозрачным фоном становятся всё более и более резкими.

@zaynyatyi, а какого размера рабочий буффер куда отрисвываются все игровые объекты?

По идеи, основной буффер не должен превышать размеры игрового окна. То есть, например, если в игре разрешение 640x480 то и буффер для рендера объектов должен быть таким же размером. При этом необходимо выполнять проверку на видимость спрайтов и если спрайты целиком за приделами экрана, то тогда их рендерить не нужно. Заливка 640x480 выполняется достаточно быстро. Но если в игре используются статичные/динамические бэкграунды на весь экран, то буфер вовсе можно не очищать рисуя новый кадр прямо по верх старого.

@Ant.Karlov
основной буффер 2500х2000, просто изначально пошел не по тому пути (рисовал не в общем буффере, а каждый объект в своем спрайте). Сейчас оптимизирую производительность. Подумал, может упустил способ "удаления" объектов с битмап даты. Например попиксельным xor. Очистку только видимой части совсем упустил из виду (чистил весь буффер), вот и терял 5-6 фпс. Сейчас чищу только видимую область, просадки нет. Спасибо.

ОМГ, попиксельный XOR меня просто убил... zaynyatyi, вы чего с ума сходите, какие нафик буферы на 2500х2000?!

Берете создаете битмап на 640х480, смещаете его x,y в мировых координатах так, чтобы он всегда был виден на экране целиком и отрисовываете в него методом draw каждый объект поочередно, исключая те объекты, чьи координаты не лежат внутри прямоугольника этого битмапа в мировых координатах.

Потом, битмап никогда специально не очищается (это глупая трата ресурсов), он перекрашивается! У вас в игре есть фон и даже если он монотонный, он все равно перекрашивает полностью старые данные в битмапе.

Про удаление объектов XOR`ом вообще для меня загадка. Но чтобы вы ни имели ввиду, забудьте про попиксельную обработку, забудьте!

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

Ant.Karlov снимай уже процесс рисования персонажа, неделю жду!

Ободряющая статейка:) уже с НГ стал копать в сторону собственного рендеринга, но работал я с большими битмапдатами 5000+, в ходе всяческих тестирований узнал много заковырок. �? вот уже было хотел сам пошаманить с большим количеством относительно мелких объектов. �? как вовремя попал на статью ... всегда приятно осознавать что движешся в верном направлении :)
Спасибо Антон! Гуджоб!

А вот как при использовании copyPixels сохранить blendmode ? �?ными словами как blending mode работал при копировании и накладывании одних пиксеей на другие?

@Shaman4d:
Никак. copyPixels просто копирует данные из одного участка памяти в другой, никакой работы с цветовой информацией не осуществляется. Поэтому он и работает быстрее чем draw.

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

Здравствуйте Антон!
У меня остро встал вопрос об оптимизации. При не очень интенсивных боевых действиях на карте, происходит просадка FPS к 10. Профайлер показывает:
[pre-render] - 43%
[render] – 33%
[execute-queued] – 7%
а вот [enterFrameEvent] – 17%

Отсюда вывод – нужно что-то делать с 83% процентами на отрисовку объектов.
Перечитал достаточно материала, но все попытки применить на практике кэширование в растр заканчиваются провалом. Тормоза становятся еще серьезней. По-моему проблема в непонимании основ. Как в существующей архитектуре Universe применить рисование в битмапу?
1.При старте уровня, все необходимые динамические объекты прокручиваются покадрово и перегоняются в BitmapData.
2.Это должен быть спец.клас CachedMovieClip реализующий функционал MovieClip (gotoAndStop/gotoAndPlay/Play/Stop/currentFrame/totalFrame/[/b]rotation/mask[b]!!!) и содержащий в себе Vector.<BitmapData> (для всех кадра)
3.Все графические объекты TowerBase, EnemyBase, BulletBase… порождаются от него.
4.В обработчике enterFrameHandler после работы функций update требуется отобразить BitmapData полученные от enemies, towers, bullets в единственную главную Bitmap игрового поля.
Как должно быть на самом деле? Куда данные кешируются, кто за это ответственен, как накладываются маски, повороты сильно портят качество картинки, как быть с управлением глубиной отображения, перестает работать получением объектов под курсором getObjectsUnderPoint…
Я понимаю, что это очень объемная тема, но хотя бы основы архитектуры…
Спасибо.

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

конфигурация -
Intel Core i5 2.8GHz, 4 ядрышка. Озу - 4ГБ. Nvidia GeForce GT 530

тестирование 1:
1)фпс~40
2)фпс~60

тестирование 2:
1)фпс~60
2)фпс~60
3)фпс~60