Производительность Flash для игры dev: собственный рендер VS BitmapData framebuffer

Ответ 1

Обновление: спасибо за версию с высоким напряжением. Опять же, я не мог видеть разницу, которая просто бегала. Но я ловко сообразил, что "r" бросает башенки, и когда я уронил 20-30 башен, родной вариант был несколько медленнее, чем ручной, так что, возможно, я ошибся. (Я не видел разницы в использовании памяти.) По-прежнему кажется, что делать что-то изначально должно быть возможно быстрее, но вполне возможно, что для этого потребуется специализированная обработка некоторого непрозрачного вида.

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

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

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

Ответ 2

Я нашел, что обычная (растровая версия) версия была намного быстрее и ожидала этого.

Flash DisplayList предназначен для учета огромного количества различий в DisplayObjects и, как результат, не будет наиболее эффективным маршрутом (если вы не учтете все эти отклонения самостоятельно в AS3, ll проиграю собственный код).

Например, для рендеринга фрагментов (где вы делаете copyPixels для плит), пользовательский рендеринг растровых изображений будет намного быстрее, чем сотни DisplayObjects в DisplayList. Вероятно, вы также можете использовать специализированный клипер, чтобы вырезать фрагменты, тогда как Flash заканчивает выполнение очень общих вычислений и тестов ограниченной рамки.

В re: отклонениях, например, в вашей пользовательской версии, "строительный" спрайт качается, когда символ перемещается, вероятно, из-за преобразования float-to-int или округления вместо округления в вашем коде.

Ответ 3

Если вы делаете сотни или тысячи объектов на экране (например, с интенсивными эффектами частиц), тогда у вас будет более высокая производительность с помощью CopyPixels.

Многое из этого зависит только от того, что вы пытаетесь сделать, правильно?

Ответ 4

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

Ответ 5

У меня ноутбук с низким уровнем доступа, Intel Mobile 1.6Ghz/512MB, Firefox 3.5.x, Flash10.0.32.18, WinXP

Я могу очистить видеть большую разницу.

родная версия: менее 10 сек. идет до CPU99%, и движение вяло. пользовательская версия: остается ниже

Btw, есть ли шанс получить пример кода в качестве упражнения.