Optymalizacja w grach pod Androida a rozdzielczość

[hgter]

Witajcie

 

Walczę sobie z wydajnością na androidzie.

 

Na nexusie 7 i xperii Z jest w pełni ok. Natomiast po uruchomieniu na Samsungu s3 mini jest marnie. Srednio mam poniżej 60 fps. W razultacie grafika tnie.

 

Roomy mają 1920x1200 co jest ręcznie (mam wyłączone surface) skalowane do odpowiednich proporcji z wykorzystaniem czarnych pasków jeżeli proporcja ekranu jest inna.

 

Tło też jest obrazkiem o takiej wielkości (sprawdzałem z skalowaniem mniejszego, ale to nie zmienia nic).

 

I teraz chcę wyświetlić sporo elementów (prymitywy) w roomie - te elementy są zawsze w tych samych miejscach i ich każdorazowe oddzielne wyświetlanie jest nieszczególnym pomysłem. Teraz robię to tak, że tworzę raz surface (mam wyłączone surface - mimo to da się je tworzyć) i potem ten surface wyświetlam.

 

Na szybkich jest ok, ale na wolniejszym urządzeniu schodzi to poniżej 60 fps.

 

Jeżeli wyłączę fragment kodu odpowiedzialny za generowanie surface wydajność bardzo rośnie (no ale nie mam grafiki:). No to sobie pomyślałem, że ten surface po utworzeniu przerzucę do sprita a surface usunę. Nic się nie zmieniło.

 

Ok no to testowo zapisałem surface na dysku i w testowej wersji dałem jego wyświetlanie jako sprita. Jak było źle tak jest, chociaż kodu z surface nie ma wcale. Skoro tak, to chyba to duże jest (ale co z tłem które też jest takie duże a nie wpływa na wydajność?). Pociąłem na 4 oddzielne sprity. Nadal kicha. Tak samo jak ustawię to jako tiles.

 

 

 

 

Ech. Co mogę z tym zrobić? Dlaczego tło roomu nie zwalnia całości a tak samo duży surface/sprite/tiles już tak?

 

Wiem, że mogę zmniejszyć room np. do 960x600 i to rozwiązuje problem (sprawdzone). Ale chciałbym aby na urządzeniach z wysoką rozdzielczością dobrze się wyświetlało. Jakie Wy wykorzystujecie wielkości roomów?

[I am vader]

To tak w skrócie:

1. Wylaczenie application_surface ktore wylaczyles owszem bardzo pomaga, ale jego wylaczenie nie wylacza korzystania z surface W OGOLE, dlatego mozesz z wlasnych korzystac.

2. Android jest słaby z dużymi surface'ami, dlatego ta 1sza opcja tak bardzo pomogła. Dlatego tez jakikolwiek wlasny surface ktory jest DUŻY zmniejszy wyraźnie wydajność.

3. W Androidzie bardzo ważny jest texture swap. Każda grafika jest zapisana na texture page'u. Postaraj się je pogrupować tak aby grafiki były roomami aby jak najmniej stron naraz było aktywne.

4. Próbowałeś jednak je rysować na bierząco zamiast trzymać surface/sprite? Może jednak okaże się szybsze?

4a. Background jest szybszy od sprite bo nie ma maski kolizji ani klatek animacji.

5. Co prawda YYC nie pomaga na draw, a na step, ale może Ci zaoszczędzi te kilka FPS

6. Rozumiem view_wview/hview jest 1920x1080, ale polecam view_wport/hport zmniejszyć do rozdzielczości wyświetlacza, jeśli tego jeszcze nie robisz

7. Robię na 720p na Androidzie, bo spadek jakości po rozciągnięciu na 1080p nie jest jakis zly, a kompromisy się przydają.

8. Room speed mocno wpływa na wydajność na Androidzie. Bywa tak, że na room_speed 30 utrzymuje stałe 30, ale na room_speed 60 trzyma się poniżej 30 tam, gdzie na speed 30 byłoby stabilnie. Wplywa to również nieznacznie na FPSy przez ogólne obciążenie urządzenia.

