FSX - Ustawienia, optymalizacja i tweakowanie

[PZL Belfegor]

Chęć uzyskania ładnego wyglądu i płynności w FSX łączy wielu, jeśli nie wszystkich użytkowników symulatora Microsoftu. Widać to po wielu poradnikach, długich na dziesiątki stron tematach o sprzęcie i optymalnych ustawieniach a także wzroście sprzedaży superkomputerów, głównie HAL, GlaDOS i Deeep Thought (sprzedano dokładnie 42).
Opcje możliwe do ustawienia za pomocą interfejsu FSX są nieco szersze niż w FS9, lecz dopiero edycja fsx.cfg pozwala na precyzyjną konfigurację i osiągnięcie optymalnej wydajności i wyglądu. Ten krótki poradnik ma przybliżyć za co dokładnie odpowiada dany suwak lub ptaszek oraz jaki ma wpływ na wydajność oraz wygląd. Trochę miejsca poświęcam tweakom fsx.cfg, jednak to bardzo mały wycinek tematu - rzeki, dlatego też na końcu znajdują się linki do poradników i tweaków, które najbardziej przypadły mi do gustu. Akapit czy dwa zajęło małe i bardzo ogólnikowe wprowadzenie do sprzętu, jakim warto się zainteresować, by FSX chodził przyjemnie.

FSX i jego wersje



FSX dostępny jest w dwóch wersjach, standard i deluxe; w tej drugiej dostępny jest SDK, więcej samolotów, misji i szczegółowych miast oraz lotnisk (lista tutaj), prosty Garmin G1000 oraz wieża kontrolna. Można także pobrać demo FSX oferujące kilka samolotów i wyspę Sint Maarten (oraz limit czasowy), jednak jego wydajność nie jest reprezentatywna - z jednej strony pokazany obszar jest niewielki, z drugiej wersja demonstracyjna pochodzi z czasów przed service packami. Pierwszy patch, SP1 (nie mylić z analogicznie nazywanymi poprawkami dla systemów operacyjnych Microsoftu) poprawił trochę bugów i znacząco zwiększył wydajność, wprowadzając przede wszystkim wsparcie dla wielordzeniowych procesorów. SP2 wniósł jeszcze trochę poprawek, nieco polepszył wydajność i wprowadził kompatybilność z Acceleration oraz tryb DX10 preview, o którym więcej będzie w sekcji o ustawieniach graficznych. Poprawa wydajności po każdej z paczek okupiona jest częściową utratą kompatybilności wstecznej, samoloty z FS9 działały najlepiej w gołym FSX - ale wszak do samolotów dla FS9 najlepszy jest FS9.



Oficjalny, płatny dodatek Acceleration dodał wszystko to co SP2, a do tego 3 nowe maszyny, wsparcie dla wielosilnikowych helikopterów oraz wciągarek, ADI i uszkodzeń silnika oraz poruszających się lotniskowców wyposażonych w katapulty i liny hamujące, a ponadto kilka scenerii i misji (w tym nowy typ, wyścigi). FSX i Acceleration w jednym pudełku sprzedawane są jako FSX Gold. Zarówno FSX, jak i dodatek zostały oficjalnie spolszczone.
Obecnie powstają właściwie wyłącznie dodatki dla FSX+SP2 i FSX+Acceleration (do działania niektórych statków powietrznych wymagany jest Acceleration, o czym wspomniałem tutaj), jest już ich wcale niemało.
Poradnik dotyczy aktualnych wersji, czyli FSX+SP2 oraz FSX+Acceleration. Przez zabawią z fsx.cfg należy na wszelki wypadek zrobić backup, jednak w razie poważnego zepsucia można go usunąć fsx.cfg - FS sam sobie wygeneruje nowy (z domyślnymi ustawieniami) przy kolejnym włączeniu.

Gdzie jest fsx.cfg



Poniższa sekcja ma oszczędzić kilku ostrzeżeń, osoby nieco obyte z FSem mogą spokojnie opuścić.
W Windowsie XP fsx.cfg znajduje się w C:\Documents and Settings\nazwa użytkownika\Application Data\Microsoft\FSX , a w Viście i Siódemce jest w C:\Users\nazwa użytkownika\AppData\Roaming\Microsoft\FSX .By tam dotrzeć, należy włączyć wyświetlanie ukrytych folderów lub użyć systemowej szukajki (z zaznaczeniem, ze ma szukać w ukrytych). Plik .cfg można otworzyć dowolnym edytorem tekstowym.

Menu ustawień



Nie będę się rozwodzić nad pięcioma podstawowymi suwakami w ogólnym menu settings, gdyż oferują zbyt mała kontrolę nad ustawieniami. Warte odnotowania są za to przyciski „save” i „load”, pozwalające zapisać aktualne ustawienia – w ten sposób można zrobić sobie profile dla poszczególnych scenariuszy (VFR, IFR, maszyny szczególnie obciążające komputer itp.) i błyskawicznie zmieniać ustawienia. Uwaga, ustawieniami widocznymi na screenach nie należy się sugerować, w żadnym razie nie jest to układ zapewniajmy optymalną wydajność – ta zależy od zbyt wielu czynników, by w każdym przypadku dało się ją uzyskać przy takim samym położeniu suwaków.


Opcja działa nawet podczas lotu - po aktywowaniu belki za pomocą alta, można ją znaleźć w menu settings .

Dźwięk



Pierwsze menu dotyczy ustawień dźwięku – tutaj można dobrać głośność silników, kokpitu, otoczenia oraz głosów, wybrać używane urządzenia (dźwięki i ATC można rozbić na dwa różne – popularny scenariusz to dźwięki w głośniczkach, a głosy w słuchawkach), a także wyłączyć dźwięki interfejsu i tragiczną muzyczkę w menu. Podczas lotu wszystkie odgłosy można wyłączyć z pomocą Q (nie ma co liczyć na katapultę fotelu pasażera), co pozwala czasami zyskać kilka FPS.

Sterowanie



Kolejne menu to ustawienia sterowania, z którego poziomu da się wywołać także systemowe narzędzie do kalibracji. Tutaj można wybrać kontroler i ustawić jego czułość oraz martwą strefę, przypisać akcje do klawiatury i myszy a także przycisków oraz osi (oddzielnie do trybu slew), a ponadto włączyć poszczególne składniki force feedbacku, o ile oczywiście kontroler jest wyposażony w sprzężenie zwrotne. Oferowane przez FSX możliwości nie wystarczą wszystkim, na dużo szerszy zakres konfiguracji pozwala zarejestrowany FSUIPC.


Interfejs FSUIPC nie należy do najpiękniejszych, ale narzędzie to ma ogromne możliwości.

Realizm



W opcjach realizmu ustawienia są dosyć oczywiste – 5 suwaków pozwala na ustawienie ogólnego realizmu lotu (im mniejszy, tym samolot jest bardziej stateczny), wpływu asymetrycznej siły ciągu śmigła, momentu obrotowego, precesji żyroskopowej oraz tolerancji kraks. Poszczególne efekty są szerzej omówione w stosownych wątkach na forum, dlatego tutaj poprzestanę na poradzie, by 4 pierwsze suwaki ustawić maksymalnie w prawo (przeważnie porządne samoloty przy takich ustawieniach zachowają się najbliżej ich prawdziwym odpowiednikom – oczywiście jest kilka wyjątków, ale o tym wspomina instrukcja dołączona do dodatku), a kraksy proponuję wyłączyć. FS kiepsko sobie radzi z uszkodzeniami samolotu, model zniszczeń praktycznie nie istnieje (nie licząc właściwie zerojedynkowego crash/brak crasha ), a teleportowanie się na miejsce startu przez zawadzenie o niewidzialny element scenerii jest szczególnie niepożądane podczas lotów w sieci.


FSowy crash – ani to ładne, ani realistyczne.

Kolejne opcje dotyczą kontroli świateł (pewnie każdy woli samemu popstrykać), precesji przyrządów żyroskopowych (przy niektórych samolotach instrukcje radzą wyłączyć, ogólnie opcja może być włączona – wtedy co jakiś czas żyroskop należy korygować, jeśli nie dzieje się to automatycznie) oraz wyboru czy na wskaźnikach ma być pokazywana prędkość przyrządowa, czy prawdziwa – oczywiście należy wybrać IAS.

W drugiej kolumnie można wyłączyć podpowiedzi w ramkach (ja wolę by FS mi nie proponował wciskania ctrl+e ani ustawiania ciśnienia na całym świecie według amerykańskich TA i TL), włączyć kraksy i wybrać, czy siły działające na samolot mają powodować uszkodzenia oraz czy mają być wykrywane kolizje z innymi statkami powietrznymi



Poniżej ustawić można automatyczną regulację mieszanki (co to za zabawa), nieskończone paliwo (z tego co czytałem wraz ze spalaniem masa samolotu prawidłowo spada, ale silniki działają nawet przy pustych bakach) oraz czy silnik można zepsuć przez przekraczanie parametrów eksploatacyjnych (opcja dostępna jedynie dla posiadaczy dodatku Acceleration).


Mustang subtelnie daje do zrozumienia o kresie jego możliwości.

Przedostatnia opcja kontroluje black- i redouty wywoływane przeciążeniem (nie pojawia się jednak charakterystyczna tunelowość widzenia), a na samym dole można włączyć autorudder – wtedy na ziemi oś lotek kontroluje skręt podwozia, a w powietrzu zakręty są automatycznie koordynowane (opcja skierowana głównie do latających na klawiaturze, samym wolancie lub mniej niż trzyosiowym dżojstiku).




Efekty pchania i ciągnięcia drąga, w Flaming Cliffs zrealizowano je sporo fajniej.

Ustawienia generalne



Opcje generalne pozwalają na wyłączenie ekranu powitalnego, automatyczne włączenie pauzy gdy FS nie jest aktywną aplikacją (np. po złożeniu na pasek zadań), włączenie zapytania czy na pewno chce się wyjść z FSa (niezależnie od tej opcji, ctrl+pause/break kończy aplikację bez pytania) i synchronizację czasu domyślnego lotu z czasem systemowym. Poniżej można włączyć napisy w misjach, oraz aktywować podpowiedzi – wskaźnik i kompas.
W kolumnie po prawej można wybrać wyświetlanie wiadomości ATC w oknie rozmowy, włączyć automatyczne otwieranie okna oraz wybrać jeden z dostępnych głosów. W rozwijanym menu mamy do wyboru trzy ustawienia jednostek (odległości, masy, wysokości, ciśnienia), a nico niżej możemy wybrać domyślne współrzędne geograficzne w oknie mapy (4 kombinacje).

Biblioteka scenerii



Ostatni przycisk przywołuje bibliotekę scenerii, której sens przybliżałem tutaj. Przyciskami po prawej można zmienić priorytet wybranej scenerii, dodać nową (w Windowsie 7 po akceptacji należy jeszcze kliknąć gdzieś na obszarze okienka eksploratora, by to znikło), usunąć scenerię z listy lub edytować wybór. Za pomocą ptaszka przy nazwie scenerii można określić, czy będzie ona aktywna. Dostępna tu opcja dotyczy czyszczenia cache’u scenerii przy wychodzeniu z FSa i skierowana jest do użytkowników trzymających aktywne scenerie na nośnikach wymiennych. W przeciwieństwie do FS9, po dodaniu scenerii nie trzeba restartować symulatora.

Szybko i ładnie, wolno i brzydko – możliwe?

Teraz pora na najciekawszą część, czyli ustawienia graficzne które mają największy wpływ na płynność działania symulatora. Przed przystąpieniem do opisu właściwego konieczny jest krótki wstęp, w którym przedstawię swoje jedynie słuszne™ opinie.
Jeśli kolega/rodzic/kochanka/proboszcz/zwierzątko domowe twierdzą, że FSX śmiga im w maksymalnych ustawieniach na tosterze – kłamią albo nie mają pojęcia o czym mówią. Przy średnim sprzęcie mając suwaki na prawo można spokojnie osiągnąć kilkadziesiąt FPS… na pauzie, wysoko nad jakimś pustkowiem, w bezchmurny dzień i do tego w prościutkim samolocie. By FSX chodził akceptowalnie dobrze, należy kupić topowy sprzęt, zastosować sprawdzone tweaki lub porzucić marzenie o wyśrubowanych ustawieniach. A najlepiej to wszystko na raz, oczywiście pamiętając, że tweaki pomagają, ale nie zwiększają wydajności w magiczny sposób.
Tutaj nie można nie napisać o fetyszu maksymalnych ustawień, na których cierpi wielu graczy (nie tylko użytkowników symulatorów). Otóż w FSX nie ma to sensu – z jednej strony ustawienia wyższe niż dostępne w menu można narzucić w fsx.cfg, a z drugiej przykładowo pewna sceneria przy ustawieniach niskich może wyglądać znacznie lepiej niż inna przy najwyższych… Nawet, gdy osiągnie się ten rzadki stan zadowolenia z wyglądu i płynności, zaraz pojawi się wyśmienita sceneria, powalający samolot i znów zacznie się pokaz klatek – właśnie dlatego warto mieć kilka konfiguracji ustawień na różne okazje. Należy się skupić na tym jak symulator działa i jak wygląda, a dopiero potem zastanawiać, jak są ustawione suwaczki i czy to jest ten „max” – pozwoli to zaoszczędzić sporo czasu i nerwów.
Na wszelakich forach można wyczytać mnóstwo opinii, jak tragicznie działa FSX i jaką jest porażką Microsoftu… to nieco przesadzone twierdzenia. Za FSX ciągnie się stary silnik i próba zachowania kompatybilności z dodatkami do FS9 (co wyszło jak wyszło), ale w porównaniu z innymi symulatorami nie działa tak źle, biorąc pod uwagę jego dość otwartą strukturę. Wiadomo, że nie ma mowy o płynności takich Hawx czy Wings of Prey (a porównywanie z FPSami w ogóle nie ma sensu, bo to zupełnie inna liga – wystarczy choćby tylko zwrócić uwagę na wielkość mapy czy zasięg widzenia), lecz to programy mniej złożone, w których świat nie składa się z mnóstwa kawałeczków, tylko z dobrze dobranych, zoptymalizowanych elementów – zamknięta architektura również na pewno ma niebagatelny wpływ na wydajność.
Nadal nie ma sprzętu, w którym połączenie FSX+dodatki+maksymalne ustawienia da permanentną płynność, jednak i na sprzęcie obywającym się bez chłodzenia ciekłym azotem przy sensownych ustawieniach można mieć powyżej 30 FPS przez większość czasu.
Po przydługim wprowadzeniu możemy w końcu przejść do meritum.

