Respawn.pl

Fortnite – fakty i mity o wersji androidowej!

Autor: Marcin Skrętkowicz
Android

9 sierpnia została wydana beta Fortnite na Androida, obsługującą wybrane urządzenia od firmy Samsung. Kilka dni później deweloperzy zaczęli wysyłać zaproszenia do niektórych posiadaczy urządzeń z Androidem, wyprodukowanych przez konkretne firmy.

STATYSTYKI

W ciągu 21 pierwszych dni po premierze Fortnite na Androida Epic Games spotkało się z ogromnym zainteresowaniem: ponad 23 mln graczy wzięło udział w wersji beta, a ponad 15 mln zainstalowało aplikację. Choć wersja na Androida jest jeszcze w fazie zaproszeń, przejście z etapu zaproszenia do gry wygląda podobnie, jak w wersji beta na iOS.

SPRZĘT I OPTYMALIZACJA

Wprowadzanie technologii.

Wydawanie tej samej gry na różnych platformach przy jednoczesnym umożliwieniu rozgrywki międzyplatformowej stanowi wyjątkowe wyzwanie. Podczas przystosowywania gry do urządzeń mobilnych zazwyczaj dochodzi do uproszczenia zawartości, a nawet projektu, w celu zachowania wydajności przy ograniczonych parametrach nowej platformy. Na przykład zmniejsza się odległość renderowania, aby zredukować liczbę poleceń renderowania. W Fortnite gracze na Androidzie mogą uczestniczyć w tej samej grze, co ich koledzy na PC i konsolach, więc trzeba renderować wszystko, co ma wpływ na rozgrywkę.

Droga do wydania gry na Androida

Od stycznia 2018 r. Epic Games pracowało w dużym zespole nad wersją FNBR na Androida. Choć mnóstwo czasu spędzili nad wydajnością renderowania, stabilnością i pamięcią, to najpoważniejsze wyzwanie stanowiła różnorodność urządzeń z Androidem, wersji systemu i sterowników.

Współpraca z partnerami miała kluczowe znaczenie dla wydania wersji na Androida. Nie poradziliby sobie bez ich wiedzy, doświadczenia i ciężkiej pracy.

Blisko współpracowali z Samsungiem przy profilowaniu i optymalizacji Fortnite na ich urządzenia. Samsung przysłał inżynierów do wielu placówek Epica na całym świecie i współpracował bezpośrednio z inżynierami nad analizą wydajności i optymalizacji. Zawdzięczają im także wiele zmian w kodzie, szczególnie w rendererze Vulkan. Przy użyciu diagnostycznych smartfonów testowych i firmowych narzędzi pomiarowych byli oni w stanie dać wgląd w źródło problemów z wydajnością i pamięcią, i znaleźć sposoby ich rozwiązania. Współpracowali też z Samsungiem nad stworzeniem jak najpłynniejszego i najbezpieczniejszego procesu instalacji dla użytkowników smartfonów tej firmy.

Również inżynierowie Google odwiedzili Epic Games na miejscu, by pomóc w profilowaniu i optymalizacji Fortnite, identyfikacji kluczowych usprawnień oraz przecieków pamięci, a także w stworzeniu sprawnej implementacji równomiernego wyświetlania klatek OpenGL na Androidzie.

Ponadto udało im się nawiązać współpracę z wieloma innymi partnerami w celu testowania i optymalizacji Fortnite. Należą do nich m.in. ARM, Qualcomm, Imagination Technologies, Razer czy HiSilicon.

Fragmentacja

Środowisko Androida składa się ze smartfonów produkcji różnych firm. Centrum każdego z nich stanowi tzw. „system na kości” (System-on-Chip, SOC), zawierający konfigurację rdzeni procesora i karty graficznej. Istnieje kilka popularnych rodzin SOC-ów, np. Snapdragon firmy Qualcomm (w 71% aktualnie obsługiwanych urządzeń) zawierający procesor Adreno, a także Exynos firmy Samsung, seria MT firmy MediaTek oraz seria Kirin firmy HiSilicon, które to serie korzystają z procesorów ARM Mali. Każde urządzenie wypuszczane jest na rynek z nieco odmienną wersją systemu operacyjnego Android, a większość producentów dodatkowo dostosowuje funkcje zarządzania procesami i energią. Urządzenia z identycznym procesorem są też wydawane z różnymi wersjami sterowników graficznych. Efekt końcowy jest taki, że dwa urządzenia o identycznej podstawie sprzętowej mogą mieć bardzo odmienne parametry wydajności i być wrażliwe na różne błędy w kodzie.

