07-04-2020, 16:26
TL;DR Poczekaj tydzień, dwa i myślę, że coś się zmieni w tej materii (obserwuj Mini FPS Booster w warsztacie Steam).
Problemem w tej grze jest niezbyt przemyślany sposób implementacji elementów interfejsu użytkownika(możliwe, że źle oszacowali popularności tytułu), jak i duże obciążenie procesora ze względu na symulacyjny aspekt gry.
Każdy element, od okienek, paneli, dialogów, po przyciski, kończąc na separatorach, nawet jeśli niewidoczny jest ciągle automatycznie odświeżany przed wyrenderowaniem każdej klatki przez silnik Unity.
Dla przypomnienia, maksymalny czas w jakim musi się zakończyć operacja zbierania informacji o następnej renderowanej klatce aby utrzymać pożądana liczbę klatek na sekundę:
Jeśli obiektów jest stosunkowo niedużo, różnica jest niezauważalna, ale tu właśnie jest haczyk. Liczba rodzajów elementów interfejsu użytkownika jest stosunkowo nieduża w grze, ale to ilość instancji (pojedynczych wystąpień) obiektów gra tutaj ogromną rolę.
W podstawowej grze po załadowaniu pustej mapy jest ich koło 8-10 tys. Każdy DLC dodaje kolejny zbiór nowych elementów, gdzie finalnie, posiadając wszystkie duże DLC, tych elementów jest około 14 tys (być może więcej, sprawdzałem przed Sunset Harbor).
W normalnych warunkach, gdyby elementy były odświeżane ręcznie w kodzie (napisanym przez deweloperów) ta operacja, nawet mimo odświeżania tak duże liczby elementów wykonałaby się maksymalnie w kilka milisekund (zależnie od szybkości procesora). W związku z tym że robi to silnik Unity, czas wykonania tej operacji dla wszystkich obiektów jest nieporównywalnie większy (nie można pominąć żadnego aktywnego obiektu, aktywacja/dezaktywacja nie została przewidziana).
Podsumowując opis problemu, niewielka pomoc w poprawieniu FPS w grze zbliża się dość dużymi korkami.
Powoli kończę prace nad pełną wersją FPS Booster'a, potrzebuję jeszcze trochę czasu na dokończenie(tydzień, dwa przy obecnej ilości wolnego czasu, obsuwa możliwa, niestety), bo walczę z kompatybilnością modów (obecnie 95% kompatybilnych) i kilkoma ważnymi elementami.
Rozwiązanie samo w sobie jest dość skomplikowane. Z uwagi na to, że nie można dystrybuować zmodyfikowanych bibliotek gry (EULA i te sprawy
), musiałem stworzyć mechanizm łatania ich podczas uruchamiania gry (właściwie zanim się uruchomi) oraz utworzyć automat który załata wszystkie mody które aktualnie używają części kodu poddanej modyfikacjom - jeszcze przed ich załadowaniem.
Wzrost wydajności? Hmm... różny, ale w każdym przypadku
Na vanilli w moim przypadku czas odświeżania 1000-1200 elementów interfejsu wynosi ~1ms co daje w sumie jakieś 12-15ms straty na odświeżaniu UI => żadnych szans na 60 fps.
W zależności od sprzętu i ilości obiektów na scenie różnica będzie wynosiła od kilkunastu do... w sumie nie wiem ilu procent(laptop: i7 + 660M pokazuje i nawet 120 fps miejscami).
Jeśli ktoś na nowej, pustej mapie zobaczy grubo ponad 100 fps to nie będę bardzo zdziwiony, tym bardziej, że mój sprzęt już swoje lata ma.
W obszarach o dużej gęstości budynków i bardzo dużym zaludnieniu (>400k), przyrost jest szacowany tylko na kilkanaście procent z uwagi na duże obciążenie symulacją. Osobiście bez większych problemów mogę uruchomić mapkę 650K mieszkańców ~20-25fps w mieście w porównaniu do vanilli... max 20fps (patrząc w ziemię)
W drugim etapie planowane jest obniżenie spadku FPS do którego dochodzi wraz ze zwiększeniem ilości subskrypcji elementów warsztatu. Tak... to tez ma wpływ, podobny do odświeżania interfejsu, tylko mniejszy, bo rzadko kto próbuje subskrybować tysiące assetów, no chyba, że mówimy o Westdale - słynne Bus Ride'y z PHTN Gaming - 23k assetów, 40min ładowanie zapisu, rozmiar plik stronicowania na poziomie 220GB
Problemem w tej grze jest niezbyt przemyślany sposób implementacji elementów interfejsu użytkownika(możliwe, że źle oszacowali popularności tytułu), jak i duże obciążenie procesora ze względu na symulacyjny aspekt gry.
Każdy element, od okienek, paneli, dialogów, po przyciski, kończąc na separatorach, nawet jeśli niewidoczny jest ciągle automatycznie odświeżany przed wyrenderowaniem każdej klatki przez silnik Unity.
Dla przypomnienia, maksymalny czas w jakim musi się zakończyć operacja zbierania informacji o następnej renderowanej klatce aby utrzymać pożądana liczbę klatek na sekundę:
- 120 kl/s - 8.3ms(milisekundy)
- 60 kl/s - 16.6ms
- 30 kl/s - 33.3ms
- 15 kl/s - 66.6ms
- 8 kl/s - 125ms
Jeśli obiektów jest stosunkowo niedużo, różnica jest niezauważalna, ale tu właśnie jest haczyk. Liczba rodzajów elementów interfejsu użytkownika jest stosunkowo nieduża w grze, ale to ilość instancji (pojedynczych wystąpień) obiektów gra tutaj ogromną rolę.
W podstawowej grze po załadowaniu pustej mapy jest ich koło 8-10 tys. Każdy DLC dodaje kolejny zbiór nowych elementów, gdzie finalnie, posiadając wszystkie duże DLC, tych elementów jest około 14 tys (być może więcej, sprawdzałem przed Sunset Harbor).
W normalnych warunkach, gdyby elementy były odświeżane ręcznie w kodzie (napisanym przez deweloperów) ta operacja, nawet mimo odświeżania tak duże liczby elementów wykonałaby się maksymalnie w kilka milisekund (zależnie od szybkości procesora). W związku z tym że robi to silnik Unity, czas wykonania tej operacji dla wszystkich obiektów jest nieporównywalnie większy (nie można pominąć żadnego aktywnego obiektu, aktywacja/dezaktywacja nie została przewidziana).
Podsumowując opis problemu, niewielka pomoc w poprawieniu FPS w grze zbliża się dość dużymi korkami.
Powoli kończę prace nad pełną wersją FPS Booster'a, potrzebuję jeszcze trochę czasu na dokończenie(tydzień, dwa przy obecnej ilości wolnego czasu, obsuwa możliwa, niestety), bo walczę z kompatybilnością modów (obecnie 95% kompatybilnych) i kilkoma ważnymi elementami.
Rozwiązanie samo w sobie jest dość skomplikowane. Z uwagi na to, że nie można dystrybuować zmodyfikowanych bibliotek gry (EULA i te sprawy
), musiałem stworzyć mechanizm łatania ich podczas uruchamiania gry (właściwie zanim się uruchomi) oraz utworzyć automat który załata wszystkie mody które aktualnie używają części kodu poddanej modyfikacjom - jeszcze przed ich załadowaniem. Wzrost wydajności? Hmm... różny, ale w każdym przypadku
Na vanilli w moim przypadku czas odświeżania 1000-1200 elementów interfejsu wynosi ~1ms co daje w sumie jakieś 12-15ms straty na odświeżaniu UI => żadnych szans na 60 fps.
W zależności od sprzętu i ilości obiektów na scenie różnica będzie wynosiła od kilkunastu do... w sumie nie wiem ilu procent(laptop: i7 + 660M pokazuje i nawet 120 fps miejscami).
Jeśli ktoś na nowej, pustej mapie zobaczy grubo ponad 100 fps to nie będę bardzo zdziwiony, tym bardziej, że mój sprzęt już swoje lata ma.
W obszarach o dużej gęstości budynków i bardzo dużym zaludnieniu (>400k), przyrost jest szacowany tylko na kilkanaście procent z uwagi na duże obciążenie symulacją. Osobiście bez większych problemów mogę uruchomić mapkę 650K mieszkańców ~20-25fps w mieście w porównaniu do vanilli... max 20fps (patrząc w ziemię)
W drugim etapie planowane jest obniżenie spadku FPS do którego dochodzi wraz ze zwiększeniem ilości subskrypcji elementów warsztatu. Tak... to tez ma wpływ, podobny do odświeżania interfejsu, tylko mniejszy, bo rzadko kto próbuje subskrybować tysiące assetów, no chyba, że mówimy o Westdale - słynne Bus Ride'y z PHTN Gaming - 23k assetów, 40min ładowanie zapisu, rozmiar plik stronicowania na poziomie 220GB