Ustawienia graficzne



Na pierwszej z pięciu kart możemy wybrać kartę graficzną, rozdzielczość wraz z głębią kolorów (w dobie monitorów LCD najlepiej jest zdecydować się na natywną w 32-bitach), wybrać rodzaj filtrowania (dwu- i trójliniowe oraz anizotropowe) i włączyć antialiasing. Dwie ostatnie opcje nie pozwalają na precyzyjny wybór, dlatego radziłbym ustawiać je z poziomu sterowników grafiki, o ile jest to możliwe (przykładowo, FSX czasami buntuje się przeciwko zmianom w ostatnich sterownikach Nvidii, także nHancer nie chce z nimi współgrać). Przy starszej karcie graficznej zmiana wydajności jest mocno odczuwalna, obecnym AA i anizo nie straszne. 



Antialiasing – różnica akurat niezbyt wielka(AA FSowe), aczkolwiek widoczna. Zastosowanie AA wymuszonego przez kartę graficzną pozwala uzyskać lepsze rezultaty.



Filtrowanie anizotropowe – polecam zwrócić uwagę na kotwicę i skrzydło. By zobaczyć pełen rozmiar, należy kliknąć w obrazek raz jeszcze.

Nieco wyżej znajduje się suwak, za pomocą którego można dobrać maksymalną liczbę wyświetlanych klatek. Nie robi on nic poza ustawieniem górnego limitu (FS nie będzie zmniejszał ustawień, by osiągnąć ustawioną wartość ani nic w tym stylu). Blokowanie klatek ma sens, gdyż nawet i 20 FPS potrafi wyglądać płynniej, niż obraz który co chwila skacze z 40 na 90 FPS. Jednak jak można łatwo zaobserwować, przy zablokowanych klatkach często wydajność spada – przykładem niech będzie blokada na 30 FPS, FS wyświetla 26 klatek, bez blokady 32. Sugeruję używanie blokady gdy liczba klatek na sekundę skacze, a pozostawienia na unlimited, gdy przeskoki nie mają miejsca. Niektórzy używają także zewnętrznego programu ograniczającego liczbę wyświetlanych klatek, FPS Limiter v0.2, w którym opisany problem zmniejszenia FPS spowodowanego blokadą nie powinien występować.


Przykład bardziej spektakularnej różnicy – tak też się czasem zdarza.

Tutaj pora na wstawkę liryczną. Telewizja pokazuje 24 klatki na sekundę i to ta wartość jest przedstawiana jako odpowiednia, by ludzkie oko postrzegało obraz jako płynny – ja jednak nie uważam tego za prawdę. Wszak w telewizji dochodzi rozmycie, głębia ostrości i kilka innych zjawisk– dzięki temu obraz wygląda na płynny. Ponadto pewnie każdy ma nieco inny próg, jednym wystarczy 30 klatek, inni odróżnią 45 FPS od 60 i nadal będzie im mało. Jak wyglądają 24 klatki na sekundę bez rozmycia można zobaczyć tutaj (polecam przeczytanie całego artykułu). Przed gonieniem za dziesiątkami FPS warto sprawdzić z jaką prędkością odświeża się monitor, bo przeciętny LCD nie wyświetli więcej niż 60, 75 klatek na sekundę.
FSX jest uważany za płynniejszy od FS9 przy takich samych wskazaniach FPS – sam nie przeprowadziłem testów, jednak w związku ze zmianami w silniku jest to prawdopodobne. Można się spotkać z opiniami, że w FSX przy 15-20 FPS obraz jest płynny – według mnie da się latać, jednak niezgorsza płynność zaczyna się od około 35 klatek.

W prawej części można wybrać górny limit rozdzielczości tekstur – ze względu na coraz częściej używane tekstury w rozdzielczości wyższej niż 1024x1024 (zwane HD, SHD, UHDT itp. – byle występowało chwytliwe HD), warto w fsx.cfg wybrać maksymalne 4096x4096. Niższe ustawienie pozwoli na używanie mniejszych tekstur, co przyda się użytkownikom kart graficznym z mała ilością pamięci.



Posiadacze Windowsa Visty i Siódemki oraz odpowiednio nowej karty graficznej mogą aktywować tryb DX10 preview – chciałbym zaakcentować „preview”, oznaczający przedsmak tego co by było gdyby zaimplementowano to porządnie.
DX10 dodaje dynamiczne (i brzydko poszarpane) cienie w VC, trochę zmieniony i mniej klatkożerny efekt blooma, nowe efekty wody (z falami reagującymi na kierunek wiatru i jego siłę, mogą się pojawić białe grzywy) oraz kilka optymalizacji. Włączenie DX10 preview powoduje zazwyczaj pewne zwiększenie wydajności, kłopoty z migającymi teksturami (flickering i shimmering), możliwość ustawiania AA tylko do 2x, niepoprawne wyświetlanie niektórych tekstur, tooltipsów i samolotów-portów. Dla mnie niedogodności przewyższają jego zalety, ale na pewno znajdzie się garstka zwolenników trybu DX10.




DirectX 10 – można zaobserwować inną wodę, cienie w kokpicie i niskie AA.

Opcja lens flare pozwala na uzyskanie efektu rozproszenia światła na obiektywie kamery – efekt nie obniża wydajności, ale nie wszystkim się podoba. Domyślnie widać go jedynie z kamer poza samolotem.



Light bloom (w polskiej wersji przetłumaczony przez jakiegoś żartownisia jako „rumieniec świetlny”) powoduje rozświetlenie i odblask światła od jasnych elementów, co pięknie wygląda na screenach i obniża liczbę klatek o połowę, bo wymaga dodatkowego renderowania sceny. Mniejszym kosztem poświatę można otrzymać dzięki zastosowaniu szeroko konfigurowalnej wtyczki ENB (można zrobić efekt noktowizora, sepii, pobawić się kolorami i jaskrawością i tak dalej).



To złudzenie, wbrew pozorom pasy są równoległe.

Zaawansowane animacje pozwolą na wyświetlanie animowanej siatki oraz kości, bez czego modele wyglądałyby niepoprawnie, opcja ta powinna być zawsze włączona.
Ostatni wybór to kwestia kosmetyczna, pozwala zadecydować czy wyświetlane komunikaty mają być wyświetlona jako jedna przesuwająca się linijka, czy jako blok tekstu.

Ustawienia samolotu



W zakładce ustawień samolotu możemy wybrać domyślny widok (panel lub VC – w czasie lotu zawsze można zmienić klikając domyślnie F9 i F10, obecnie od paneli odchodzi się na rzecz trójwymiarowych kokpitów), włączyć wyświetlanie podpowiedzi pojawiających się po najechaniu myszką na element VC (przełącznik, zegar, popielniczkę o ile autor samolotu to przewidział), wybrać wysokiej jakości wskaźniki (przy niskiej kokpity prezentują się bardzo marnie) i dobrać przezroczystość panelu. Użytkownicy z manią ustawiania wszystkiego na prawo często dziwili się, dlaczego nie widzą okienek panelu…


Półprzezroczysty panel. Zaiste, wygodne…


Podpowiedź dla zapominalskich.


Wskaźniki w niskiej rozdzielczości i normalne. Jak widać, cały panel radia jest gaugesem.

W prawej kolumnie włączyć możemy cień samolotu na ziemi (widoczny także z VC, nie jak w FS9), klatkożerny gdy mamy do czynienia ze złożonym modelem oraz cień samolotu na samym sobie, czyli self-shadowing. Normalnie działa jedynie na model zewnętrzny, w trybie DX10 cieniować się będzie także VC – cały efekt wygląda tak samo fajnie jak obniża wydajność. Ostatni ptaszek pozwoli nam na używanie świateł lądowania podświetlających ziemię.




Trzy konfiguracje cieni i trzy duże obrazki, bo lubię tego Tiger Motha.


Światła – nawet te nieoparte na kościach w miarę oświetlają teren.

W tym akapicie można też omówić, dlaczego pewne samoloty są klatkożerne, a inne nie. Duże obciążenie dla komputera może być powodowane przez aspekty głównie graficzne, przede wszystkim liczbę drawcalli, która zależy od ilości poligonów tworzących model oraz materiałów mu przypisanych. Kiepsko zrobiony model z mało szczegółową siatką może być bardziej wymagający od samolotu składającego się z kilkakrotnie większej ilości trójkątów. To mniejsze piwo, bo zazwyczaj karta graficzna nie jest wykorzystywana do kresu możliwości i do pewnego stopnia może znieść taki model. Aspekty systemowe, czyli ilość klikanych miejsc w kokpicie, dwuwymiarowe wskaźniki z naciskiem na MFDki wysokiej rozdzielczości oraz (w bardzo niewielkim stopniu) logika awioniki obciążają procesor – tutaj już zazwyczaj rezerwy nie ma, stąd też domyślna Cessna z Garminem działa zauważalnie wolniej od tego samego modelu z tradycyjnymi wskaźnikami.

Ustawienia scenerii



Opcje dotyczące scenerii dają do zabawy multum suwaków, a wpisy w fsx.cfg jeszcze bardziej rozszerzają paletę opcji.
Pierwszy suwak odpowiada za zależność poziomu detali od odległości, kontroluje jak daleko od kamery będą ładowane szczegółowe obiekty i tekstury. Ustawienie to ma bardzo wyraźny wpływ na wydajność i szybkość ładowania tekstur – warto wiedzieć, że 2 razy wyższe ustawienie LOD radius oznacza 4 razy więcej danych do wczytania i wyświetlenia. Wartość maksymalna wybierana za pośrednictwem interfejsu to 4.5, kiedyś w fsx.cfg ustawiłem na 12 – po niesamowicie długim wczytywaniu było pięknie i ostro, każda klatkę mogłem podziwiać przez dłuższy czas, a potem co nie było zaskoczeniem zostałem uraczony błędem OOM.








Ustawienie niskie, średnie i wysokie, czyli 2.5, 3.5 oraz 4.5.

Kompleksowość meshu kontroluje, w jakiej odległości od kamery siatka wysokościowa będzie traciła swą szczegółowość. Im wyżej ustawiona, tym większa odległość i mniejszy stopień utraty detali.








Kompleksowość ustawiona na 0, 50 i 100. Na miniaturce niewiele widać, na screenach w pełnym rozmiarze zmiany są lepiej widoczne.

Za pomocą tego suwaka można ograniczyć rozdzielczość meshu. Mając mesh 76-metrowy ustawienie na 38 nic nie da, jednak przy 38-metrowym meshu ustawienia na 76 spowoduje obniżenie rozdzielczości siatki i zwiększenie wydajności.







Rozdzielczość meshu ustawiona na 152, 76 i jakieś 10 metrów. Warto zobaczyć, że przy kompleksowości 0 i rozdzielczości 10 mesh w oddali jest znacząco gorszy, a w pobliżu nieco lepszy niż przy kompleksowości 100 i rozdzielczości 152m.

Analogicznie można postąpić z teksturami – ustawiając na 5 metrów można zobaczyć, jak by to wyglądało w FS9, a przy wyborze 7 cm podziwiać elementy dodatkowych fotoscenerii w ogromnej rozdzielczości, o ile takowe zamieścił twórca.
Ustawienia suwaka na rozdzielczość większą niż dostępna (np. 60 cm przy teksturach dwumetrowych) może powodować dłuższe wczytywanie przez konieczność przeskalowania materiału i wolniejsze działanie symulatora – ja specjalnego wpływu na wydajność w takiej sytuacji nie zaobserwowałem, choć nie przeprowadzałem pomiarów ze stoperem i nie mogę się definitywnie wypowiedzieć na ten temat.



Pięć metrów zbliżone do FS9 i na oko jeden metr.

Przy najniższym ustawieniu suwaka jakości wody praktycznie jej nie ma, a przy najwyższym skrzy się i odbija wszystko pożerając mnóstwo mocy obliczeniowej. Ustawienie none powoduje, ze wyświetlane są po prostu tekstury „podłoża” wody, przy 1.x low dochodzi podstawowe cieniowanie (shadery 1.0) w postaci animowanych fal, przy mid pojawia się odbicie podobne do znanego z FS9, a przy high specular (nie udało mi się dostrzec różnicy między 1.x mid a high). Ustawienie na 2.x włącza animowaną bumpmapę, bardziej zaawansowane shadery (2.0) oraz prawdziwe odbicia, co wymaga ponownego wyrenderowania sceny i zabiera sporo FPS. Low 2.x odbija niebo (słońce, księżyc, gwiazdy) i nasz samolot, przy mid dochodzą chmury, przy high teren, a przy max wszystko, czyli także sceneria i autogen. Za najlepszy stosunek wyglądu do pożeranych zasobów uważam low 2.x, brak części odbić przy odpowiednio niespokojnych falach nie kłuje w oczy. Fale w DX10 składają się z większej ilości tekstur, reagują na wiatr i mogą się pienić.



