Аппаратное ускорение перед сотой - PullRequest
Новая
       19

Аппаратное ускорение перед сотой

1 голос
/ 06 марта 2012

Я играю с Android API с долгосрочной перспективой разработки 2D-игры. Обычно я мог бы жить с использованием Canvas для рисования спрайтов в качестве графики для моей игры. Я хотел бы иметь возможность рисовать много для визуальных эффектов, но кажется, что версии Android до Honeycomb (3.0, API уровня 11) не поддерживают аппаратное ускорение .

Я не уверен, что это значит. Я не могу заставить себя поверить, что рисование выполняется процессором, пиксель за пикселем!?! Если у меня будут такие эффекты, как свечение, линзы и т. Д., Я буду рисовать каждый пиксель несколько раз. Правильно ли я считаю, что типичный процессор для смартфона не справится с этим при ~ 30 FPS?

У меня нет роскоши нацеливаться на версии Android> = 3.0, поскольку они составляют 8% на уже не столь большом рынке Android. Должен ли я не торопиться с OpenGL (я новичок в OpenGL)? Если я сделаю это, как вы думаете, я получу что-нибудь, наложив GLSurfaceView, заботясь об эффектах поверх пользовательского представления Android, используя Canvas, чтобы сделать рисование иначе. Или это по какой-то причине плохая идея смешать два?

1 Ответ

4 голосов
/ 06 марта 2012

О Боже, да.Особенно, если вы нацелены на устройства до Android 3, переход от SurfaceView (с вызовами Canvas.drawXxx ()) к OpenGlSurface прекрасно работает.Мало того, что у вас более быстрые кадры (обновления) в секунду, но потребление памяти ОЧЕНЬ лучше.

Вот некоторые моменты, которые я заметил:

  • Если вы хотите сделать(мульти) спрайтовые анимации, выполнение их с изображениями, загруженными в виде текстур OpenGL и отображенными в квадрате OpenGL, дает вам гораздо больше места в памяти.Это связано с тем, что хотя обычные растровые объекты ограничены пределом памяти Android-процесса (который составляет около 16-48 МБ, в зависимости от устройства и версии Android), создание текстур OpenGL из этих изображений (и очистка iamges сразу после) не имеет этого ограничения.Вы ограничены только общим объемом памяти устройства, который ОЧЕНЬ больше, чем 16-48 мегабайт.

Во-вторых, но все еще с этим связано, Android 2 и ниже отслеживают, сколько памятиВзятие экземпляров растрового изображения намного сложнее, поскольку эти экземпляры не передаются в память кучи Java.Они расположены в каком-то другом пространстве памяти.Короче говоря, еще меньше хлопот, если вы используете OpenGL.

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

  • Если вы играете в 2D-игру, использование ортогональной проекции OpenGL не только значительно упрощает (в данном случае бесполезно)хлопот, которые у вас возникли бы с обычной перспективной проекцией OpenGL, но на самом деле это облегчает множество проблем, с которыми вы столкнетесь с обычным SurfaceView, когда нужно масштабировать все ваши графические элементы, чтобы они выглядели одинаково на разных разрешениях экрана / пропорциях,С помощью ортогональной проекции OpenGL вы эффективно создаете фиксированную область желаемой высоты и высоты, а затем автоматически проецируете ее OpenGL на область экрана устройства.

  • Само собой разумеется, что создание простых эффектов, таких какпульсирующий свет, влияющий на некоторый графический элемент, гораздо проще сделать с OpenGL (где вы просто делаете свет и пульсируете им, и все горит соответствующим образом), чем моделировать его с помощью SurfaceView и запекать в спрайтах.

На самом деле я запустил небольшую игру, похожую на астериодную защиту, с SurfaceView и Canvas, а затем быстро переключился на OpenGL по указанным выше причинам.Короче говоря, игра теперь выглядит лучше, и хотя первоначально она работала с 16 ИБП на Samsung TEOS и 30 ИБП на Optimus LG 2x, теперь она работает с 33 ИБП на Teos и около 80 ИБП на LG 2x.

...