9. Dodatkowo do przeciwwagi spadków prędkości używaj delty. Nie zwiększy Ci to FPS ale zmniejszy ilość bolących zadków, bo nie będzie spowolnienia gry samej w sobie.

10. Jak masz pewność, że background zapełnia cały ekran, polecam w roomie wyłączyć opcje [settings>>]"Clear Display Buffer with Window Colour" oraz [backgrounds>>] Draw background color

11. Global Game Settings>Android>Graphics>16 bit

 

To tyle co z głowy mogę wyciągnąć apropo optymalizacji. Rozumiem, że pewne rzeczy mogą Cię zniesmaczyć, jak chociażby 16-bitowa grafika, ale pamiętaj, że robisz grę na małe urządzonko trzymane w kieszeni, a nie na komputer. Jesteś przyzwyczajony że 2015 i taka technologia i takie bajery, no ale telefon to telefon.

 

 

 

Edit: Mogę Ci wydajność testnąć jeśli podeślesz APK na PW.

Chociaż moje urządzenie to tablet i to całkiem dobry więc może Ci nie dać żadnych interesujących wyników.

[hgter]

Kurcze na początek dzięki wielkie, że chciało Ci się to wszystko zebrać.

 

1. Wylaczenie application_surface ktore wylaczyles owszem bardzo pomaga, ale jego wylaczenie nie wylacza korzystania z surface W OGOLE, dlatego mozesz z wlasnych korzystac.

 

Podejrzewałem to, tylko cały czas się boję czy nie będzie z tego artefaktów. Np. nie mogłem zmusić do działania surface_resize - po prostu znikała.

 

2. Android jest słaby z dużymi surface'ami, dlatego ta 1sza opcja tak bardzo pomogła. Dlatego tez jakikolwiek wlasny surface ktory jest DUŻY zmniejszy wyraźnie wydajność.

 

Szperając byłem tu:

http://gmc.yoyogames.com/index.php?showtopic=655565

I po tym zacząłem kombinować z podziałem spritów na mniejsze części. Myślałem czy nie zrobić podobnie na etapie tworzenia surface - czyli np. zamiast jednej dużej dać 4 mniejsze, ale naprawdę nie chcę wbijać w pisanie kodu tego. Generuję obraz na bazie dużej ilości trójkątów i gdybym chciał to w locie dzielić na np. 4 musiałbym w przypadku tych trójkątów, które wchodzą na dwie surface jadnocześnie wyliczać przecięcie i rysować jedną połówkę tu a drugą tu. Już tu mi się odechciewa mocno, a jak pomyślę co z trójkątami które są na 4 surfacach (lub więcej) to odpadam:)

 

Jeszcze teoretycznie mógłbym użyć surface_copy_part do podziału gotowej surface na 4 części, ale jak robiłem podobnie, tyle że dzieląc na 4 sprity to efektu nie było niestety. Chyba sam fakt, że surface była rozwalał fps.

 

Miałem też epizod, w którym wykorzystałem to:

http://gmc.yoyogames.com/index.php?showtop...49#entry4734849

 

Przerobiłem to tak, że na początku gra stopniowo zmniejszała jakość do takiej przy której ilość fpsów była wystarczająca. Ale to był niewypał bo fakt, że do tego surface musi był włączony powodował, że na s3 mini gra szła dopiero przy około 0.2 początkowej wielkości co dawało jakość w której nic nie było widać:) Ale sama idea była fajna.

 

 

3. W Androidzie bardzo ważny jest texture swap. Każda grafika jest zapisana na texture page'u. Postaraj się je pogrupować tak aby grafiki były roomami aby jak najmniej stron naraz było aktywne.

 

Ok, dobra idea. Niby to bardzo wstępna wersja, ale mam kupę starych wersji spritów, które niepotrzebnie się ładują.

 

 

