Jak zabić FSX tweakami (+poradnik naprawy)

O pokój będziemy walczyli tak, że kamień na kamieniu nie zostanie – czyli o tym jak zabiłem FSX poprawiając konfigurację. I co zrobić, żeby odzyskać najwyższą jakość symulacji.

Ostatnio popadłem w szaleństwo – nowa karta graficzna i testy lepszych ustawień spowodowały u mnie to, przed czym sam przestrzegałem i co inni opisali wielokrotnie – tak długo poprawiałem mój fsx.cfg że klatkowanie w locie i na ziemi radykalnie spadło.

Problem zauważyłem nad Billund. Po ostatnich zmianach (po całej serii) w dolocie do tego lotniska klatkowanie spadło do 7fps. Co prawda 7 to najniższa wartość – wymagała Cessny 182 A2A ustawionej w ściśle określonej pozycji względem miasta i lotniska. No ale zdecydowanie jest to wartość niedopuszczalna i nieakceptowalna. Zapamiętałem miejsce, uruchomiłem Trike’a i zacząłem testy scenerii. Prace trzeba prowadzić w miejscu złym, wręcz fatalnym. Nie myślcie źle o Billund (Vidan Design) – to genialna sceneria i jestem zachwycony optymalizacją. Ale ma lepsze miejsca (35 klatek w 737 PMDG, 40 klatek w Cessnie A2A) i gorsze. Najgorsze znajduje się kawałek na południe od lotniska – z widokiem na lotnisko, zatłoczone samochodami parkingi i Billund, które Vidan świetnie wykonał w symulatorze. Przesuwając Trike’a znalazłem miejsce, w którym klatkowanie spadło do 9. Tu trzeba wprowadzać zmiany.

Napisze łopatologicznie, ale lektura facebooka i forów każe to szczególnie podkreślić:
Jeśli chcecie tweakować symulator – musicie wybrać dobrze zrobioną scenerię, która obciąża wasz komputer, a potem znaleźć najgorsze miejsce tej scenerii. Domyślne lotnisko na nic się tu nie przyda. Zmiana klatkowania z 70 na 130 klatek nic nie znaczy – przy tych samych ustawieniach w wymagającej scenerii może nie być żadnej zmiany. Dlatego poprawiamy tam gdzie jest najgorzej walcząc z wynikami słabymi (a nie poprawiając dobre).

Procedura

Krok 1 – skasowałem fsx.cfg. To krok radykalny, ale niezbędny – nie mam siły przeglądać całego fsx.cfg w poszukiwaniu bałaganu. W widoku pełnoekranowym klatkowanie skoczyło z 9 do 23 (przy małej rozdzielczości).

Krok 2 – ustawiam rozdzielczość – klatkowanie spada do 19.

Krok 3 – włączam tryb DX10 Preview – wzrost do 21.

Krok 4 – kasuje domyślny ruch (wcześniej testowałem z wyłączonym) – wzrost do 22 (21,5).

Krok 5 – edycja ustawień (suwaki w prawo + filtrowanie anizotropowe i antyaliasing) – spadek do 21 fps.

Krok 6 – ustawienie nVidia Inspectora (podstawowe ustawienia dla DX10) i konfiguratora DX10 Fixer – 20,5 fps.

Krok 7 – ustawiam SmallPartRejectRadius na 0. I tu radykalna strata – FPS spadają do 8.

Krok 8 – wstawiam bardziej racjonalny SmallPartRejectRadius=1. Wzrost do 12-13.

Krok 9 – sprawdzam Bufferpools (wyłączone) – spadek o jedną klatkę (możliwe, że efekt jest przypadkowy – dalej nie zbadałem tego tweaka – wycofuję więc).

Krok 10 – pora ustawić suwak wody na bardziej racjonalną wartość (do tej pory – wymaksowany, wcześniej latałem z 2.x low). Ustawiam 2.x low – klatkowanie podskakuje do 22.

Krok 11 – test autogenu. Niemal niezauważalny wpływ w przedziale 19-21 klatek między Normal a Very Dense. Zostawiam Dense. Suwakiem scenerii nie bawię się – zostaje Very Dense. W tekście o ustawieniach scenerii pisałem, że nie spotkałem się ze sceneriami skonfigurowanymi pod te ustawienia, więc praktycznie wszystko w zakresie Sparse – Extremely Dense powinno wyglądać identycznie.

Krok 12 – przyspieszam uruchamianie – testuje DisablePreload=1, który (zaskakująco) powoduje o 6 sekund dłuższe uruchamianie. 35 vs 29 sekund. Spróbowałem innej konfiguracji – przesunąłem Trike’a nad środek Atlantyku i zapisałem taki lot jako domyślny. Czas uruchomienia – 28 sekund. Różnica poniżej błędu pomiaru, ale zostawię.

