Простая система частиц на Android с использованием OpenGL ES 1.0

Я пытаюсь собрать систему частиц в Android, используя OpenGL. Мне нужно несколько тысяч частиц, большая часть которых, вероятно, будет за кадром в любой момент времени. Визуально это довольно простые частицы, а мой мир 2D, но они будут двигаться, менять цвет (не размер — они 2x2), и тогда мне нужно будет иметь возможность добавлять и удалять их.

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

Я написал систему для поддержки статических частиц, которые я загрузил в vertex/colorarray и построил с помощью glDrawArrays, но этот подход кажется подходящим только для частиц, которые никогда не изменят относительное положение (т.е. я перемещаю их все, используя glTranslate), цвет и где мне не нужно добавлять/удалять частицы. Несколько тестов на моем телефоне (HTC Desire) показывают, что попытка изменить содержимое этих массивов (которые представляют собой ByteBuffers, на которые указывает OpenGL) выполняется очень медленно.

Возможно, есть какой-то способ вручную написать экран с процессором. Если я просто рисую точки 1x1/2x2 на экране, и меня интересует только запись, а не смешивание/сглаживание, это вариант? Будет ли это быстрее, чем то, что делает OpenGl?

(200 или около того частиц на машине с тактовой частотой 1 ГГц и мегабайтами оперативной памяти. Это намного медленнее, чем я получал 20 лет назад на машине с тактовой частотой 7 МГц и оперативной памятью ‹500 тыс.! Я ценю, что использую здесь Java, но, безусловно, лучшее решение Должен ли я использовать NDK, чтобы получить мощь С++, или это то, что мне нужно)


person Community    schedule 19.02.2011    source источник


Ответы (1)


Я надеялся, что кто-нибудь может ответить на этот вопрос окончательно, так как мне самому понадобятся частицы на Android. (Однако я работаю на C++ -- в настоящее время использую glDrawArrays(), но еще не довел частицы до предела.)

Я нашел эту тему на gamedev.stackexchange.com (не специфично для Android), и никто не может договориться о наилучшем подходе, но вы можете попробовать кое-что и убедиться в этом сами.

Я собирался предложить glDrawArrays(GL_POINTS, ...) с glPointSize(), но парень, задавший вопрос, казался недовольным этим.

Дайте нам знать, если вы найдете хорошее решение!

person Martin Stone    schedule 21.02.2011
comment
Спасибо за ссылку. glDrawArrays(GL_POINTS) был описан выше. Я только что поэкспериментировал с GL_TRIANGLE_STRIP и двумя треугольниками, и это немного быстрее (возможно, на 5-10%, если мое время точное). Я попытался использовать один треугольник (GL_TRIANGLES), но он мерцал и не казался быстрее. GL_LINES не помог. Это расстраивает, потому что я могу обрабатывать тысячи точек в моем статическом массиве без замедления, но несколько десятков динамических точек (квадратов) полностью убивают его. Я сомневаюсь, что мне сойдет с рук запись в растровое изображение размером с экран, преобразование его в текстуру в каждом кадре и отображение его. - person ; 22.02.2011
comment
После поиска и экспериментов кажется, что у меня нет другого выбора, кроме как установить NDK и сделать это на C++. Кажется очевидным, что у моего телефона нет проблем с рендерингом тысяч точек с помощью одного вызова glDrawArrays, но несколько вызовов DrawArrays (один вызов на точку) просто недостаточно быстры для более чем 20 или 30 точек. Также слишком медленно изменять буфер вершин из Java, поэтому моей первой задачей будет манипулировать им из C++. Возможно, быстрее все еще использовать треугольники (2 треугольника на точку), как это происходит, когда я делаю несколько вызовов в настоящее время, поэтому мне также придется рассчитать время. - person ; 22.02.2011
comment
В итоге использовал NDK и плавает вместо фиксированной точки. Эта страница оказалась полезной ( badlogicgames.com/wiki/index.php/ ). Они утверждают, что использование put с целыми числами происходит медленно из-за ошибки и что это будет исправлено в Android 3.0, но альтернатива использованию чисел с плавающей запятой по-прежнему загружается медленнее, чем их собственное решение (один memcpy в C, что я делать.. ну, два memcpy...) так какая разница, исправят ли они это?! Я все еще использую баллы; накладные расходы на использование отдельных вызовов OpenGL для построения четырехугольника намного медленнее, чем один вызов для построения сотен точек. - person ; 27.02.2011