Использование OpenGL для ускорения 2D-графики

Я и мой друг пытаемся ускорить 2D-игру с помощью OpenGL. Видеочипсет Radeon X1250, кажется, недостаточно мощный и может отображать до 80 полных кадров 1366x768 в секунду. Учитывая, что мы рисуем много спрайтов друг на друге, производительность резко падает ниже 60 FPS, на которые мы нацелены. Не могли бы вы дать советы по оптимизации для быстрого рендеринга 2D с помощью OpenGL?

РЕДАКТИРОВАТЬ: некоторые пояснения: разработка ведется на C ++ под Linux. Мы сделали это с помощью SDL, но производительность была неудовлетворительной, поэтому мы решили переключиться на OpenGL, который оказался намного быстрее. Конечно, тогда был толчок для реализации дополнительных функций, требующих от нас перерисовывать весь экран в каждом кадре.

Наша тестовая программа визуализирует текстурированные четырехугольные плитки 256x256 на экране 1366x768. Если перед заменой буфера уложен один слой тайлов, он дает 80 FPS, если уложены два слоя, частота кадров падает ниже 60 FPS. Учитывая, что от платы потребуется одновременное декодирование и рендеринг некоторых небольших файлов MPEG, это может быть неудовлетворительным.

Я просто подумал, что могу поискать оптимизацию, связанную с тем, что игра является 2D - я подумал, например: 1) можно ли отключить масштабирование текстуры. 2) рендеринг непосредственно в буфер кадра (хотя мы слышали, что glDrawPixels должен быть медленным.


person kyku    schedule 12.10.2009    source источник
comment
Не могли бы вы предоставить код?   -  person James Black    schedule 13.10.2009
comment
Будет полезно, если вы напишете, о каком количестве спрайтов вы говорите. Много 100, 1000, 10000? Тогда будет проще сказать, делаете ли вы что-то не так или как можно оптимизировать.   -  person Foxfire    schedule 13.10.2009


Ответы (5)


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

Если вы перегрузите буфер кадра (особенно в высоком разрешении), то в конечном итоге вы снизите частоту кадров из-за ограничений скорости заполнения карты.

Хотя современные карты могут выполнять множество операций, у них все еще есть ограничение на количество пикселей, которые они могут выдвинуть.

Чтобы уменьшить это, некоторые предложения:

  • Не рисуйте все в каждом кадре - если возможно - визуализируйте некоторые части в других буферах, а затем смешивайте их - с более низким разрешением, если возможно
  • Не используйте смешивание, если оно вам не нужно - смешивание происходит намного медленнее, чем рисование непрозрачных материалов.
  • Используйте более дешевую программу фрагментного шейдера / фрагмента - если вы используете программируемый конвейер (NB: я не знаю, как вы действительно можете определить, насколько это дорого)
  • Используйте как можно больше отбраковки - избегайте рисования вещей, которые вообще не видны. Если спрайт полностью (или почти полностью) скрыт за другими, рисовать его не нужно.
  • Масштабирование / интерполяция, вероятно, относительно дёшево - используйте текстуры с более низким разрешением и масштабируйте их - особенно если ваши текстуры изначально "размытые".

Если вы делаете это, чтобы получить какой-то фанковый эффект дыма / частиц, вы, вероятно, не сможете использовать все или многие из этих оптимизаций.

person MarkR    schedule 13.10.2009
comment
Не могли бы вы подробнее рассказать о том, как не рисовать все в каждом кадре? - person pachanga; 08.06.2013

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

Если вы загружаете на сервер много данных для каждой вершины, убедитесь, что вы храните данные вершин в буферных объектах. Никогда не используйте немедленный режим, также известный как пары glBegin / glEnd. Вместо этого используйте glDrawArrays, glDrawElements или другой вызов отрисовки массива. Это уже дает огромный прирост производительности.

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

Если эти советы не помогают, я рекомендую вам проверить, действительно ли ваше приложение привязано к графическому процессору. У меня есть сомнения. Узкое место могло быть где-то еще. Возможно, ваш X visual / FBConfig не имеет аппаратного ускорения?

person Community    schedule 12.10.2009

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

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

Какую часть экрана вы воссоздаете? Например, вы регенерируете каждый объект, а не просто переводите его?

Вы можете найти полезный вопрос: Что такое какие рекомендации по программированию OpenGL (особенно по объектной ориентации)?

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

Если вы просто использовали каркас, без заливки или текстуры, как ваши результаты?

Как выглядит ваш игровой цикл? Например, есть ли взаимодействие с мышью или клавиатурой и влияет ли эта логика на частоту кадров?

У меня была эта проблема в какой-то момент, когда я перерисовывал 70 кадров в секунду, но моя музыка не начиналась и не заканчивалась за правильную миллисекунду, поэтому я изменяю цикл, чтобы делать только 30 кадров в секунду, и увеличиваю частоту обработки музыки, и моя производительность увеличилась. .

person James Black    schedule 12.10.2009

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

Но остальные комментарии верны. Невозможно сказать, как можно ускорить работу с таким небольшим количеством информации ...

person Goz    schedule 12.10.2009

Вы уверены, что рендеринг является проблемой, или у вас есть логика, связанная с рендерингом? Оптимизация производительности в OpenGL - довольно большая тема, поэтому я просто укажу вам ресурс.

Первая ссылка в Google

person Stefan Kendall    schedule 12.10.2009