Woda 2.x jakby płytsza…

Opcja land detail texture włącza wyświetlanie „szumu” urozmaicającego wygląd tekstur ziemi, ja wybrałem trawkę.


Oczywiście legalną. Tajemnicą pozostaje przyczyna zmiany koloru linii.

Szczegółowość scenerii oferuje 6 opcji do wyboru, od very sprase do extremaly dense. Ostatnia opcja wyświetla wszystko, wraz z przesuwaniem suwaka w lewo znikać będą elementy scenerii. Które dokładnie będą wyświetlane przy określonym położeniu suwaka zależy od twórcy scenerii, dlatego jedno lotnisko może wyglądać świetnie przy ustawieniu normal, a inne bardzo łyso. Jak będzie wyglądała liczba klatek na sekundę zależy od wielkości, szczegółowości i optymalizacji scenerii, dlatego nie można zaproponować jednego, uniwersalnego ustawienia.







Domyślne Las Vegas przy ustawieniach very sprase, normal i extremaly dense. Znajdź dziesięć szczegółów…

Gęstość autogenu również można ustawić na jedną z 6 pozycji, nawet przy sprase domków i drzewek jest więcej niż w FS9. Autogen potrafi drastycznie obniżyć wydajność, dlatego nie proponuję wybierania więcej niż normal czy dense – już przy tych ustawieniach na ziemi jest całkiem gęsto. Gdy karta graficzna nie wyrabia z przyjmowaniem danych, z autogenu lubią się zrobić charakterystyczne kolce, bywa też że zawisa on w powietrzu. Czasami samoczynnie to znika, czasami kończy się błędem OOM.
Ilość budynków na komórkę można zwiększyć lub zmniejszyć w fsx.cfg. Po ustawieniu maksymalnej wartości suwak w opcjach FSa reguluje, jaki ułamek obiektów będzie mógł być wyświetlony (przy wpisie n i suwaku na pół skali, wyświetlone będzie 0.5n obiektów). Tutaj również zalecam ustawianie w zależności od obszaru, nad którym latamy i raczej redukcję domyślnych wartości.


Autogen nieco zlał się z podłożem, ale coś widać… zwłaszcza na pierwszym screenie. Ustawienia to kolejno brak, normal i extremaly dense.

Poniżej możemy zaznaczyć rzucanie cieni przez scenerie – odradzam. Nie dość, że opcja ta powoduje odczuwalny spadek wyraźności, to w dodatku przeważnie cienie nie radzą sobie z pofalowanym terenem i wygląda to kiepsko, gdy szary zarys unosi się nad podłożem.


Jak widać, i obiekty scenerii mogą rzucać cień na siebie.

Ostatnia z opcji znalazły się tu chyba przypadkiem, gdyż nie jest stricte związana ze sceneriami. Suwak określa gęstość efektów cząsteczkowych, takich jak rozpryski wody, smugi kondensacyjne i dym. Ze względu na kilka samolotów, które potrafiły wygenerować dym niesamowicie obniżający wydajność (do pojedynczych klatek na sekundę) ustawiłem u siebie na pół skali, by nie musieć pamiętać o zmianach przed wyborem tych kilku maszyn.

Ustawienia pogody



Opcje pogody pozwalają ustawić w jakiej odległości mają być rysowane chmury (2 razy większa odległość oznacza 4 razy więcej chmur) oraz jak mają wyglądać – można wybrać płaskie chmury z czasów FS2002 lub trójwymiarowe, a w przypadku tych drugich ustawić także ich gęstość (overcast przy niewielkiej gęstości nie będzie overcastem). Suwakiem pokrycie można ustawić do 8/12, edytując fsx.cfg można narzucić maksymalną wartość.


Zasięg rysowania chmur – 60, 80 i 110 mil.

Tutaj także włączyć można wizualizację kominów termicznych – mogą to być spiralne strzałki lub ptaki przy ustawieniu natural.


Ptaki trudno dostrzec będąc poniżej, bo to Haliaeetus Stealthius - ich skrzydła są od spodu przezroczyste.

Nieco niżej zaznaczyć można, by FS pobierał także dane o przypuszczalnych wiatrach na wysokościach przelotowych oraz by turbulencje i prądy powietrza nie oddziaływały na nasz samolot. Ostatni suwak wskazuje, jak szybko ma się zmieniać pogoda (podejrzewam, ze ma wpływ głównie gdy używamy FSowej opcji ściągania aktualnej pogody).

Ustawienia ruchu AI



Ostatnia opcja dotyczy ruchu samolotów sterowanych przez AI (artificial inteligence – w wypadku FSX to po polsku „prawdziwa głupota”). Ruch bardzo obciąża procesor, a także kartę graficzną – wystarczy pomyśleć o zarządzaniu tysiącami lotów gdzieś tam w tle oraz o wyświetlaniu setek modeli na widocznym lotnisku. Mamy 2 suwaki do kontroli samolotów pasażerskich oraz GA, ustawienie gęstości pojazdów lotniskowych, samochodów na drogach (niesamowicie klatkożerne), statków i promów oraz jachtów. Dwóch ostatnich nie ma specjalnie po co włączać do lotów nad lądem, ustawianie ruchu drogowego powyżej 10% to proszenie się o pokaz klatek, a ruch samolotów regulować podług własnych upodobań i aktualnego obciążenia procesora. W ramce po prawej można wybrać, czy i co ma być prezentowane na migającym napisie nad samolotami AI (oraz własnym samolotem, jeśli ktoś ma krótką pomięć i nie pamięta czym leci) a także kolor i częstotliwość zmian napisów.


Seria zbędnych screenów, bo AI i tak każdy widział. Tak wygląda GA…


IFR…


Ruch drogowy…


Jachty…


Statki i promy…


I w końcu pojazdy lotniskowe, lubiące podskakiwać przy wczytywaniu scenerii.

System i sprzęt do FSa

Bez przynajmniej sensownej konfiguracji nawet znając na wylot wszystkie opcje i swoistości FSa niewiele się zdziała. Poniżej postaram się podać podstawowe cechy komponentów, na jakie należy zwrócić uwagę kupując sprzęt pod kątem FSX.

System: XP, Vista lub Siódemka, dwa ostatnie o ile możliwe w wersji 64-bitowej. Pozwoli to na wykorzystanie więcej niż 4GB RAMu oraz korzystanie z dedykowanych 64-bitowych aplikacji. XP to dobry system, jednak jego 64-bitowa wersja pozostawia wiele do życzenia, Vista budzi wiele kontrowersji lecz pewnie nie jest aż taka zła jak ją przedstawiają, a Siódemkę mogę samemu polecić.

Procesor: optymalnie 4 rdzeniowy o możliwie szybkim zegarze. FSX potrafi wykorzystać dodatkowe rdzenie do ładowania scenerii, jednak kupowanie sześciordzeniowa jedynie dla FSX jest zwyczajnie nieopłacalne. Dla FSX, jak to symulatora, CPU jest podstawą i najbardziej ze wszystkich komponentów wpływa na ogólną wydajność. Szybki dwurdzeniowiec będzie się spisywał akceptowalnie, lecz ładowanie scenerii będzie przebiegać wolniej, z procesorem jednordzeniowym lepiej zostać przy FS9. Podkręcanie pozwoli zauważalnie zwiększyć wydajność stosunkowo niewielkim kosztem (dobre chłodzenie powietrzne to kilkaset złotych, wodne jest jednak dużo droższe, choć pozwala wyciągnąć jeszcze więcej), jednak trzeba się zastanowić, czy warto narażać gwarancję i stabilność. Ja po zapoznaniu się z teorią stwierdziłam, ze nie zaryzykuję – wprawdzie spalić procesor nie jest wcale tak łatwo, a przez obawy nie wyciągam z mojego CPU wszystkiego co potrafi, lecz dzięki temu mam w obudowie chłodniej i wiem, że jakiś błąd czy nieprawidłowość na pewno nie jest spowodowana moimi zabawami w BIOSie. Na dodatkowe rdzenie można też przerzucić programy działające w tle, a w fsx.cfg można narzucić, które rdzenia mają być używane przez symulator (intelowskie HT nic tutaj nie daje). Nieco sprawę upraszczając, Intele są teraz szybsze, a AMD tańsze – radziłbym przy zakupie kierować się zasobami finansowymi i wydajnością, a nie sympatią do którejś z marek.

Płyta główna: solidna (w końcu to podstawa m.in. podstawy!), oferująca odpowiednio dużo wszelakich gniazd i możliwość podkręcania, nawet jeśli się tego nie planuje – zawsze lepiej mieć więcej opcji. Niegłupia byłaby także długa gwarancja. Wystarczy jeden slot PCI-E 16x (AGP to pieśni przeszłości), pod kątem FSX nie warto kupować płyty wspierającej SLI ani Crossfire, także 2 karta dedykowana obsłudze fizyki nie ma sensu – FS jej nie wykorzysta.

RAM: 4GB dla systemu 32-bitowego, jakieś 6GB dla 64-bitowego powinno starczyć. Różnicy między RAMami o różnych prędkościach czy timingach, o ile parametry te nie będą bardzo kiepskie podczas lotu raczej się nie odczuje – dopiero przy podkręcaniu opóźnienia i megaherce stają się istotne. Użytkownicy systemów 32-bitowych mogą użyć switcha 3GB, pozwalającego aplikacjom użyć więcej pamięci, co jednak może wiązać się z utratą stabilności.

Zasilacz: to istotny element, na którym nie warto oszczędzać i należy wybrać renomowaną firmę – dobry zasilacz o mocy 500W będzie lepszy od 650-ki firmy bez nazwy. Musi nie tylko mieć wystarczającą moc, ale także dostarczyć odpowiednio dużo amperów i charakteryzować się stabilnością, fajnie jeszcze by był cichy.

Dyski: jeśli kieszeń pozwoli duże i szybkie – minimum 7200rpm, albo duży i szybki – duży jako archiwum (bo dodatków potrafi się zebrać sporo, a po przygodzie z Avsimem lepiej jednak mieć wszystko u siebie), szybki do FSa. RAID na pewno znacząco skróci czas ładowania, a dyskom SSD głównie ze względu na stosunek rozmiaru do ceny radzę dać dojrzeć – obecnie na dysku w rozsądnej cenie zmieści się niewiele więcej poza systemem i garścią programów. Defragmentacja w przypadku tradycyjnych twardzieli jest nieodzowna – istnieją do tego wyspecjalizowane programy, ale i narzędzie systemowe da radę.

Obudowa: odpowiednio duża, by pomieściła wszystkie bebechy i przewiewna by w środku nie powstała sauna. Co jakiś czas warto przedmuchać, bo w środku lubi gromadzić się kurz utrudniający wymianę ciepła. Wbrew pozorom niebieski, pulsujący neon nie zwiększy wydajności ani zainteresowania dziewoi.

Karta muzycznaa: FSX nie wspiera EAX ani podobnych bajerów (w stosunku do FS9 doszły jedynie stożki dźwięku i wsparcie 5.1), jednak karta muzyczna pozwoli nieco odciążyć procesor, który nie będzie się musiał teraz zajmować dźwiękami.

Karta graficzna: często można przeczytać, że nie warto inwestować w dobrą kartę graficzną, bo dla FSX liczy się procesor, a na reszcie można oszczędzać. To, jak nietrudno się domyślić, półprawda. Powiedzenie, iż komputer jest tak szybki jak jego najwolniejszy element sprawdzi się tu, o ile dodamy „w określonej sytuacji”. Zależnie od tego, czego zażądamy od FSX wąskim gardłem może być inny element, co na uproszczonym przykładzie postaram się zilustrować poniżej.



Sytuacja pierwsza to podejście nad lotnisko pełne AI samolotem wyposażonym w wyświetlacze wysokiej rozdzielczości, z pogodą ładowaną tle i działającym radarem pogodowym. Procesor wyciska siódme poty, karta graficzna też nie odpoczywa, ale to właśnie CPU doszło do kresu możliwości – wsadzenie wypasionej grafiki nie spowoduje tu wzrostu FPS.



Sytuacja druga, lecimy sobie spokojnie samolotem wyposażonym w trójwymiarowe wskaźniki nad rozległym lasem, gdzieś tam skrzy się powierzchnia wody, ruch AI jest niewielki, antialiasing i filtrowanie anizotropowe mamy ustawione bardzo wysoko. Procesor mógłby rozbujać się bardziej, lecz karta graficzna nie wyrabia się z renderowaniem i ogranicza nam liczbę klatek na sekundę. Podkręcenie procesora ani jego wymiana niewiele by tu dały.

W FSie sytuacje podobne do pierwszej mają miejsce dużo częściej niż drugi scenariusz, ale mimo to nie można go zaniedbywać, zwłaszcza że dobra (przez co rozumiem od GTX280 w górę) karta pozwoli nam na zastosowanie tweaka bufferpools=0 (lub RejectThreshold=n w przypadku braku stabilności), dzięki czemu FS odetchnie i pozwoli na zwiększenie kilku suwaków i/lub cieszenie się zauważalnie większą płynnością. W przypadku najnowszych Nvidii i Radeonów wzrost wydajności jest zauważalny nawet bez specjalnego tweakowania.

