Zmniejszenie Draw Calls

[Nirvan]

Witam, właśnie rozmyślam nad tym jak mógłbym przyspieszyć swoją gierkę którą piszę na libGDX w javie na androida.

Rysuję tło które składa się z wielu ruchomych elementów, każdy z osobna rysuje co sprawia że tło zabiera 97 draw calli co spowalnia grę.

Jak nazywają się metody które pomogły by mi zmniejszyć ilość draw calli a równocześnie mógłbym rysować wiele prostych ruchomych elementów?

Chyba istnieją takie? :D

[gnysek]

Batch draw ?

 

https://libgdx.badlogicgames.com/nightlies/.../g2d/Batch.html

[Nirvan]

Używam do tej pory SpriteBatch który jest implementacją interfejsu Batch i właśnie myślałem czy jest coś co renderowałoby szybciej.

[Exigo]

Być może źle używasz batchera. Powinieneś mieć, nie wiem, coś koło max 3-4 draw calle na klatkę.

 

Największy performance uzyskasz używając atlasu tekstur. Winowajce masz tutaj (przykład): https://github.com/libgdx/libgdx/blob/maste....java#L232-L233 (linie 232-233).

Każde przełączenie tekstury wymusza flusha, czyli wyrenderowanie i całkowity reset VAO który uzbierałeś do buforu - tym jest właśnie draw call. Jeśli jednak koniecznie nie chcesz używać atlasu, posortuj chociaż rysowania po teksturze, czyli coś w stylu: najpierw wszystkie chmurki, potem wszystkie gwiazdki, etc. Ale to będzie trochę na około problemu (da się zejść do poziomu 1 call == 1 aktywna tekstura).

 

Ostatecznie możesz też zmodyfikować batchera i jego shader; wymaga to lekkiej znajomości OpenGL-a (+ GLSL-a). Samo API dostarcza taką możliwość. Batcher, w założeniu, służy "do wszystkiego" i jest idioto-odporny, więc ma nawalone jakichś zbędnych macierzy, dodatkowych atrybutów (niepotrzebny color? przez które jest potem wszystko przemnażane (a przez cały lifetime shadera wynosi vec4(1, 1, 1, 1) i zaśmieca VAO)), etc., dużo ficzerów których pewnie i tak nigdy nie użyjesz. Jak się postarasz i sprecyzujesz co dokładnie chcesz rysować, z połowę tych rzeczy można zwyczajnie wyciąć, co zoptymalizuje sam shader jak i CPU który jest akurat największym bottleneckiem dla batchera (bo skalowanie, rotacja, translacja - wszystkie są na cpu, TAK, CPU!, czytaj: wszystkie przekształcenia macierzowe (w 2d jest proste cos/sin, ale wciąż), robi Java a nie karta). Np. niesamowicie da się zoptymalizować renderowanie sceny opartej o siatkę (przykład z życia).

 

Mam nadzieję że pomogłem. :) Polecam przejrzeć source i zobaczyć jak on działa. Im więcej rozumiesz co jest w środku, tym większe triki możesz z tym robić.

 

Dawno tu nie pisałem. ;D

[Nirvan]

O super, bardzo fajna rada, właśnie zauważyłem że ten batch to takie coś do wszystkiego a mało co z tego do tej rzeczy do której chce potrzebuję.

Nie wiedziałem pod jaką nazwą szukać czegoś szybszego bo pod "faster spriteBatch" nic sensownego nie znalazłem.

Zobaczę jak ten atlas textur działa, ale nie wiem za ile dni to sprawdze, bo zbyt dużo różnych projektów na głowie :D

Dzięki.