Як покращити ефективність дозування

Я розвиваю спрайтову 2D гру для мобільних платформ (платформ) і використовую OpenGL (ну, власне, Irrlicht) для візуалізації графіки. Спочатку я здійснив спрайт-рендерінг простим способом: кожен ігровий об’єкт відображається як квадратик із власним графічним викликом GPU, тобто, якщо у мене було 200 ігрових об'єктів, я робив 200 дзвінків на кадр. Звичайно, це був поганий вибір, і моя гра була повністю пов'язана з процесором, тому що в кожному розіграші GPU притягується невелика кількість центральних процесорів. GPU залишався бездіяльним більшість часу.

Тепер я подумав, що міг би покращити продуктивність, збираючи предмети у великі партії та надаючи ці партії лише кількома дзвінками. Я реалізував пакетну групування (щоб кожен ігровий об'єкт, що ділився однією і тією ж текстурою, відображався в одній партії) і подумав, що моїх проблем немає ... лише для того, щоб дізнатися, що частота кадрів була меншою, ніж раніше.

Чому? Ну, у мене є 200 (і більше) ігрових об’єктів, і вони оновлюються 60 разів за секунду. Кожен кадр я повинен перерахувати нове положення (переклад та обертання) для вершин у процесорі (GPU на мобільних платформах не підтримує екземпляри, тому я не можу це зробити там), і роблю цей розрахунок 48000 в секунду (200 * 60 * 4, оскільки кожен спрайт має 4 вершини) просто здається занадто повільним.

Що я міг би зробити для покращення продуктивності? Всі ігрові об’єкти рухаються / обертаються (майже) кожен кадр, тому мені дійсно доведеться перерахувати вершинні позиції. Єдина оптимізація, яку я міг би придумати, - це оглядова таблиця поворотів, щоб мені не довелося їх обчислювати. Чи допоможуть точкові спрайти? Будь-які неприємні хаки? Ще щось?

Дякую.

Ви використовували мій порт irrlicht для андроїда? Для 2-х спрайтів на Android та iphone я використовую ті самі хитрощі, що і ви: дозування. Я пробую багато рішень у OpenGL ES 1.x та 2.x:

• сортуйте за z (паралакс) та за текстурою, зробіть перетворення на процесорі та зателефонуйте glDrawArrays або glDrawElements (найшвидший спосіб). Використовуйте одну велику текстуру, якщо можете.
• той самий трюк з VBO, не швидше, тому що для кожного кадру ви оновлюєте всю інформацію. Це може бути корисно для спрайтів статики.
• використовувати OpenGL ES 2.x і використовувати шейдер Vertex для обчислення позицій (повільніше)
• використовуйте PointSprites (жодного рішення, якщо це не квадрат, а занадто багато прозорих пікселів вбивають фільтрат)
• використовувати розширення gldrawtexoes ...
• використовувати зворотний виклик для кожного спрайту (найповільніший метод)

Отже, як і ви, всі перетворення виконуються процесором для OGLES 1.x або OGLES 2.x. Якщо у вас є неонові інструкції, ви можете використовувати їх для прискорення обчислень.

Ps: на пристроях iphone або android я не обмежений процесором, але швидкість заповнення обмежена. Тому дуже важливо обмежити перевитрату.

Я б рекомендував мати VBO, при цьому кожна вершина містить положення / обертання кожного виведеного об'єкта та групування на основі текстури, як ви робите. Я не дуже знайомий з ogl ES, тому я не впевнений, яку версію glsl він підтримує, але ви, можливо, навіть зможете складати пакетну групу на основі набору текстур і зберігати, яку з 4-х текстур ви передаєте Ви б використовували всередині вершини. Точкові спрайти, безумовно, покращать вашу ефективність, оскільки це зменшить кількість даних, які ви надсилаєте, різко, і пакетне використання не повинно ніколи знижувати продуктивність, якщо ви робите це правильно. Крім того, ви можете трохи покращити продуктивність, обчисливши обертання на шейдері і лише передавши значення int / float в парами або всередині самої вершини. (парами були б швидшими,

Ви згадуєте мобільні платформи, які не мають інстанцій. Але у вас все ще є вершинні шейдери, чи не так?

У такому випадку ви все ще можете зробити псевдоінстанціювання, що теж дуже швидко. Зробіть VBO (GL_STATIC_DRAW) з кутовими точками (щодо центральної точки спрайта, наприклад, -1 / -1, 1 / -1, 1/1, -1/1) та будь-якими потрібними текстурними координатами. .
Потім встановіть один із загальних атрибутів вершини для кожного виклику малювання до центральної точки спрайта та намалюйте два трикутники зв'язаним буфером. Всередині вершинного шейдера прочитайте загальний атрибут вершини та додайте координати вершини.

Це дозволить вам заощадити блокування при передачі даних для кожного спрайту і повинно бути набагато швидшим. Фактична кількість розіграшів дзвінків не настільки важлива, блокування / зупинка між ними є.

Проблема полягає в кількості даних, які ви надсилаєте в GPU кожен кадр. Просто створіть VBO для кожної партії та заповніть її один раз, а потім застосуйте відповідні матриці перетворення (через glMultMatrix або шейдер, якщо ви використовуєте ES 2.0), коли малюєте партії.