Zarówno SLI, jak i Crossfire po pewnych kombinacjach działają z FSX, jednak podwyższenie FPS jest dosyć nikłe w porównaniu z ceną 2 kart i odpowiedniej płyty głównej. 3d Vision Nvidii pozwalające uzyskać trójwymiarowy obraz z użyciem specjalnych monitorów (szybkie odświeżanie) i okularów działa, tańsze 3d można uzyskać po ustawieniu obrazu anaglifowego i użycie okularów z kolorowymi szkłami. Do jednej karty Nvidii można podpiąć 2 monitory, u ATI 3 w tych z Eyefinity (SLI i Crossfire pozwalają mnożyć ekrany). Urządzenie pozwalające podłączyć kilka monitorów z użyciem jednego złącza oferuje Matrox. FSX potrafi także wyświetlić obraz na wyświetlaczach z łączem USB. Można pobrać dodatek, dzięki któremu FSX jest w stanie skorzystać z shaderów 3.0 – posiadacze odpowiednich kart ujrzą między innymi poprawioną atmosferę i wodę, a radeonowcy zyskają kilka FPS.

Kontrolery: FSX pozwala używać klawiatury i myszy do sterowania, jednak takie rozwiązanie nie może się równać z dedykowanym kontrolerem. Dobry dżojstik powinien mieć minimum 4 osie (ster wysokości, kierunku, lotki i przepustnica), kilka przycisków i HATa. Bardziej wyspecjalizowany sprzęt to HOTAS lub wolant, do których przydadzą się lotnicze pedały i dodatkowy komplet wajch. Widok można kontrolować za pomocą ruchów głowy wykorzystując Track IRa, HatTraka a nawet pilota od Wii (śledzenie w podczerwieni), a także Cachayę lub darmowego Freetracka (pasmo widzialne). Nabyć można także panele i instrumenty, a nawet kompletne kokpity – jednak cena gotowych komponentów zachęca do budowania samemu.


Rozmycia


Rozmycia, zmora każdego FSowca.


Te też.

Rozmywanie tekstur i ich długie ładowanie, a czasami nawet znikanie już załadowanych szczegółowych tekstur to druga po niskim FPS zmora użytkowników FSX. Gdy symulator nie będzie nadążał z ładowaniem tekstur, będzie po prostu wyświetlał ich wersje w coraz niższej rozdzielczości, co może doprowadzić do zmiany ziemi w rozmazaną plamę (loty Hornetem z Ma 1.5 na wysokości opuszczonych spodni niechybnie się czymś takim zakończą). Także, gdy w pamięci karty graficznej zabraknie miejsca, tekstury w wysokiej rozdzielczości zostaną zamienione na bardziej rozmazane.
Dzięki wpisowi FIBER_FRAME_TIME_FRACTION= w fsx.cfg, można wybrać, ile czasu procesora będzie poświęcane ładowaniu scenerii. Zwiększenie domyślnej wartości 0.33 przyspieszy ładowanie tekstur kosztem ilości FPS, zmniejszenie odniesie odwrotny skutek. Wbrew wielu opiniom, to działa także w przypadku procesorów wielordzeniowych, co sam sprawdziłem.
Bardziej szczegółowo na ten temat można przeczytać tutaj: http://support.microsoft.com/kb/555738

Jak ważna jest ochrona przed wirusami i innymi zagrożeniami nie trzeba nikomu wyjaśniać, podobnie jak pisać o sensie posiadania aktualnego antywirusa i firewalla. Warto jednak wspomnieć o możliwości wyłączenia skanowania FSX – wiele antywirusów sprawdza każdy plik pod kątem infekcji, co potrafi bardzo wydłużyć czas ładowania oraz doczytywania danych podczas lotu i często owocuje małymi, lecz irytującymi przycięciami (microstuttering). Exclude nakaże antywirusowi by nie sprawdzał dziesiątek tysięcy FSowych plików. Nie spotkałem się jeszcze z wirusem dołączonym do dodatku dla FSa (pewnie użytkownicy tych z nieprawego łoża powiedzieliby co innego), dlatego nie uważam tego działania za ryzykowne. Nie można jednak zapomnieć o regularnym skanowaniu (nie tylko pod kątem wirusów – Adaware i Spybota warto używać) i czyszczeniu komputera (CCleaner jest godny polecania). By programy działały najlepiej, dobrze jest aktualizować sterowniki oraz DirectX, a także wyposażyć się w pakiety C++ Redistributable, Javę i Frameworki (nie są kumulatywne, należy zainstalować wszystkie). Warto wiedzieć, że czasami starszy sprzęt woli starsze sterowniki, gdyż aktualne bywają optymalizowane pod najnowsze elementy, w przypadku braku doświadczenia BIOSu natomiast lepiej nie ruszać, jeśli nie ma takiej konieczności.

Użyteczne tweaki

Pora na wymienienie kilku przydatnych modyfikacji fsx.cfg, a także podanie gdzie na temat tweaków bardziej skomplikowanych można dowiedzieć się więcej. Niektóre linki zawierają sprzeczne informacje (np. format ForceFullScreenVSync=True zamiast poprawnego 1), dlatego sugeruję skupić się tylko na tweaku dotyczącym podanego wpisu.

[GRAPHICS]
DAY_THRESHOLD= (0- 65535)
NIGHT_THRESHOLD= (0- 65535)
Określa ilość dodatkowego światła, można sobie przyciemnić lub rozjaśniać dzień i noc.
http://blogs.msdn.com/b/ptaylor/archive ... n-sp1.aspx

SHADER_CACHE_PRIMED_10=
SHADER_CACHE_PRIMED=
ALLOW_SHADER_30=
SHADER_CACHE_VERSION=
Wpisy związane z shaderami, radzę zmieniać zgodnie z radami Jezusa z wątku o shaderach 3.0.
http://forum.avsim.net/topic/283701-boj ... d-for-fsx/

TEXTURE_MAX_LOAD= (64 - 4096)
Linijka odpowiadająca za maksymalną rozdzielczość wyświetlanych tekstur.

HIGHMEMFIX=1
Wpis zapobiegający znikaniu tekstur i artefaktom graficznym.
http://forums1.avsim.net/topic/281538-t ... nclusions/

STALE_BUFFER_THRESHOLD=1024 // (2048 megabytes)
http://forum.avsim.net/topic/280688-gra ... _threshold

ForceFullScreenVSync=1
ForceWindowedVSync=1
Wymuszenie synchronizacji pionowej w trybach pełnoekranowym i okienkowym.
http://forum.avsim.net/topic/283143-fsx-vsync-fix/

[Weather]
CLOUD_DRAW_DISTANCE=
CLOUD_COVERAGE_DENSITY=
Zasięg rysowania chmur i gęstość pokrycia – można narzucić wartości niemożliwe do wybrania z poziomu interfejsu.

[Display]
InfoBrakesEnable=(True/False)
InfoParkingBrakesEnable=(True/False)
InfoPauseEnable=(True/False)
InfoSlewEnable=(True/False)
InfoStallEnable=(True/False)
InfoOverspeedEnable=(True/False)
Włączenie czerwonych napisów informacyjnych.

RUNWAY_LIGHTS_SURFACE_SCALAR=(domyślnie 1.0)
RUNWAY_LIGHTS_VASI_SCALAR=(domyślnie 1.0)
RUNWAY_LIGHTS_APPROACH_SCALAR=(domyślnie 1.0)
RUNWAY_LIGHTS_STROBE_SCALAR=(domyślnie 1.0)
Skalowanie różnych typów świateł.

TEXTURE_BANDWIDTH_MULT=
TextureMaxLoad=
MAX_TEXTURE_DATA=
Linie dotyczące wczytywania tekstur, je oraz limit klatek łączy dość skomplikowany związek – należy obliczyć optymalne wartości, by wczytywanie było szybkie, a jednocześnie nie zatykało komputera.
http://forums1.avsim.net/topic/281538-t ... nclusions/
http://forums1.avsim.net/topic/282292-t ... __threaded

WideViewAspect=True
Ustawienie szerszego początkowego kąta widzenia dla posiadaczy monitorów panoramicznych. Być może psuje skalowanie efektów, bo gdy stosowałem u siebie dopalacze były za duże i prześwitywały przez dysze.

[Main]
HideInfoText=(0/1)
Ukrywa wszystkie napisy informacyjne, także to dotyczące kamery.

FIBER_FRAME_TIME_FRACTION=0.33 (0.1 – 1.0)
Kontroluje czas procesora poświęcony ładowaniu scenerii.
http://forums1.avsim.net/topic/281538-t ... nclusions/

DisablePreload=1
Wyłączenie wczytywania domyślnego lotu podczas włączania symulatora i pobytu w menu, pozwala przyspieszyć wczytywanie FSa i miejsca innego niż domyślne.
http://forums.simflight.com/viewtopic.php?f=230&t=70673

PerfBucket=7 (1-7)
Kategoria, do jakiej FS przydzielił nasz sprzęt na podstawie jego szybkości, w zależności od tego domyślne będą inne ustawienia. Zmiana nie ma wpływu na wydajność.
http://blogs.msdn.com/b/ptaylor/archive ... r-not.aspx

[SCENERY]
SmallPartRejectRadius= (1-6)
Rozmiar w pikselach, jaki musi osiągnąć obiekt, by został wyświetlony. Za duże wartości mogą spowodować nagłe wyskakiwanie.
http://blogs.msdn.com/b/ptaylor/archive ... n-sp1.aspx

[Terain]
LOD_RADIUS=(0.1-12?)
Zależność poziomu detali od odległości.

SWAP_WAIT_TIMEOUT=
Ilość klatek, jaką FS będzie czekał na załadowanie tekstury.
http://forums1.avsim.net/topic/281538-t ... nclusions/

IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS= (16-2048)
W ogromnym skrócie odpowiada za szczegółowość ustawienia autogenu
http://msdn.microsoft.com/en-us/library/cc526979.aspx

TEXTURE_SIZE_EXP=10
MIN_DETAIL_TEXTURE_LEVEL=21 // Default is 15
MAX_DETAIL_TEXTURE_LEVEL=21 // Default is 21
Linie odpowiedzialne za skalowanie i poziom detali tekstur ziemi, więcej w wątku o shaderach 3.0 (co nie znaczy, ze tylko wtedy wpisy odnoszą skutek).

TERRAIN_MAX_AUTOGEN_TREES_PER_CELL= (0-6000)
TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL= (0-6000)
Regulacja ilości drzewek i domków autogenu na komórkę terenu. Domyślne wartości to odpowiednio 4500 i 1300 (niektóre źródła podają 3000).
http://orbxsystems.com/forums/index.php?topic=24895.0

[JOBSCHEDULER]
AffinityMask= (1-255)
Wybór, na których rdzeniach procesora ma działać FS.
[BufferPools]
UsePools= (0,1)
PoolSize=
RejectThreshold=
Wybór, czy FS ma używać bufora (UsePools=0 i PoolSize=0 mają takie same działanie) oraz jaki ma być jego rozmiar, a w przypadku RejectThreshold limit wielkości.
http://forums1.avsim.net/topic/281538-t ... nclusions/
http://forum.avsim.net/topic/275328-buf ... rformance/
http://forum.avsim.net/topic/280688-gra ... ion-found/

Po wejściu w ustawienia FSX i zaakceptowaniu ich, niektóre ustawienia w fsx.cfg zostaną zmienione do wartości, na jaką ustawione są suwaki interfejsu – należą do nich TEXTURE_MAX_LOAD, LOD_RADIUS= i 2 wpisy dotyczące zasięgu rysowania i gęstości chmur. By zostać przy swoich ustawieniach należy znów edytować fsx.cfg albo nie dokonywać zmian w FSX i wprowadzać je ręcznie.

Do poczytania dla zainteresowanych

Więcej o switchu 3GB: http://blogs.msdn.com/b/ptaylor/archive ... space.aspx

Jak jednym ruchem myszki zwiększyć ilość FPS:
http://www.forum.aerosoft.com/index.php?showtopic=36891
Sprawdziłem, rzeczywiście działa, w zależności od samolotu może to być wartość niezauważalna, jak i ponad 20 klatek.

Aztecowy poradnik: http://www.aztec.pl/index.php?option=co ... &Itemid=25
Poradnik zamieszczony na forum Vatsim:
http://www.forum.vatsim.pl/viewtopic.php?f=9&t=29441
Nie umniejszając zasług autorów, poradniki troszkę się już zestarzały.

Wątek na forum o optymalizacji:
viewtopic.php?t=8665
Wątek o sprzęcie do FSX:
viewtopic.php?t=5916

O wodzie bardziej technicznie:
http://blogs.msdn.com/b/ptaylor/archive ... ageIndex=2
Dlaczego tylko woda odbija obiekty:
http://blogs.msdn.com/b/sebby1234/archi ... tings.aspx

Dobre opracowanie opcji FSX i ustawień w fsx.cfg:
http://www.mycessnasim.com/tweaks/FSXTweakGuide.pdf

Poradnik z Aerosoftu, myśl przewodnia: „ustawiaj suwaki w lewo”:
http://www.forum.aerosoft.com/index.php?showtopic=30796

Poradnik dotyczący ustawień Windowsa 7 (czy autor cierpi na syndrom niespokojnego shifta?):
http://www.simforums.com/forums/topic34 ... tml#198187
I o ustawieniach samego FSX oraz nHancera (uwaga, niektóre rady wprowadzają w błąd):
http://www.simforums.com/forums/topic29041.html

Poradnik z bardzo dobrym podsumowaniem ostatnich tweaków:
http://forums1.avsim.net/topic/281538-t ... nclusions/

Nieco o sprzęcie, z czasów gdy dwurdzeniowce były rewolucją – jednak sporo rad pozostało aktualnymi:
http://usa-w.vatsim.net/prc/VPTPublic/pdfs/103i.pdf
Omówienie różnic między samolotami skompilowanymi różnymi wersjami SDK:
http://92.60.138.60/~apacz/smf/index.php?topic=10415.0

Wtyczka ENB i wątek na forum Avsim – w sieci można znaleźć setki konfiguracji efektów:
http://enbdev.com/index_en.html
http://forum.avsim.net/topic/248307-ada ... t-for-fsx/