4. Próbowałeś jednak je rysować na bierząco zamiast trzymać surface/sprite? Może jednak okaże się szybsze?

 

Niestety tak. Danie tego do surface dało prawie 4x wzrostu fps (ale na mocnych urządzeniach - sprawdzę czy na słabym nie zachowa się to inaczej).

 

 

4a. Background jest szybszy od sprite bo nie ma maski kolizji ani klatek animacji.

 

No tak tylko, że spróbowałem też podejścia, w którym najpierw wygenerowałem 4 pliki png z ćwiartkami tego surface i następnie w projekcie testowym wstawiłem je jako tile. Tu nie było rysowania surfaceów ani spritów a i tak nie dało to efektu. Byłem tym naprawdę zdziwiony - liczyłem, że w najgorszym razie zrobię to tak, że po rozpoznaniu słabego urządzenia, gra przy pierwszym uruchomieniu wygeneruje sobie odpowiednie tile i to z nich będzie korzystać potem.

 

 

5. Co prawda YYC nie pomaga na draw, a na step, ale może Ci zaoszczędzi te kilka FPS

 

Niestety akurat tu różnica była zbyt mała.

 

 

6. Rozumiem view_wview/hview jest 1920x1080, ale polecam view_wport/hport zmniejszyć do rozdzielczości wyświetlacza, jeśli tego jeszcze nie robisz

 

Tak właśnie robię.

 

 

 

7. Robię na 720p na Androidzie, bo spadek jakości po rozciągnięciu na 1080p nie jest jakis zly, a kompromisy się przydają.

 

I chyba w tym kierunku pójdę. Ciekawy byłem jakie inni stosują tu wielkości. Tylko właśnie tego rozciągania się bałem. Muszę zrobić sobie jakiś testowy obraz i zobaczyć jak duże są te straty.

 

 

 

8. Room speed mocno wpływa na wydajność na Androidzie. Bywa tak, że na room_speed 30 utrzymuje stałe 30, ale na room_speed 60 trzyma się poniżej 30 tam, gdzie na speed 30 byłoby stabilnie. Wplywa to również nieznacznie na FPSy przez ogólne obciążenie urządzenia.

 

9. Dodatkowo do przeciwwagi spadków prędkości używaj delty. Nie zwiększy Ci to FPS ale zmniejszy ilość bolących zadków, bo nie będzie spowolnienia gry samej w sobie.

 

Niestety całość gry opieram na fizyce. I te 60 musi być aby miało to sens.

 

 

10. Jak masz pewność, że background zapełnia cały ekran, polecam w roomie wyłączyć opcje [settings>>]"Clear Display Buffer with Window Colour" oraz [backgrounds>>] Draw background color

 

Ok, dzięki.

 

 

11. Global Game Settings>Android>Graphics>16 bit

 

To tyle co z głowy mogę wyciągnąć apropo optymalizacji. Rozumiem, że pewne rzeczy mogą Cię zniesmaczyć, jak chociażby 16-bitowa grafika, ale pamiętaj, że robisz grę na małe urządzonko trzymane w kieszeni, a nie na komputer. Jesteś przyzwyczajony że 2015 i taka technologia i takie bajery, no ale telefon to telefon.

 

To będzie bardzo prosta gierka - fajerwerków nie będzie tak dużo:). Cała ta zabawa jest, ponieważ chcę maksymalnie ułatwić pracę w edytorze roomów, aby zupełnie bez kodowania i tailowania można było tworzyć "z klocków" kolejne levele. I robię to też trochę "dla sztuki" żeby się nauczyć jak najwięcej na tym projekcie. Stąd wspomniany gdzieś wcześniej przeze mnie mechanizm, w którym obiekty po starcie usuwają się, konwertując przy tym do prymitywów opartych o trójkąty, które z kolei się ładnie teksturują i są wrzucane na surface. Podobnie z fiksturami. W efekcie nie ma różnicy czy w grze jest 10 czy 600 obiektów (muszę w końcu zrobić testy ile maksymalnie tych obiektów wyciągnę). Oczywiście jeżeli obiektów miałoby być 10 na ekranie to to jest idiotyzm na którym więcej tracę niż zyskuję.

 

