Флэш-производительность для игрового разработчика: встроенный рендер против кадрового буфера BitmapData - PullRequest
20 голосов
/ 19 июня 2009

Я разрабатываю 2D шутер с множеством объектов и агрессивной прокруткой .

ВОПРОС: какой путь лучше?

CHOICE 1 - использовать встроенный рендеринг Flash:

  • извлекает игровые объекты из Bitmap, использует существующие x, y, width, height, bitmapData
  • добавить все объекты как дочерние UIComponent.addChild (...) на экран
  • обрезать видимую область с помощью scrollRect

CHOICE 2 - написать собственный рендеринг, используя «bitmap + copyPixels»

  • использовать собственный игровой объект с x, y, шириной, высотой, bitmapData
  • добавить растровое изображение на экран, взять с него bitmapData
  • перерисовывает каждый ENTER_FRAME: bitmapData.lock (), перебирает игровые объекты и copyPixels () в bitmapData, затем bitmapData.unlock ()
  • пользовательское вырезание: не отображать объекты на экране

Здесь, в этом вопросе некоторые люди жалуются, что "bitmap + copyPixels ()" работает медленно.

ЭКСПЕРИМЕНТ: Я реализовал оба метода:

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

Подождите, пока не будет не менее 250 врагов (счетчик над экраном).
ОБНОВЛЕНИЕ: Попробуйте открыть диспетчер задач (или $ top) и посмотрите общее использование процессора

ОБНОВЛЕНИЕ 2: Я изменил код, теперь икра крипа гораздо быстрее.

Ответы [ 5 ]

4 голосов
/ 21 июля 2009

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

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

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

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

4 голосов
/ 19 июня 2009

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

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

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

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

2 голосов
/ 19 июня 2009

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

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

1 голос
/ 19 июня 2009

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

0 голосов
/ 07 октября 2009

У меня недорогой ноутбук, Intel Mobile 1.6 ГГц / 512 МБ, Firefox 3.5.x, Flash10.0.32.18, WinXP

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

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

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

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