Dlaczego symulatory działają wolniej od FPSów na przykładzie raytrackingu:
http://xplanescenery.blogspot.com/2010/ ... u-fly.html

Kilka pierwszych obrazków pochodzi z materiałów prasowych Microsoftu, jeden z instrukcji do FSUIPC, kolejny rozpowszechniany jest na licencji creative commons attribution-share alike i pochodzi z Wikipedii. Pozostałe ilustracje są mojego autorstwa.

Za rady bardzo dziękuję Michałowi „Empeckowi” Puto i Krzysztofowi „Rzemykowi” Rzemińskiemu.

[ad_verbum]

Dzięki wpisowi FIBER_FRAME_TIME_FRACTION= w fsx.cfg, można wybrać, ile czasu procesora będzie poświęcane ładowaniu scenerii. Zwiększenie domyślnej wartości 0.33 przyspieszy ładowanie tekstur kosztem ilości FPS, zmniejszenie odniesie odwrotny skutek. Wbrew wielu opiniom, to działa także w przypadku procesorów wielordzeniowych, co sam sprawdziłem.

Parametr FIBER_FRAME_TIME_FRACTION= służył do podziału czasu pracy procesora, w czasach kiedy FSX nie obsługiwał procesorów wielordzeniowych. Na pojedynczym procesorze (1 rdzeniowym) zadania, zwane "fibers" były przetwarzane w podziale czasu. Standardowo 66% czasu przypadało na obliczenia związane z generowana sceną, 33% na przetwarzanie pobieranych tekstur, autogenu i inne.

Serwis Pack 1 dodał do FSX obsługę procesorów wielordzeniowych (do 32 rdzeni). Cały proces przetwarzania danych FSX zamiplementowany w SP1 został napisany zupełnie od nowa i nie ma on nic wspólnego z wcześniejszą techniką "fiber-frame". Dodanie obsługi procesorów wielordzeniowych przeniosło ładowanie oraz przetwarzanie tekstur do niezależnych wątków przydzielanych poszczególnym rdzeniom. Analogicznie proces generowania autogenu również został przeniesiony do niezleżnego wątku i jest przydzielany dostępnym rdzeniom.

Microsoft nie podaje czy stara metoda "fiber-frame" została pozostawiona w kodzie FSXa, czy nie. Jeśli nie została usunięta, to jej stosowanie ma sens na procesorach jednordzeniowych oraz tych dwurdzeniowych, w których drugi rdzeń nie wyrabia się z procesami przygotowania tekstur i autogenu.
W pozostałych przypadkach stosowanie parametru FIBER_FRAME_TIME_FRACTION= wydaje się być pozbawione sensu. "Fiber-frame" działa tylko na jednym (pierwszym) rdzeniu i zabiera mu czas przeznaczony na obliczenia (proces obliczeniowy jest zawsze przetwarzany tylko przez jeden rdzeń).

Polecam uruchomienie menedżera zadań i sprawdzenie stopnia obciążenia poszczególnych rdzeni. W przypadku procesorów dwurdzeniowych, jeśli pierwszy rdzeń jest obciążony w 100%, a drugi w mniejszym stopniu, to stosowanie omawianego parametru mija się z celem. Przy procesorach 4 rdzeniowych jest praktycznie pewne, że pozostałe 3 rdzenie, poza 1 zajmującym się obliczeniami, będą się "nudzić".

źródło:
http://www.microsoft.com/Products/Games ... allIt.aspx
http://software.intel.com/en-us/article ... threading/

[PZL Belfegor]

służył do podziału czasu pracy procesora, w czasach kiedy FSX nie obsługiwał procesorów wielordzeniowych.

Nadal do tego służy, fibers są przywiązane do pierwszego rdzenia niezależnie od AffinityMask.

Cały proces przetwarzania danych FSX zamiplementowany w SP1 został napisany zupełnie od nowa i nie ma on nic wspólnego z wcześniejszą techniką "fiber-frame".

Nieprawda.

Jeśli nie została usunięta, to jej stosowanie ma sens na procesorach jednordzeniowych oraz tych dwurdzeniowych, w których drugi rdzeń nie wyrabia się z procesami przygotowania tekstur i autogenu.

Otóż nie, FIBER_FRAME_TIME_FRACTION= nawet przy procesorze czterordzeniowym i koligacji FSa ustawionej na trzy ostatnie rdzenie ma wpływ na działanie symulatora.

[ad_verbum]

Nadal do tego służy, fibers są przywiązane do pierwszego rdzenia niezależnie od AffinityMask.

Czyli, tak jak napisałem "Fiber-frame działa tylko na jednym (pierwszym) rdzeniu i zabiera mu czas przeznaczony na obliczenia (proces obliczeniowy jest zawsze przetwarzany tylko przez jeden rdzeń)."

Cały proces przetwarzania danych FSX zaimplementowany w SP1 został napisany zupełnie od nowa i nie ma on nic wspólnego z wcześniejszą techniką "fiber-frame".

Nieprawda.

"We are rebuilding the binaries from scratch. That's not trying to patch the old binaries, it's replacing them with new files, many of which have quite a bit of new code. The multi-core work, for instance, went through the terrain code stack from top to bottom. That's one reason why SP1 took so long. The multi-core infrastructure is solid, will use up to 256 cores if available"

źródło: SP1: How to Prepare for it and What You Get When You Install It, A Detailed Look
http://www.microsoft.com/Products/Games ... allIt.aspx

Otóż nie, FIBER_FRAME_TIME_FRACTION= nawet przy procesorze czterordzeniowym i koligacji FSa ustawionej na trzy ostatnie rdzenie ma wpływ na działanie symulatora.

Tylko, po co to robić skoro pierwszy rdzeń, ten któremu FIBER_FRAME_TIME_FRACTION= zabiera moc obliczeniową jest najczęściej w 100% obciążony, a pozostałe 3 są obciążone w nieznacznym tylko stopniu? Jak się ma te 33% (lub więcej) czasu obliczeniowego podebranego pierwszemu rdzeniowi do mocy obliczeniowej 3 pozostałych rdzeni (3x100%)? Widać to wyraźnie na wykresach obciążenia poszczególnych rdzeni.

[PZL Belfegor]

"We are rebuilding the binaries from scratch. That's not trying to patch the old binaries, it's replacing them with new files, many of which have quite a bit of new code. The multi-core work, for instance, went through the terrain code stack from top to bottom. That's one reason why SP1 took so long. The multi-core infrastructure is solid, will use up to 256 cores if available"

Nic o pozbywaniu się fibers.

Tylko, po co to robić skoro pierwszy rdzeń, ten któremu FIBER_FRAME_TIME_FRACTION= zabiera moc obliczeniową jest najczęściej w 100% obciążony, a pozostałe 3 są obciążone w nieznacznym tylko stopniu?

Po co co dokładnie robić?

[ad_verbum]

Nic o pozbywaniu się fibers.

Przecież napisałem "Microsoft nie podaje czy stara metoda "fiber-frame" została pozostawiona w kodzie FSXa, czy nie."

Po co co dokładnie robić?

Po co stosować parametr FIBER_FRAME_TIME_FRACTION , który zabiera moc obliczeniową z najbardziej obciążonego pierwszego rdzenia, jedynego który zajmuje się właściwymi obliczeniami FSX, gdy pozostałe 3 zajmujące się rdzenie są obciążone w małym stopniu?

[PZL Belfegor]

Przecież napisałem "Microsoft nie podaje czy stara metoda "fiber-frame" została pozostawiona w kodzie FSXa, czy nie."

Napisałeś >Cały proces przetwarzania danych FSX zamiplementowany w SP1 został napisany zupełnie od nowa i nie ma on nic wspólnego z wcześniejszą techniką "fiber-frame"< co jest nieprawdą i nie podpierasz tego żadnym źródłem. Zacytowałem ten fragment i do niego się odnosiłem,a nie do kolejnego o którym teraz piszesz.

Po co stosować parametr FIBER_FRAME_TIME_FRACTION , który zabiera moc obliczeniową z najbardziej obciążonego pierwszego rdzenia, jedynego który zajmuje się właściwymi obliczeniami FSX, gdy pozostałe 3 zajmujące się rdzenie są obciążone w małym stopniu?

Co rozumiesz przez "stosować"? Użytkownik nie ma żadnej możliwości włączenia bądź wyłączenia fibers, może co najwyżej zmieniać wartość parametru FIBER_FRAME_TIME_FRACTION. Jeśli usunie tę linijkę z fsx.cfg, FS będzie stosował domyślną wartość 0.33.

[ad_verbum]

Odnoszę się z szacunkiem do Twojej wiedzy, doświadczenia i pracy wykonywanej na tym forum, nie mniej jednak czuję się zmuszony do dalszej polemiki. Zarzucasz mi pisanie nieprawdy i niepodawanie źródeł. Po zakończeniu tej wymiany zdań nie będę protestował, jeśli wyczyścisz wątek - nasza polemika dla większości nie będzie zbyt interesująca - istotna będzie tylko konkluzja.

Napisałem, że cały proces przetwarzania danych zaimplementowany w SP1 został napisany od nowa. W świetle przytoczonych poniżej informacji od Microsoftu jest to prawda. SP1 zamienił jednprocesorowy/jednordzeniowy model szeregowego przetwarzania danych w podziale czasu, na przetwarzanie równoległe w podziale wątków(zadań) pomiędzy poszczególne rdzenie jednostki wielordzeniowej przetwarzające dane równolegle w tym samym czasie.
To jest, nie tylko zupełnie inny kod bibliotek binarnych, jest to także zupełnie inna architektura przetwarzania danych.

Napisałem też, że ta architektura zaimplementowana w SP1 nie ma nic wspólnego z wcześniejszą techniką "fiber-frame" - bo biblioteki kodu instalujące się z SP1, nie mają z "fiber-frame" nic wspólnego.
Nie pisałem natomiast nic na temat usunięcia "fiber-frame" z całkowitego kodu FSX, bo nie mam na ten temat żadnych informacji. Wystarczy czytać dokładnie. Już w pierwszej wypowiedzi napisałem - "Microsoft nie podaje czy stara metoda "fiber-frame" została pozostawiona w kodzie FSXa, czy nie.".

Przez stosowanie parametru "FIBER_FRAME_TIME_FRACTION" rozumiem jego zamieszczenie w pliku fsx.cfg. W wersjach z SP1 wpis ten jest domyślnie nieobecny. Czy jego wprowadzenie coś zmienia, czy też nie, tego nie wiem. Z reguły nie zwracam uwagi na opcje związane z kompatybilnością wsteczną starych rozwiązań.


I. Jak było w FSX RTM - opis techniki "fibers" przetwarzającej wszystkie wymienione powyżej zadania w trybie podziału czasu na jednym, jedynym rdzeniu procesora jednordzeniowego:

"Before multi-threading, FSX used a technique called fibers on single-core machines to handle sub-tasks (including texture processing) during available intervals, as dictated by the frame rate and rendering requirements. The level of detail generally had to be reduced by means of the slider settings because the background processes could not be allowed to interfere with the graphics rendering. For example, with a target frame rate of 33 frames per second, each frame runs for 30 milliseconds. Critical jobs, such as rendering, might require about 20 milliseconds. This leaves about 10 milliseconds before the 30 milliseconds allotted to the frame elapses. Those remaining milliseconds are all that are available for performing background processes, such as the texture loader and the composition, as well as burning all the required shadows."

źródło: http://software.intel.com/en-us/article ... threading/

II. Jak jest po modyfikacji bibliotek binarnych przez Service Pack 1- zamiast podziału czasu mamy podział wątków pomiędzy poszczególne rdzenie procesora:

1. Loading textures is one aspect of the texture composition task, but you also need to do pre-processing before you push a texture to the graphics card. Loading textures is one aspect of the texture composition task, but you also need to do pre-processing before you push a texture to the graphics card. (...)
Multiple cores make it possible to break down individual tasks and perform them concurrently. With the multi-threaded version of Flight Simulator X, those background tasks are running in the separate cores now. No matter how much time it takes to render the scene - the main task - the other cores are still processing the background and texture composition.

2. The first thread manages the game rendering and processes the artificial intelligence and physics algorithms.

3. On a system platform with more than one core, multiple terrain tessellation simultaneously executes on the second, third, and fourth cores.

4. Digital elevation model loader and texture composition tasks are encompassed in this processing as well.

źródło: http://software.intel.com/en-us/article ... threading/

III. Kilka słów na temat zakresu modyfikacji kodu FSXa wnoszonej przez SP1:
We are rebuilding the binaries from scratch. That's not trying to patch the old binaries, it's replacing them with new files, many of which have quite a bit of new code. The multi-core work, for instance, went through the terrain code stack from top to bottom.

źródło: http://www.microsoft.com/Products/Games ... allIt.aspx


Teraz czas na kilka pytań z mojej strony:
Piszesz, że FIBER_FRAME_TIME_FRACTION nadal służy do podziału czasu pracy procesora pomiędzy poszczególne zadania. Jakie to zadania są wykonywane w trybie podziału czasu, a nie w wątkach i skąd pochodzi ta informacja? Jakieś źródło?

Piszesz "użytkownik może co najwyżej zmieniać wartość parametru FIBER_FRAME_TIME_FRACTION. Jeśli usunie tę linijkę z fsx.cfg, FS będzie stosował domyślną wartość 0.33". Skąd pochodzi wiedza, że FSX z SP1 w ogóle stosuje ten parametr? Też poprosiłbym o źródło.

Piszesz też, że FIBER_FRAME_TIME_FRACTION= nawet przy procesorze czterordzeniowym i koligacji FSa ustawionej na trzy ostatnie rdzenie ma wpływ na działanie symulatora. Jaki jest to wpływ? Czym się objawia?

[PZL Belfegor]