Edit: Mogę Ci wydajność testnąć jeśli podeślesz APK na PW.

Chociaż moje urządzenie to tablet i to całkiem dobry więc może Ci nie dać żadnych interesujących wyników.

 

Na razie urządzeń trochę mam więc dziękuję. Muszę chyba tylko coś słabszego kupić.

 

 

Jeszcze raz dzięki za odpowiedź!

 

[hgter]

Zrobiłem jeszcze trochę testów. Wyniki są dość zaskakujące:

 

1) Próbowałem jeszcze raz z tilami - nie mogłem uwierzyć, że to też zabierało fps. Potwierdziło się. Dawanie 1 dużego tila nic nie pomaga

2) Po podziale na 4 mniejsze tile nadal bez zmian.

3) No dobra to automatem pokrywam wszystko tilami 30x30 - bez zmian

 

Zacząłem kombinować z background. No bo on jest wielki a nie obniża fps.

 

4) Funkcja draw_background - wygląda świetnie, ale fpsy lecą w dół bez zmian.

 

5) I w końcu postanowiłem nie rysować niczego tylko użyć: room_set_background.

 

I to nie powoduje spadku fpsów. Czyli jeżeli background rysuję to spadek jest a jeżeli go ustawiam to nie ma.

 

Wynika z tego, że użycie tilów jest wolne i użycie jakichkolwiek draw też. Kurde trochę bez sensu. Ale tak wyszło. Dla pewności sprawdziłem co będzie jeżeli surface utworzę, ale nie narysuję - i tu zgodnie z oczekiwaniem spadku nie ma.

 

Czyli jeżeli nie chcę zmniejszać wielkości roomu to na słabych urządzeniach muszę zamienić wszystkie grafiki w background i następnie przypisać do roomu. Wadą jest to, że room_set_background nie można użyć na aktywnym roomie oraz to, że nie można tu użyć sprita - można co najwyżej wczytać plik.

 

Mogę teraz zrobić to na dwa sposoby: albo mieć gotowe wcześniej odpowiednie backgroundy dla każdego levelu - ale to spowoduje, że gra będzie wielka albo przy pierwszym uruchomieniu gry konwertować kolejno w każdym roomie wszystkie grafiki wraz tłem na surface, potem zapis do pliku i następnie odczyt do backgrounda. O matko.

 

Jak ktoś zna sposób na bezpośrednią zamianę surfaca/sprita w background to poratujcie.

 

[I am vader]

Draw w Androidzie to absolutne piekło, zapewniam Cię. Sam niedawno miałem z tym problemy.

Niskie FPSy są cały czas czy po jakimś czasie (np. kilku sekundach) wzrastają?

[hgter]

Zgadza się co do draw. Trochę irytujące to jest.

 

I to na tyle, że zaczynam zastanawiać się czy dobrym wyborem do 2D jest GM i czy nie lepiej byłoby pracować na np. Unity.

 

Nie wiem czy słusznie, ale mam odczucie, że w GM bardzo szybko można uzyskać działającą grę, ale jest sporo zabawy żeby działała dobrze. Spotkałem się z opinią, że wiele osób używa GM jedynie do prototypowania.

 

Nie wiem jak to jest w Unity natomiast.

 

 

 

PS A fpsy są niskie cały czas (nawet lekko spadają - ale to pewnie przy dalszej optymalizacji zniknie).

[I am vader]

Optymalizacja to coś od czego nie uciekniesz bez względu na platformę. Różnicą jest czy optymalizujesz opcje nadane Ci przez SDK(koszt uproszczeń) czy optymalizujesz własny kod(co by Ci się przydarzyło z np. c++)

[Threef]

A ja dodam że draw jest zawsze wąskim gardłem. Niezależnie od platformy czy silnika. Dlatego mamy teraz w swoich PC dedykowane karty graficzne.