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

Question

Я и мой друг пытаемся ускорить 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 должен быть медленным.

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Вам может пригодиться вопрос: Каковы некоторые рекомендации по кодированию OpenGL (особенно ориентация объекта w.r.t.)?

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

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

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

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

Answer 4

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

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

Answer 5

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

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