Nie zgadzam się z Tobą na temat fibers, gdyż gdyby rzeczywiście FS już z nich nie korzystał, to wpis o nich byłby zapewne ignorowany - dowolne ustawienia parametru nie miałyby wpływu na jego działanie, a pierwszy rdzeń przy ustawieniu odpowiednim ustawieniu AffinityMask byłby całkiem wolny od FSa - jednak tak nie jest. Różnica we współpracy FSa bez SP1 i zaktualizowanego service packiem z procesorami wielordzeniowymi jest oczywista i nie sposób się z nią spierać, jednak wpis FIBER_FRAME_TIME_FRACTION nie jest reliktem przeszłości - po prostu normalnie w fsx.cfg go nie ma, a FS korzysta z domyślnej wartości (tak samo jak z np. AffinityMask czy limitem drzewek i domków autogenu). Zapoznałem się z podanymi przez Ciebie linkami, jednak nic nowego nie wniosły - powszechnie wiadomo, że obecnie pierwszy rdzeń spośród używanych przez FSa robi prawie wszystko, a kolejne głównie ładują scenerię.

Piszesz "użytkownik może co najwyżej zmieniać wartość parametru FIBER_FRAME_TIME_FRACTION. Jeśli usunie tę linijkę z fsx.cfg, FS będzie stosował domyślną wartość 0.33". Skąd pochodzi wiedza, że FSX z SP1 w ogóle stosuje ten parametr? Też poprosiłbym o źródło.

Zajmę się aktualną wersją SP2/Acceleration której używam i której dotyczy większość aktualnych poradników (choć prawdopodobnie system działa identycznie jak z SP1).
Link podany już w tym wątku: http://forums1.avsim.net/topic/281538-t ... nclusions/
Plus, jak już pisałem, sam sprawdzałem czy parametr ma wpływ na działanie FSa (w połączeniu z różnymi ustawieniami kologacji, nie tyle dla sportu co dla znalezienia optymalnych ustawień do mojej konfiguracji).

Piszesz też, że FIBER_FRAME_TIME_FRACTION= nawet przy procesorze czterordzeniowym i koligacji FSa ustawionej na trzy ostatnie rdzenie ma wpływ na działanie symulatora. Jaki jest to wpływ? Czym się objawia?

Sceneria ładuje się szybciej i mamy mniej FPS lub sceneria ładuje się wolniej, ale mamy więcej FPS. Nawet jak całkiem wolnemu od FSa rdzeniowi (prócz fibers oczywiście) damy za mało czasu, to nie zdąży on załadować scenerii i skończymy z rozmytą plamą.

[ad_verbum]

Po dogłębnym przeszukaniu zasobów sieci okazuje się, że po części Ty miałeś rację, a po części ja. Obsługa metody "fibers" nie została całkowicie wyeliminowana, pewnie ze względu na kompatybilność wsteczną z systemami jednordzeniowymi.
Natomiast tak, jak napisałem na początku stosowanie parametru FIBER_FRAME_TIME_FRACTION= "ma sens na procesorach jednordzeniowych oraz tych dwurdzeniowych, w których drugi rdzeń nie wyrabia się z procesami przygotowania tekstur i autogenu. W pozostałych przypadkach stosowanie parametru FIBER_FRAME_TIME_FRACTION= wydaje się być pozbawione sensu. "Fiber-frame" działa tylko na jednym (pierwszym) rdzeniu i zabiera mu czas przeznaczony na obliczenia (proces obliczeniowy jest zawsze przetwarzany tylko przez jeden rdzeń)."

I. Trochę historii, czyli jak było w FSX RTM - Wykonywane przez procesor zadania były podzielone na coś w rodzaju wątków zwanych "fibers". Wszystkie zadania, takie jak rendering, obliczenia fizyki, procesy AI, ładowanie i przetwarzanie tekstur, ładowanie i przetwarzanie DEM oraz pozostałe mniej istotne zadania, były wykonywane w trybie podziału czasu na jednym, jedynym rdzeniu procesora jednordzeniowego lub na pierwszym rdzeniu procesora wielordzeniowego (pozostałe nie były wykorzystywane). Do kontroli podziału czasu pomiędzy dwa najistotniejsze, ze względu na jakość i szybkość wyświetlanej grafiki, procesy wprowadzono parametr FIBER_FRAME_TIME_FRACTION pozwalający kontrolować podziału czasu pomiędzy procesami renderingu a procesami ładowania i przetwarzania tekstur.

II. Jak jest dzisiaj - Serwis Pack 1 przyniósł bardzo znaczącą modyfikację kodu FSXa, wykonywanie zadań w systemie podziału czasu zastąpiono systemem równoległego przetwarzania najistotniejszych zadań w wątkach przydzielanych poszczególnym rdzeniom procesora wielordzeniowego. SP2 i Acceleration zasadniczo nie przyniosły żadnych dalszych zmian w tym zakresie.

Pierwszy rdzeń przetwarza zadania związane z renderingiem, fizyką i AI oraz inne zadania, które nie wymagają dużej mocy obliczeniowej. Najbardziej krytyczne dla wydajności graficznej FSXa zadania polegąjace na ładowaniu i przetwarzaniu tekstur oraz modelu terenu (DEM), zostają podzielone pomiędzy wszystkie dostępne rdzenie procesora wielordzeniowego.

Trzy warianty, dla procesorów jednordzeniowych, wielordzeniowych oraz dwurdzeniowych:

W przypadku uruchamiania FSX z SP1 na procesorze jednordzeniowym wszystko pozostaje po staremu, zadania są wykonywane w podziale czasu i za jego kontrolę odpowiada parametr FIBER_FRAME_TIME_FRACTION.

W przypadku uruchamiania FSX z SP1 na procesorze wielordzeniowym (4 rdzenie fizyczne lub więcej), stosowanie (zwiększanie) wartości parametru FIBER_FRAME_TIME_FRACTION nie ma sensu. Było by to dodatkowe zabieranie mocy obliczeniowej najbardziej obciążonemu pracą pierwszemu rdzeniowi, jedynemu który zajmuje się właściwymi obliczeniami FSX, tylko po to by miał wspomagać ładowanie tekstur. Trzy pozostałe rdzenie spokojnie powinny sobie dać z tym radę. Teoretycznie można by myśleć nad zmniejszeniem domyślnej wartości FIBER_FRAME_TIME_FRACTION.

Specyficzna jest sytuacja w przypadku procesorów dwurdzeniowych, drugi rdzeń w przypadku pracy z dużą ilością tekstur może nie dawać sobie rady. Można wtedy przydzielić trochę więcej czasu pracy pierwszego rdzenia na zadania związane z ładowaniem tekstur, kosztem czasu renderingu. Celem jest osiągnięcie rozsądnego kompromisu pomiędzy ilością FPS a jakością wyświetlanej scenerii.

Na koniec kilka słów komentarza o stosowaniu parametru FIBER_FRAME_TIME_FRACTION od jednego z autorów kodu FSXa:
"On multi-core machines, there&#8217;s very little reason to tweak the fraction because it really only impacts performance of single core machines."
"Please emphasize the pointlessness of tweaking this value on multi-core machines."
Adam Szofran, Senior Software Development Engineer at Microsoft

Źródło: http://blogs.msdn.com/b/ptaylor/archive ... -week.aspx
Cytowana wypowiedź to A. Szofrana jest prawdopodobnie pierwotnym źródłem wszystkich wątków na temat FIBER_FRAME_TIME_FRACTION obecnych w sieci, także tego który mi poleciłeś http://forums1.avsim.net/topic/281538-t ... nclusions/ może warto dodać też ten pierwotny?

[ad_verbum]

Uzupełnienie do sekcji "Użyteczne tweaki"

Opisy niektórych parametrów fsx.cfg zamieszczone na blogu jednego z pracowników Microsoftu.
Warto się zapoznać z tymi materiałami, gdyż pochodzą bezpośrednio ze źródła i prezentują nieco odmienny punkt widzenia niż np. zalecenia z forum avsim.
Polecam przeczytać komentarze, jak również pamiętać, że w międzyczasie wydajność procesorów i kart graficznych znacząco wzrosła. Stosowanie niektórych parametrów straciło sens, w przypadku innych można obecnie stosować wartości większe niż było to zalecane wcześniej.

Na blogu jest opisanych więcej parametrów z fsx.cfg, jednak większość tych istotnych została już wcześniej podlinkowana przez Belfegora.

---

Informacja na temat Bufferpools i domyślnej wartości Pollsize
[BUFFERPOOLS] Poolsize=n

wartość domyślna w FSX RTM to Poolsize=1000000
wartość domyślana w FSX SP1 to Poolsize=4000000
dla kart graficznych z pamięcią nie wiekszą niż 512MB zaleca się nieprzekraczanie Poolsize=10000000

[DISPLAY] TEXTURE_BANDWIDTH_MULT=n

http://blogs.msdn.com/b/ptaylor/archive ... -or-2.aspx

---

[DISPLAY.Device.xxx.0] MipBias=6
To your fsx.cfg file reduces or eliminates the blurries especially with photo-scenery
Note: xxx is whatever your fsx.cfg shows for your graphics config.

http://blogs.msdn.com/b/ptaylor/archive ... -tips.aspx

---

[MAIN] FIBER_FRAME_TIME_FRACTION=

http://blogs.msdn.com/b/ptaylor/default ... ageIndex=6

[Kirow]

Zwróćmy tylko uwagę, że Twoje porady na tym blogu MSNowym są z 2007 roku, a wiele porad np. z AVSIMu są np. z 2010. To w końcu które tweaki sprawdzane są na tym nowszym sprzęcie?

[ad_verbum]

Ja nie podaję wytycznych do stosowania tweaków z prostej przyczyny, ich efekty są zależne od tak wielu zmiennych (ustawienia jakości i kompleksowości grafiki, ustawienia target frame rate, ilość rdzeni procesora, szybkość taktowania procesora, rodzaju GPU, rozmiaru pamięci karty graficznej, trybu DirectX, rodzaju scenerii), że jest to całkowicie pozbawione sensu. Tego nie da się uogólnić i właśnie dlatego szukam nie porad, a opisów poszczególnych parametrów po to by wiedzieć, jak je zastosować w moich konkretnych warunkach.

Znalezionymi informacjami, tymi które nie zostały wcześniej wskazane, uznałem za stosowne się podzielić - może komuś będą przydatne.

Podam przykład - znalazłem tu: http://forums1.avsim.net/topic/281538-t ... nclusions/ informację na temat [GRAPHICS] HIGHMEMFIX=1 jednak z jej opisu nie za wiele wynika:
"Fixes errors with texture addressing modes in WDDM1.0 and 1.1 when using a lot of video memory. The HIGHMEMFIX=1 you see above, fixes a bug in the FSX engine on how it handles texture addressing modes (Wrap,Clamp) and initial render states on single pass shaders, it will completely prevent textures, buildings and entire cockpits from dissapearing! this 'bug' is triggered when there is a high video memory usage situation."

Nie wiadomo co autor rozumie przez "using a lot of video memory", czy jest to 768MB, 1GB a może 1,7GB? Jest też mowa o shaderach, ale jakim trybie DX9 czy DX10? Od czasu ukazania się SP2 robi to bardzo dużą różnicę. Belfegor, może Ty znasz jakieś dodatkowe źródła informacji na temat [GRAPHICS] HIGHMEMFIX=1 ?

[PZL Belfegor]

Staram się, ale nie mogę dostrzec do może dorowadzić nasza dyskusja o fibres. Prócz tego, że udało mi się wskazać Ci, że fibres są nadal wykorzystywane, kręcimy się w kółko - najpierw podałeś linki, potem je zacytowałeś, a na koniec przetłumaczyłeś. Na pewno zaciekawi to wnikliwych zainteresowanych jak FS działa "tam w środku", ale nic nowego ani zaskakującego nie wprowadza.

Natomiast tak, jak napisałem na początku stosowanie parametru FIBER_FRAME_TIME_FRACTION= "ma sens na procesorach jednordzeniowych oraz tych dwurdzeniowych, w których drugi rdzeń nie wyrabia się z procesami przygotowania tekstur i autogenu. W pozostałych przypadkach stosowanie parametru FIBER_FRAME_TIME_FRACTION= wydaje się być pozbawione sensu. "Fiber-frame" działa tylko na jednym (pierwszym) rdzeniu i zabiera mu czas przeznaczony na obliczenia (proces obliczeniowy jest zawsze przetwarzany tylko przez jeden rdzeń)."

To Twoja opinia (do tego napisana jeszcze gdy, jak mi się zdaje, sądziłeś, że fibres można nie używać) - niewątpliwie wpływ parametru FIBER_FRAME_TIME_FRACTION= jest mniejszy niż w czasach gdy FS wykorzystywał jeden rdzeń, jednak możliwość jego zmiany nie jest całkiem zbędna - lepiej mieć pewną możliwość kontroli ile "uwagi" FS poświęci wczytywaniu scenerii, niż nie mieć tej kontroli wcale.

Na koniec kilka słów komentarza o stosowaniu parametru FIBER_FRAME_TIME_FRACTION od jednego z autorów kodu FSXa:
"On multi-core machines, there&#8217;s very little reason to tweak the fraction because it really only impacts performance of single core machines."
"Please emphasize the pointlessness of tweaking this value on multi-core machines."
Adam Szofran, Senior Software Development Engineer at Microsoft

Źródło: http://blogs.msdn.com/b/p...f-the-week.aspx
Cytowana wypowiedź to A. Szofrana jest prawdopodobnie pierwotnym źródłem wszystkich wątków na temat FIBER_FRAME_TIME_FRACTION obecnych w sieci, także tego który mi poleciłeś http://forums1.avsim.net/...p0-conclusions/ może warto dodać też ten pierwotny?