Miłym zaskoczeniem dla inżynierów był fakt, że najnowsza wersja Androida jest bardziej popularna na urządzeniach z ostatnich 2 lat, niż zakładano. Choć jest to jeszcze na etapie bety i wyższych wymagań sprzętowych, zauważyć można, że 92% użytkowników Fortnite pracuje na Androidzie 8 (Oreo) lub nowszym, ok. 8% na Androidzie 7 (Nougat), a mniej niż 0,5% na wersji wydanej w 2015 r. lub wcześniej. Producenci tych urządzeń wydają specjalnie dostosowane aktualizacje i w większości przypadków muszą skoordynować z operatorami bezprzewodowymi na całym świecie produkcję i wypuszczanie tych aktualizacji.

Do zarządzania tym skomplikowanym układem inżynierowie mają w silniku Unreal Engine hierarchiczny system profilów urządzeń. Zaczynają od stworzenia czterech profilów wydajności: niskiej, średniej, wysokiej i epickiej. Profile te zmieniają ustawienia skalowania w silniku gry, co pozwala jej działać na urządzeniach o różnej wydajności. Poziom niski ogranicza do minimum odległość renderowania, a także wyłącza opcjonalne efekty graficzne. Poziom epicki włącza wszystko: cienie, roślinność itp., a także wydłuża odległość renderowania na tyle, na ile można sobie pozwolić przy zachowaniu płynnej pracy na najnowszych urządzeniach.

Do tego dodany jest zestaw profilów karty graficznej, np. Adreno 54x czy Mali G72. Profile te wybierają profil wydajności pasujący do możliwości danego urządzenia, a także pozwalają włączyć optymalizacje lub obejścia potrzebne na tym konkretnym sprzęcie. I ostatecznie jest zestaw profilów dla danego urządzenia, np. Samsung Galaxy Note 9 Adreno lub Google Pixel 2 XL. Ta ostatnia warstwa profilów urządzenia pozwala w razie potrzeby włączyć kolejne obejścia lub optymalizacje, tym razem przystosowane do konkretnego urządzenia. Podczas uruchamiania gry sprawdzane są parametry w rodzaju modelu urządzenia, wersji systemu i sterownika graficznego, aby ustalić, który profil urządzenia zastosować.

Wydajność renderowania

Dotychczas najpoważniejszą przeszkodę dla programistów w utrzymaniu płynności gry stanowiło obciążenie procesora podczas renderowania. Zużywa to dużo więcej czasu procesora na Androidzie niż na komputerach PC, konsolach czy iOS-ie. Choć najnowsze urządzenia z Androidem mogą obsłużyć ponad 1500 poleceń renderowania na klatkę, inne obsługują o wiele mniej. Obsługiwane przez Epic Games urządzenia średniej klasy muszą być zdolne do wykonania ok. 600 takich poleceń, a urządzenia niższej klasy ok. 400.

Zredukowali już liczbę obiektów renderowanych w każdej klatce do praktycznego minimum przy okazji premiery wersji iOS w zeszłym roku, więc musieli uciec się do innych sposobów. Inżynierowie spróbowali dynamicznego grupowania poleceń renderowania w polecenia przywołane i choć zapewniło to pewną poprawę wydajności, nie była ona na tyle istotna, by uzasadnić dodatkowe skomplikowanie kodu.

Niektóre optymalizacje w OpenGL przyniosły niewielkie korzyści, lecz największy krok naprzód był dla nas niespodzianką i pochodził z jednej z optymalizacji pamięci: emulacji buforów jednolitych. To ścieżka kodu, którą silnik UE4 obsługiwał od lat, używana do urządzeń z OpenGL ES2, które nie obsługują natywnie buforów jednolitych, znanych też jako bufory stałe. Działa to w następujący sposób: w momencie kompilacji shadera identyfikujemy wszystkie stałe potrzebne shaderowi i umieszczamy je w tablicy, którą czyta shader. Zachowywane są również tabelę mapowania, które mówią silnikowi gry, skąd brać stałe dla buforów jednolitych i gdzie je umieszczać w tablicy stałych. W czasie rzeczywistym trzymane są bufory jednolite w pamięci dostępnej dla procesora, korzystając z tabeli mapowania, by skopiować je do bufora tymczasowego i wysyłane są wszystkie stałe przy użyciu jednego odwołania funkcji glUniform4fv.

Choć nadal jest ona dość zagadkowa, ścieżka kodu emulowanych buforów jednorodnych zaoszczędziła sporo czasu inżynierom w sterowniku. Możliwe jest, że sterownik dokonuje podobnego procesu we własnym zakresie, a ten sposób lepiej się sprawdza do potrzeb Epic Games. Możliwe też, że przez przeznaczanie mniej zasobów, sterownik po prostu spędza mniej czasu na zarządzaniu czasem trwania tych buforów. Tak czy inaczej, sposób ten w niektórych przypadkach zmniejszył obciążenie sterownika o 10-15%.

Całość informacji do przeczytania tutaj.