Krok 13 – dalsze testy – tym razem sprawdzam SmallPartRejectRadius=1.5. O dziwo (w sensie – nie wiem dlaczego różnica miałaby być pozytywna) wrażenia są lepsze, a klatki wzrosły do 23-25.

Krok 14 – test wody. Rozważam jedynie ustawienia 2.x. Niskie, średnie i wysokie dają ok. 24 klatki. Max – spadek do 13. Zostawiam Wysokie, ale trzeba powtórzyć ten test nad wodą.

Krok 15 – jeszcze jeden test SmallPartRejectRadius. Opcje 1, 2 i 1.5. 1 daje (po zmianie wody w porównaniu z poprzednim testem) ok 21-22 klatek. 2 powoduje wzrost do 26-27. Zostawiam 1.5 – mam wrażenie (subiektywne – nie zrobiłem nagrań do porównania), że efekt wyskakiwania autogenu i obiektów jest przytłumiony w porównaniu z opcją 2.

Koniec. Ostatni test z myszką poza obszarem widoku – 26 klatek.

Co dalej?

Teraz kluczowa jest ocena szybkości ładowania tekstur. Jeśli będą ładowały się odpowiednio szybko – mogę znieść blokadę klatek (obecnie 40) – to da mi w warunkach testowych 30 klatek. Jeśli tekstury nie będą się ładowały wystarczająco dobrze – wrócę do blokady (kosztem kilku klatek osiągnę ostrzejsze tekstury gruntu).

Efekty

W przypadku testowego Trike’a osiągnąłem niemal trzykrotny wzrost w porównaniu z poprzednim ustawieniem. Dodatkowo podniosłem parametry wody (samolot i chmury będą się teraz odbijały). Podniosłem też autogen z Dense na Very Dense. Koszt – trochę więcej wyskakującego autogenu (poprzednio latałem z ustawieniem 1, zamiast 1.5 teraz w SmallPartRejectRadius).

Podczas testów używałem też największych dostępnych tekstur (4096). Nie wpływają na wyniki w momencie kiedy nie używam scenerii i maszyn, które korzystałyby z takich rozdzielczości (to popularny mit – w wielu przypadkach zmiana z 4096 na 2048 nic nie zmienia – wpływ na klatki i VAS pojawia się dopiero kiedy latamy w miejscu, które z takich tekstur korzysta). Ale zapamiętam sobie, żeby zmniejszyć tekstury w przypadku lotu samolotem mocno obciążającym VAS (odrzutowce PMDG).

Dodatkowy test przeprowadziłem nad Warszawą (Drzewiecki Design) w C182 (A2A). Przy odblokowanych klatkach i bardzo wysokich ustawieniach – 25-40 klatek w zależności od kierunku lotu. Można nagrywać filmy!

Wnioski

Przesterowanie FSXa nie pomaga. Wbrew rozpowszechnianym opiniom – nie każdy wpis w fsx.cfg pomaga – wiele przeszkadza.

Konfigurując FSX trzeba pamiętać, że istnieje wiele prawidłowych (i jeszcze więcej nieprawidłowych) konfiguracji. Pamiętajcie, że liczba permutacji wszystkich zmienianych opcji i dostępnych ustawień jest przeogromna. Dlatego czasem nie warto zaglądać w fsx.cfg szukając problemu.

Lepiej pozbyć się pliku, zaakceptować zezwolenia od nowa i pobawić się w konfigurację.

To czasochłonna zabawa!

Nie można skonfigurować FSX w 5 minut. Ani w 10. Godzina to też mało. Jeśli planujecie się w to bawić – należy liczyć 3, 4 może nawet 5 godzin. Wykonując opisaną konfigurację wyłączałem FSX kilkadziesiąt razy (po kilka na każdy etap testów). Warto resetować komputer (kilka razy). Wszystko po to, żeby wyniki były powtarzalne i nieobarczone błędem wynikającym z chwilowego obciążenia komputera.

Czy mogę Ci wysłać swój fsx.cfg?

Mogę. Często ktoś o to pyta. Ale to nie ma większego sensu! Mój plik cfg jest ustawiony pod mój system – procesor (i5 @ 4,2GHz), kartę graficzną (GTX 1060), scenerie (Global, Vector + wymagające lotniska) i samoloty (A2A, PMDG).

Poza tym – mój fsx.cfg się zmienia. Jeśli zauważę problemy – natychmiast zacznę modyfikować ustawienia – pierwsze „polecą” wielkie tekstury (4096 -> 2048, a pewnie nawet do 1024). Potem autogen (są miejsca gdzie Very Dense to jednak zbyt wiele). Następne są cienie (choć z tą kartą może nie będę musiał się ich pozbywać).