Sądzę, ze to pewien skrót myślowy mający podkreślić jak bardzo FS zmienił się po SP1. FIBER_FRAME_TIME_FRACTION= zdecydowanie stracił na znaczeniu, dlatego też jego zmiana nie wprowadza tak dramatycznych efektów jak w gołym FSie - jednak nie jest też ignorowana i ma wpływ na działanie FSa. Link mogę dodać (jeśli tylko dyskusja o fibers zostanie wydzielona), jednak nadal wydaje mi się, że krótka notatka w poradniku nie jest błędna - przy aktualizacji poradnika nie będę jej zmieniać, ale postaram się podkreślić jakie zmiany zaszły między gołym FSem a wersją z SP1.

Nie wiadomo co autor rozumie przez "using a lot of video memory", czy jest to 768MB, 1GB a może 1,7GB? Jest też mowa o shaderach, ale jakim trybie DX9 czy DX10? Od czasu ukazania się SP2 robi to bardzo dużą różnicę. Belfegor, może Ty znasz jakieś dodatkowe źródła informacji na temat [GRAPHICS] HIGHMEMFIX=1 ?

Tutaj piszą o 512: http://www.fsdeveloper.com/forum/showthread.php?t=19432 Sądzę, że największa szansę odnalezienia kolejnych szczegółów masz na forum Avsim, w postach Jezusa oraz w podforum PMDG.

[ad_verbum]

Najpierw zbierałem informacje, bo niezależnie od korzystania z praktycznych porad bardziej doświadczonych użytkowników, lubię wiedzieć w jaki sposób zalecane modyfikacje działają - tym bardziej, że każdy komputer jest inny. Mam Win7 64bitowe, sterowniki karty graficznej i DirectX też, nie wiem tylko w jakim trybie jest na tym uruchamiany DX10 i mam świadomość, że to środowisko jest trochę odmienne od tego, w którym był opracowywany i modyfikowany FSX wraz z SP1 i SP.

Po zgromadzeniu i przeanalizowaniu informacji przychodzi czas na testy. By były w miarę dokładne trzeba poświęcić na to trochę czasu. Testowałem moją konfigurację na dwóch rodzajach scenerii:
- fotosceneria bez autogenu - VFRPoland
- klasyczna sceneria z landclassem i autogenem - FTX NA Blue (demo)

Na tej podstawie mogę z czystym sumieniem podtrzymać moją wcześniejszą opinię, że stosowanie parametru FIBER_FRAME_TIME_FRACTION= "ma sens na procesorach jednordzeniowych oraz tych dwurdzeniowych, w których drugi rdzeń nie wyrabia się z procesami przygotowania tekstur i autogenu. W pozostałych przypadkach stosowanie parametru FIBER_FRAME_TIME_FRACTION= wydaje się być pozbawione sensu. "Fiber-frame" działa tylko na jednym (pierwszym) rdzeniu i zabiera mu czas przeznaczony na obliczenia (proces obliczeniowy jest zawsze przetwarzany tylko przez jeden rdzeń)."

Uzupełniając tę opinię o jedną istotną konkluzję - jeśli już zmieniać ustawienia FIBER_FRAME_TIME_FRACTION= to raczej zmniejszając je poniżej wartości standardowej, niż zwiększając. Zgodnie zresztą z moją opinią o niepotrzebnym zabieraniu mocy obliczeniowej pierwszego rdzenia. Po zakończeniu testów wyjaśnię dlaczego doszedłem do takiego wniosku.

Na koniec kilka słów komentarza o stosowaniu parametru FIBER_FRAME_TIME_FRACTION od jednego z autorów kodu FSXa:
"On multi-core machines, there&#8217;s very little reason to tweak the fraction because it really only impacts performance of single core machines."
"Please emphasize the pointlessness of tweaking this value on multi-core machines."
Adam Szofran, Senior Software Development Engineer at Microsoft

Sądzę, ze to pewien skrót myślowy mający podkreślić jak bardzo FS zmienił się po SP1.

Dlaczego nie chcesz przyjąć tego wyjaśnienia dosłownie? Autor nie jest dostatecznie wiarygodny? ;-)

[PZL Belfegor]

Odnoszę wrażenie, że założyłeś iż "stosowanie" to "zwiększanie" - tymczasem jak zauważyłeś, jego zmiana ma wpływ na działanie symulatora, i rzeczywiście, większość używających tego wpisu korzysta ze zmniejszonej wartości, preferując płynność symulatora nad szybkością wczytywania scenerii.

Dlaczego nie chcesz przyjąć tego wyjaśnienia dosłownie? Autor nie jest dostatecznie wiarygodny? ;-)

Nie przyjmuję tego dosłownie, bo bawienie się tym parametrem nie jest bezcelowe (co nie znaczy, że uważam je za konieczne), nawet w przypadku wieloprocesorowych komputerów.

[ad_verbum]

Odnoszę wrażenie, że założyłeś iż "stosowanie" to "zwiększanie" -

Jakoś tak mi wyszło po przeczytaniu różnych wątków poświęconych temu zagadnieniu.

Zastanawiam się, jakie zadania będą miały zredukowany czas obliczeniowy procesora po zmniejszeniu FIBER_FRAME_TIME_FRACTION= i jak to się odbije na działaniu FSXa. Nie lubię robić zmian "na oko", jak nie wiem na co mogą one wpłynąć.
Nigdzie nie znalazłem informacji, co z pierwotnych wątków "fibers" pozostało na pierwszym rdzeniu po przeniesieniu ładowania i przygotowywania tekstur, autogenu i DEM na pozostałe rdzenie. Trochę strach to ruszać w ciemno - można jakieś nowe wąskie gardło sobie stworzyć.

[ad_verbum]

Moja subiektywna konkluzja odnośnie wpływu parametr FIBER_FRAME_TIME_FRACTION= na ładowanie tekstur - przetestowana na dużych i szczegółowych (1m/piksel) fotosceneriach przy LOD_RADIUS=8.000000.

W kontekście wskazanych poniżej materiałów źródłowych dotyczących sposobu wykorzystania dostępnych rdzeni procesora proponował bym zaktualizowanie tego opisu:

Dzięki wpisowi FIBER_FRAME_TIME_FRACTION= w fsx.cfg, można wybrać, ile czasu procesora będzie poświęcane ładowaniu scenerii. Zwiększenie domyślnej wartości 0.33 przyspieszy ładowanie tekstur kosztem ilości FPS, zmniejszenie odniesie odwrotny skutek. Wbrew wielu opiniom, to działa także w przypadku procesorów wielordzeniowych, co sam sprawdziłem.

W obecnej postaci jest on trochę mylący - znaczenie parametru FIBER_FRAME_TIME_FRACTION= zmniejszyło się znacznie i nie ma on, moim zdaniem, widocznego i mierzalnego wpływu na procesy ładowania tekstur (w przypadku procesorów wielordzeniowych). Przetestowałem jego wpływ w zakresie ustawień od 0,1 do 2,0 nie odnotowałem żadnych pozytywnych efektów.

W swojej pierwotnej postaci FSX (wersja RTM) obsługiwał tylko jeden rdzeń, niezależnie od tego ile ich posiadał procesor. Realizowane zadania dzieliły się zasadniczo na rendering i symulację oraz ładowanie tekstur, modelu DE i autogenu. Parametr FIBER_FRAME_TIME_FRACTION= służył do zdefiniowania podziału czasu pracy procesora pomiędzy rendering a procesy ładowania.

Źródła:
Comments about the blurries from an ACES developer
http://forum.avsim.net/topic/56337-comm ... l__szofran

"The Blurries" - Allocating more CPU Time to the terrain texture loader
http://support.microsoft.com/kb/555738

Zmiany związane z w prowadzeniem SP1. Jednym z celów wydania SP1 było usprawnienie wydajności FSX poprzez przystosowanie kodu do wykorzystania wielu rdzeni procesora. Pierwszemu rdzeniowi procesora przypisano zadania związane z renderingiem, symulacją i koordynacją procesów. Zadania polegające na ładowaniu i przygotowaniu tekstur, modelu DE i obiektów autogenu zostały przeniesione na pozostałe rdzenie.
Jako, że parametr FIBER_FRAME_TIME_FRACTION= kontroluje wyłącznie zadania wykonywane na pierwszym rdzeniu, a zadania ładowania tekstur zostały przeniesione z pierwszego rdzenia na pozostałe, dotychczasowy opis tego parametru stracił swoją aktualność. Obecnie odpowiada on za podział czasu pomiędzy rendering a te pozostałości "fibers", które nie zostały przeniesione na pozostałe rdzenie. Jakie są to pozostałości i za co one odpowiadają, tego nie określa żadne znane mi źródło.

Źródło: SP1: How to Prepare for it and What You Get When You Install It - A Detailed Look
http://www.microsoft.com/Products/Games ... allIt.aspx

PS. Wg opisów z forum AVSIMu parametr FIBER_FRAME_TIME_FRACTION= może przyjmować wartości większe niż 1. Wartość 1 oznacza że stosunek podziału czasu pomiędzy rendering a ładowanie tekstur jest, jak 1:1. Wartość 2 przydzieli dwukrotnie więcej czasu na ładowanie niż na rendnering. Takie ustawienia były kiedyś zalecane do pracy z TileProxy.

[ad_verbum]

Słowo komentarza i ostrzeżenie na temat możliwego działania "tweaka" HIGHMEMFIX=1. Może to mój indywidualny przypadek, ale zwracam uwagę, że Bojote przestrzega przed działaniem tego wpisu w systemach Vista i Win7. Szkoda, że to ostrzeżenie nie jest zamieszczane na forach w miejscach, gdzie ten "tweak" jest wskazywany.

Wpis HIGHMEMFIX=1 spowodował u mnie dokuczliwe i wyraźnie widoczne pogorszenie jakości wyświetlanego obrazu. Jest to widoczne w VC oraz najbardziej w widoku zewnętrznym. Objawia się to jak gdyby spowolnionym i szarpanym przerysowywaniem się obrazu, zwłaszcza w jego centralnej części. Efekt "szarpana" jest taki, jak bym zamienił kartę graficzną na taka sprzed 10 lat.
Usunięcie wpisu niestety nie przywróciło programu do wcześniejszego poarawnego trybu pracy. W czasie testowania HIGHMEMFIX=1 nie zmieniałem żadnych innych parametrów, a fatalny efekt był widoczny od razu po pierwszym uruchomieniu FSX'a po dodaniu tego wpisu.

Autorem tego "tweaka" jest Jesus Altuve aka "Bojote". Tweak został opisany następująco:
"[GRAPHICS] HIGHMEMFIX=1 Fixes errors with texture addressing modes in WDDM1.0 and 1.1 when using a lot of video memory. The HIGHMEMFIX=1 you see above, fixes a bug in the FSX engine on how it handles texture addressing modes (Wrap,Clamp) and initial render states on single pass shaders, it will completely prevent textures, buildings and entire cockpits from dissapearing! this 'bug' is triggered when there is a high video memory usage situation. so, enjoy this is my way of giving to a community that has given me so much over the years. "

Nieco później autor skomentował jego działanie tak:
"I don't think HIGHMEMFIX improves performance AT ALL... nothing, nada... its simply a FIX! (not a performance tweak) it simply enables the LARGEADDRESSAWARE for the DX9 D3DEffects system which (for implementation reasons) was NOT enabled by default when FSX shipped. It made things worse with WDDM because of how memory is managed in Vista and Win7."
http://forum.avsim.net/to...th-highmem-fix/

Zwróciłem się z prośba do autora o precyzyjniejsze wyjaśnienie, co ten "tweak" faktycznie robi i skąd pochodzi informacja o jego działaniu - odpowiedzi nie otrzymałem.

[st1322]

Z tym HighMemFix cos jest na rzeczy. Ja wlasnie to wywalilem i ilosc klatek podskoczyla. Wynikalo ze obcinal za duzo, zwlaszcza w terenie zabudowanym.

[mbucholski]

U mnie po wyrzuceniu zmniejszyła się liczba przycięć, szczególnie już w powietrzu.

[ad_verbum]

Moim zdaniem warto jeszcze, po usunięciu tego wpisu, przeinstalować sterownik WDDM. W przypadku kart GeForce należy zainstalować nowy (lub ten sam) sterownik Nvidia wybierając instalację niestandardową i później pełną reinstalację wraz z usunięciem zapisanych ustawień.

[ToTom]

Po przesiadce na FSX w zasadzie wszystko już sobie poustawiałem. Spokoju nie daje mi jedna rzecz. Autogen.
Otóż wyskakuje on jak królik z kapelusza i to w niewielkiej odległości od samolotu. Poszukiwania w sieci naprowadziły mnie na tezę, że FSX tak ma i już, a wszystko w imię poprawy wydajności.
Zrobiłem poszukiwania na znanym portalu z filmami. I faktycznie, coś jest na rzeczy, bo od razu trafiłem na identyczne jak u mnie objawy:
1. Od początku: http://www.youtube.com/watch?v=JbLbjt9R ... re=related
2. Od 7:50 http://www.youtube.com/watch?v=Hxnru30X ... re=related

Trzeba to pokochać, czy da się z tym coś zrobić? Na wydajność FSX (SP2) nie narzekam (I2500K/ATI5770), ale autogen, bez względu na ustawienia (min/maks) zawsze tak się zachowuje.

[PZL Belfegor]

W aktualnej wersji FSX autogen nie pojawia się płynnie jak w FS9, nie ma alpha fade. Striking Software pokazał filmiki na których uzyskał zbliżany efekt (tu jeden z nich), ale modyfikacji nie wydał.

[ToTom]

W aktualnej wersji FSX autogen nie pojawia się płynnie jak w FS9, nie ma alpha fade. Striking Software pokazał filmiki na których uzyskał zbliżany efekt (tu jeden z nich), ale modyfikacji nie wydał.

alpha fade - słowo klucz... To sformułowanie pojawiało się w wątkach o tym problemie i ucinało dyskusje... Czyli nie ma rady i trzeba to pokochać
PS. Jakby to było tak, jak na filmie (nawet kosztem kilku fps) to byłoby super!

[ad_verbum]

Ważne - wszystkim modyfikującym w fsx.cfg parametr TEXTURE_BANDWIDTH_MULTIPLIER, dla których cały materiał wydaje się być przydługi i nazbyt teoretyczny sugeruję zapoznać się z fragmentem zaznaczonym jako istotna uwaga.

Poniższy materiał prezentuje omówienie parametrów TEXTURE_MAX_LOAD, TEXTURE_BANDWIDTH_MULTIPLIER i TextureMaxLoad oraz formuły MAX TEXTURE DATA (MTD) oraz związków występujących między nimi. Parametry te dotyczą jedynie tekstur dla obiektów 3D takich, jak obiekty scenerii lotniskowych, budynki i drzewa autogenu, model zewnętrzny samolotu, VC oraz chmury. Co istotne, parametry te nie mają wpływu na sposób przetwarzania tekstur terenu, zarówno w przypadku fotoscenerii, jak i scenerii typu Landclass.

Formuła MAX TEXTURE DATA (MTD) wyznacza maksymalny poziom ilości danych o teksturach jaka będzie pobierana przez FSX do obliczeń w jednostce czasu (1 klatka) i w przypadku, gdy jest ustawiony wewnętrzny limit FPS, jest obliczana wg wzoru:
MAX TEXTURE DATA= TEXTURE_MAX_LOAD^2 (czyli rozmiar pliku w bajtach) * TextureMaxLoad * (TEXTURE_BANDWIDTH_MULTIPLIER / UPPER_FRAMERATE_LIMIT)

lub jeśli nie ma ustawionego wewnętrznego limitu FPS:
MAX TEXTURE DATA= TEXTURE_MAX_LOAD^2 (czyli rozmiar pliku w bajtach) * TextureMaxLoad

Przy czym poszczególne parametry są definiowane następująco:
1. TEXTURE_MAX_LOAD = 1024 (wartości z przedziału 256 do 4096)
To inaczej parametr global texture resolution, wartość 1024 odpowiada ustawieniom "very high" z poziomu programu, Można podwyższyć do 2048 lub 4096, ale to oznacza wzrost ilości danych odpowiednio 4x i 16x. Ważne - dla celów obliczeniowych formuły MTD wartość ta ma być wyrażona w bajtach odpowiadająca wielkości pliku z teksturą (1024 x 1024 = 1MB)

2. TextureMaxLoad = 12 (3 to wartość domyślna)
To maksymalna ilość tekstur jaką będzie texture manager pobierał na każdą przetwarzaną klatkę. W przypadku gdy do pobrania jest ich więcej, pobieranie następnych zostanie rozpoczęte dopiero wraz z rozpoczęciem obliczania następnej klatki.

3. TEXTURE_BANDWIDTH_MULTIPLIER = 40
To mnożnik przez który jest przemnażana wartość TextureMaxLoad, jego wartość powinna być nieco wyższa niż UPPER_FRAMERATE_LIMIT .

4. UPPER_FRAMERATE_LIMIT =36
Wewnętrzny limit FPS. Jeśli jest ustawiony, to wartość ta stanowi dzielnik dla wartości TEXTURE_BANDWIDTH_MULTIPLIER

Dla przedstawionych, przykładowych wartości transfer maksymalny MTD wynosi 480MB/s ((1024 x 1024 * 12 * 40/36) * 36 klatek by uzyskać wynik na sekundę) i dotyczy wymiany danych pomiędzy pamięcią systemową, CPU i GPU. Przy rozmiarze tekstur 4096x4096 i reszcie parametrów nie zmienionych transfer maksymalny wynosiłby 7680 MB/s i niebezpiecznie zbliża się do maksymalnej wydolności magistrali PCIe x16, która wynosi 8GB/s. Uwaga: w większość przykładów w sieci wyliczenie to jest błędnie przedstawiane jako (1024 *12*40) i jest wartością bezsensowną - rozmiar pliku z teksturą jest definiowany przez dwa wymiary, a nie jeden, a standardowy plik z teksturą o rozdzielczości 1024px na 1024px nie ma rozmiaru 1kB tylko ma 1MB.

Istotna uwaga dla wszystkich stosujących parametr TEXTURE_BANDWIDTH_MULTIPLIER. Jak wynika z opisu przedstawionego przez Steve Lacey'a (FSX software developer - patrz literatura) w przypadku korzystania z zewnętrznego limitera i nieustawienia limitu klatek wewnętrznie w FSX wartość TEXTURE_BANDWIDTH_MULTIPLIER nie jest brana pod uwagę: cyt. "This value is multiplied by the TEXTURE_BANDWIDTH_MULT configuration variable and divided by the target framerate only in the case where you have a target framerate set. With 'unlimited', the variable will have no effect."
Formuła MTD jest w takim przypadku obliczana wg wzoru MAX TEXTURE DATA = TEXTURE_MAX_LOAD^2 (w bajtach) * TextureMaxLoad i jak widać ilość maksymalnie pobieranych tekstur zależy od wartości parametru TextureMaxLoad i to właśnie ten parametr należałoby podwyższać chcąc zwiększyć limit ilości pobieranych tekstur.

Wracając do maksymalnego poziomu ilości danych wyznaczanego przez formułę MTD warto pomyśleć, że ustawianie abstrakcyjnie wysokich wartości dla powyższych parametrów, jak np. TEXTURE_BANDWIDTH_MULTIPLIER = 400 to głupota. Dane o teksturach stanową tylko część danych przesyłanych po magistrali PCIe i przy ustawieniach typu (4096^2 x 3 x 400 czyli 19200 MB/s) można doprowadzić do zupełnego zatkania PCIe. Po drugie, FSX raczej nie dostarczy takiej ilości danych, bo chyba nikt nie buduje takich scenerii. Moim zdaniem, nie ma co przesadzać z tymi parametrami ponieważ w praktyce "podaż" tekstur jest zależna od tego, co zrobił projektant scenerii, a dobrze zaprojektowane scenerie uwzględniają realne możliwości komputerów. Ustawienia należy dostosować do rozdzielczości stosowanych tekstur oraz do realnych możliwości posiadanego komputera. Stosowanie tekstur HD (2048 czy 4096) powinno iść w parze z rozsądnym dobraniem szybkości ich pobierania tak, by nie zatkać magistrali PCIe.

Powyższy materiał powstał jako próba usystematyzowania zagadnienia MAX TEXTURE DATA i opisuje stronę teoretyczną zagadnienia w oparciu o istniejący, niestety bardzo ograniczony materiał źródłowy. Jest możliwe, że pewne ustalenia mogą odbiegać od stanu rzeczywistego. Jeśli ktoś dysponuje wiedzą pogłębiającą zagadnienie lub ma uwagi to zapraszam do komentowania.

Literatura:
http://www.steve-lacey.com/2005/11/the_stutters (jedyne oryginalne źródło informacji na temat formuły MTD)
http://forum.avsim.net/index.php?showtopic=281312 (zawiera błędny opis formuły MTD w kontekście rozmiaru pliku w bajtach)
http://blogs.msdn.com/b/ptaylor/archive ... -or-2.aspx

[Mad Max]

Witam wszystkich!
Do niedawna do FSXa (w wersji Deluxe) używałem komputera stacjonarnego, w konfiguracji:
- Procesor: Intel (R) Core (TM) 2 Duo CPU E6550@2.33GHz
- 2 GB RAM
- Karta graficzna: NVIDIA GeForce 8600 GTS (256 MB)
- System operacyjny: Windows XP

W chwili obecnej, jako że większość czasu spędzam przy laptopie Dell Inspiron M501R, w konfiguracji:
- Procesor: AMD Phenom II N850 Triple-Core 2.20GHz
- 6 GB RAM
- Karta graficzna: ATI Mobility Radeon HD550v (1 GB)
- System operacyjny: Windows 7 (64 bit)

wydawało mi się rozsądne, że najlepiej będzie przenieść FSXa i wszystkie dodatki na laptopa, który znacząco przewyższa parametrami stacjonarkę, i cieszyć się większą płynnością. Otóż nie. Fakt faktem, nigdy zbytnio nie zagłębiałem się w konfigurację i tweakowanie FSXa, wystarczało mi operowanie suwakami ustawień, jednak używając tych samych ustawień na komputerze stacjonarnym, uzyskiwałem płynny obraz i 35-40 FPS, osiągając przy tym zadowalający mnie poziom detali (przyjemny dla oka), natomiast na nowszym o cztery lata laptopie, posiadającym mocniejsze podzespoły, obraz tnie się klatka po klatce, i osiągam 10 FPS!!! Uniemożliwia mi to jakiekolwiek funkcjonowanie w świecie wirtualnego latania.

Mam więc pytanie - w kwestiach technicznych jestem laikiem, czy zależy to od systemu operacyjnego? Co muszę zrobić, by w pełni wykorzystać potencjał mojego laptopa?

[Kirow]

Jakbyś uważnie przeczytał ten wątek, dowiedzialbys się że twój laptop mimo lepszych innych bebechów ma wolniejsze traktowanie procesora i to może być powód.

[Tomek1158]

No bez przesady. 3 rdzeniowy 2.20GHZ zamiast dwurdzeniowego 2.33GHZ nie powinien spowodować spadku o 30fps... Problem musi leżeć gdzieś indziej.

Jesteś pewny, że nie masz włączonego lightbloom'a, DirectX 10 preview lub ustawionego limitu klatek na np. 15? (Co się często ustawia automatycznie po zainstalowaniu FSX)

[ad_verbum]

czy zależy to od systemu operacyjnego? Co muszę zrobić, by w pełni wykorzystać potencjał mojego laptopa?

Z definicji wszystkie ustawienia w laptopie są podporządkowane oszczędzaniu energii. Procesory mobilne szybciej przechodzą w tryb obniżonego taktowania i są to niższe szybkości niż w procesorach desktop.

Ściągnij sobie program CPU-Z i poobserwuj prędkość taktowania procesora w trakcie latania w FSX. Potem zajrzyj do ustawień zarządzania energią w panelu sterowania Win7 i ustaw tryb maksymalnej wydajności. Ponownie sprawdź w CPU-Z z jaką szybkością pracuje (pod FSXem) procesor. Można by też spróbować zmienić ustawienia zarządzania energią dostępne z poziomu BIOSu, ale obawiam się, że mogą być one zablokowanie/nieudostępnione. To się często spotyka w komputerach przenośnych - taki przejaw troski producenta by komputer zbyt szybko nie wysysał baterii.

PS. Procesory Phenom II niespecjalnie sprawdzają się w przypadku FSXa, tu dochodzi jeszcze problem polegający na tym, że wersje mobilne procesorów Phenom II zostały okrojone, całkowicie pozbawiono je pamięci cache trzeciego poziomu. Zamiast 6 MB, bo tyle mają desktopy, jest 0 MB, co niestety negatywnie odbija się na wydajności.

No bez przesady. 3 rdzeniowy 2.20GHZ zamiast dwurdzeniowego 2.33GHZ nie powinien spowodować spadku o 30fps...

Pod warunkiem, że procesor nie pracuje przez sporą część czasu z taktowaniem na poziomie np. 0,8 GHz. Agresywne zarządzanie energią potrafi czynić takie cuda.

Problem musi leżeć gdzieś indziej.

Założyłem, że Mateusz odrobił swoją część pracy i sprawdził ustawienia FSXa na zgodność z tymi z komputera stacjonarnego.

[robs85]

Witam podepnę się pod temat..
Ciekawy jestem jak u Was na laptopie wygląda fsx.. Ja u siebie zauważyłem że obraz pozostawia dużo do życzenia.. scenerie na pewno nie są w pełni wykożystane graficznie.. Na pasach muszę się mocno skupiać aby zobaczyć drogi kołowania (numery).. W kokpicie np C172 od A2A muszę mocno zoom'ować aby np zobaczyć co jest na GPS lub na zegarach radia.. wszystko jest mocno pikselowe.. Nie wiem jaką kartę używa FSX podczas gry.. W ustawieniach mam Nvidie.. Wydawało mi się że przy dość mocnym lapku będzie to lepiej wyglądać niż na starym laptopie ze zintergowaną kartą.. Macie może jakieś pomysły co mogę zrobić aby poprawić jakość obrazu? Ustawienia graficzne w FSX mam na maxa.. Opcje DX10 wyłączoną, scenerie lotnisk od Drzewieckiego, cesna 172 A2A. Na lotnisku/scenerii EPWA klatki mocno spadają do 7 ale to inny temat.. najbardziej drażnią mnie te pikselowe widoki w kokpicie i za oknem.. przez co wszystko jest mało czytelne..
Specyfikacja komputera:
Laptop ASUS K555LD-XO291H
Procesor Intel Core i7-4510U (2 rdzenie, od 2.00 GHz do 3.10 GHz, 4 MB cache) Chipset Intel HM86
Pamięć RAM 12 GB (SO-DIMM DDR3, 1600 MHz)
Dysk twardy 1000 GB SATA 5400 obr.
Karta graficzna NVIDIA GeForce 820M+ Intel HD Graphics 4400
Wielkość pamięci karty graficznej 2048 MB GDDR3 (pamięć własna)
FSX: FSX SE
Windows 8.1
Czy w ogóle na takim kompie może to fajnie wyglądac zachowując przy tym rozsądna ilość klatek?