Jelen írás célja, hogy egy kicsit élvezhetőbbé tegyük az Microsoft Flight Simulator X futását.

Elöljáróban pár alapszabályt tisztázunk.

1. Ez nem egzakt tudomány. Rengeteg változóból kell kialakítanunk egy olyan rendszert, ami nekünk leginkább megfelel. Mindenkinek vannak egyéni preferenciái, amiről nem akar, vagy szeretne lemondani. Ezek viszont tovább árnyalják a lehetőségeket, lehetséges megoldásokat.

2. Nincs két egyforma FSX install, és futási környezet! Valahol találtam egyszer egy tesztet a neten, amit sajnos azóta sem sikerült előkeresni, miszerint két azonos számítógépre telepítették az FSX-et, és más teljesítménnyel futott azonos beállítások, és driverek mellett. Így fordulhat elő hogy lesznek beállítások amik működnek, és lesznek amik nem.

Az itt leírtak elsősorban javaslatok, hogy merre érdemes keresgélni.

3. Az FSX egy nagyon erőforrás igényes program! NAGYON! A GPU teljesítménye sok esetben másod, harmadlagos a többihez képest (kivétel a több monitoros megjelenítés). A legfontosabb a CPU teljesítménye és a magok száma. Ez után pedig a memória mérete, és sebessége. Fizetős addonok (Aerosoft Budapest 2.0, PMDG 737) esetén 4 gyors mag, és 4 GB memória az ami a megfelelő látvány/teljesítmény eléréséhez kell.

4. Az FSX SP1 + SP2, vagy az Acceleration pack telepítése nélkül ne is álmodjon senki megfelelő teljesítményről, ugyanis ezek alapvető javításokat tartalmaznak, mind a több magon történő futtatáshoz, mind pedig a grafikai motort tekintve. (AZ Acceleration önmagában tartalmazza a frissítéseket.)

5. Tapasztalat azt mutatja, hogy Win7 64 alatt jobban teljesít az FSX

6. Az FSX elsősorban nem játék, hanem egy szimulátor! Itt nem egy adott pályán belül mozgunk, egy előre scriptelt környezetben. Itt rengeteg változó kiszámításából, és újra és újra kiszámításából épül fel a program.

Akinek már itt sok a rizsa és instant megoldást keres, az tekerjen a végére ott lesz pár dolog amit érdemes beírni próbálja meg, és ha nem megy (nem működik) akkor olvasson tovább.

Környezet, amiben szeretnénk futtatni a programot

Fontos, hogy számítógépünk stabilan fusson. A memóriák időzítése megfelelő legyen. Az FSX telepítése előtt érdemes az esetleges overclock-ot lekapcsolni. Lehetőleg minden a gyári beállítások szerint menjen.

Stabilitás, stabilitás, stabilitás! Ha a rendszerünket nem megfelelően lőttük be (driverek, beállítások, melegedés, stb) akkor az FSX azon biztosan meg fog hasalni. Lehet hogy más programoknál stabilnak tűnő gépünkről ki fog derülni, hogy nem is annyira stabil.

Aki nem teljesen mozog otthon abban hogy hogyan kell a rendszerrel elinduló szolgáltatásokat "processeket" kezelni, lekapcsolni, vagy kényelmes megoldást keres a hétköznapi használat mellett annak ajánlom a Game Booster használatát. Jelentősen tudja csökkenteni a teljesítmény ingadozást, és futás végeztével vissza állítja azokat a szolgáltatásokat, amik az esetleges hétköznapi felhasználáshoz egyébként kellenek. ( pl.: nyomtatók, okostelefonok vezérlő programjai, amik csak ott ülnek és foglalják a memóriát, és egy kis proci időt, aztán néha "bejelentkeznek" egy kicsit, konstatálják hogy semmi dolguk, majd nagy duzzogva megint meghúzzák magukat, mi meg közben leszállás közbeni kilebegtetéskor bele laggoltunk a betonba.)

Fontos hogy minél tisztább legyen a rendszer. Az FSX minden egyes órajel ciklust meg fog zabálni amit adunk neki. Ha nem tudjuk megszelídíteni a rendszerünket, akkor segíthet hogy a core0-ról, amit a legtöbb alkalmazás használ, letiltjuk az FSX-et és csak a többi magon engedjük futni. Erről a [JOBSCHEDULER] pont alatt lesz részletesebben szó.

FSX telepítése

A telepítésnél Win7 alatt nem ajánlott az alapértelmezett \programfiles(x86)\ mappába telepítés, mert a rendszer védi, nem engedi változtatni, stb. UAC-ot ki kell kapcsolni!

Törekedjünk arra, hogy az FSX saját FIZIKAI meghajtón legyen. Nem szerencsés ha egy meghajtón van a rendszerrel, vagy esetleges virtuális memóriával. A program folyamatosan hatalmas mennyiségű adatot olvas. Itt nem töltődik be a "pálya" indításkor, mert esetünkben ez az egész Földet jelenti. Indításkor csak a repülőgép bizonyos nagyságú környezete töltődik be a memóriába, a többi repülés közben, igény szerint. Az SSD meghajtó ezen a ponton jelent előnyt, ugyanis a töltési időkből adódó "stutter" vagy más néven mikro-lagg jelenséget nagy mértékben csökkenti, "kisimítja" a futást abban az esetben ha ez a szűk keresztmetszet.

Újra telepítésnél figyeljünk a módszeres, és mindenre kiterjedő eltávolításra. Úgy kell elvégezni, mintha hagymát pucolnánk. Először a sima az addonok, sceneryk, repülőgépek, aztán kiegészítők, végül maga az FSX, melyet a telepítő programmal kell leszedni, ezután keressük meg a megmaradt könyvtárakat, és töröljük azokat. Ezután reboot, majd registry takarítása egy erre alkalmas programmal, reboot, és megint takarítás. Ha mindent jól csináltunk, akkor is előfordul, hogy a service pack nem települ rendesen, vagy végzetes hibát észlelve kilép. Ennek az oka, hogy registry-ben benne maradt valami, ami mélyebb matatást igényel.

Lépések:

1. FSX telepítése, aktiválás, load default flight, kilépés, számítógép újra indítása.

2. SP1, load default, reboot, majd SP2, VAGY(!) Acceleration pack telepítése, regisztrálás, load default flight, kilépés, számítógép újra indítása.

3. Töredezettség mentesítés a meghajtón.

4. Minden addon-t külön-külön telepítünk, telepítés után load default flight (ez azért kell hogy újra tudja építeni a program a scanery library-t) majd gép újra indítása.

Használatba vétel

Fontos hogy milyen a gépünk, amin az FSX-et futtatni szeretnénk. Két magos öregebb rendszerek esetén le kell mondanunk egészen biztosan a trafic beállításokról, ugyanis nincs hozzá elegendő erőforrásunk. Az FSX Intel procira lett optimalizálva. Az AMD itt jelentős hátrányban van. A fejlesztés során az Intel mérnökeivel dolgoztak együtt a fejlesztők, velük dolgozták ki a több szálon történő futtatás megoldását. Az FSX motorjának egyes részei (renderelés, autogen, 3D váz számolása) más magokon futnak. Egy magos rendszeren nincs használható FSX!

Az I7 tulajok bejegyzései alapján, (mievel ezt nem volt alkalmam tesztelni) az a jobb, ha le van tiltva a BIOS-ban Multi-Threading, és csak a fizikai magok futnak. Ennek oka, hogy az FSX motorja a fizikai gyorsító tárat használja. Mivel a virtuális magnak ilyen nincs, így nem tud rajta futni, ami ugyancsak gubancokhoz vezet, mert ebben az esetben a virtuális szálakat "parked" állásba rakja a rendszer, ami azt eredményezi, hogy elveszik a proci effektív teljesítményének 50%-a, már ami az FSX szempontjából számít. Ez akkor is így van sok esetben, ha látszólag a mag működik.

Mivel a fejlesztés során a lehető legnagyobb kompatibilitást akarták elérni, ezért rengeteg "öreg" kód, és vezérlő utasítás van a motorban, ami a mai gépeken, csúcshardvereken már hátrány. Ez az oka annak, hogy elsősorban nem videó kártyán múlik, hogy hány FPS-t tudunk produkálni. Mindez az egy megjelenítős módig igaz, több monitor használata esetén további gondokkal találjuk szembe magunkat.

Az ATI kártya tulajdonosoknak rossz hír, hogy az FSX nem nagyon ATI barát. A grafikus motor felépítése jobban kedvez az nVidia kártyák felépítésének, miszerint a nVidia nagy, nyers erővel operáló adatfeldolgozást végez a GPU-n belül, míg az ATI inkább minél több szálra bontja a grafikus feldolgozást.

Az ATI meg valamiért nem akart foglalkozni azzal az utóbbi hónapokig, hogy driver szinten megoldja a problémát. Az ATI kártyák a felhők kezelésénél hasaltak el a közel múltig, ugyanis az Anti Aliassing kódolásába valami bug került. (hogy FS, vagy ATI oldalon azt nem tudni) Így, ha emelted az AA beállításokat felhős időben, pillanatok alatt 10 közelébe zuhant az FPS. Hosszas kutakodás után talált rá egy úriember megoldást, mégpedig a shader modell lecserélését. Az FSX DirectX 9. alatt shader modell 2.0-t használ alapból, viszont erre az ATI kártyák nincsennek optimalizálva. A Shader modell 3 telepítése ezt a gondot megoldhatja, viszont számos más gondot is hozhat, de erről később. A MOD innen tölthető le. Másik megoldás DX10 futtatás lehet, de ez megint rengeteg buktatót hordoz magában.

FIGYELEM: a shader 3.0 nem kompatibilis a REX-el. Aki REX-et használ ne telepítse.

Update: 7xxx -től felfele, 13.1 catalystól teljesen megoldódni látszik az ATI kártyák problémája.

Az FSX tweak egyik fontos értelmezése, hogy folyamatosan egyensúlyozunk a teljesítmény és a stabilitás között. Az instabil működés jelei: ugráló textúrák, "stutter" jelenség ami a táj renderelésének ingadozása, lagg, fények számolásának hibája, fekete négyszögek a textúrák helyén, égig érő textúrák, és számtalan más dolog. Amit egy számítógép produkálhat, azt FSX alatt produkálni is fogja.

Fontos, hogy egy nem teljesen stabil gép esetében ne próbálkozzunk a tweak-ekkel, mert nem fog kielégítő eredményt hozni. Tessék tesztelni a gépet. Memória időzítés hibák, melegedés, elégtelen tápegység mind vissza fog ütni, mert FSX alatt a CPU közel folyamatosan 100% körül fog mozogni, ha föld közelben vagyunk. Fent a magasban nem kell autogent, meg részletes domborzatot számolni, így ott nem lesznek nagy gondjaink, csak 100+ FPS. (jó esetben...)

SLI/xFire

Az FSX nem támogatja a több videó kártyás/ GPU-s működést. Az eddigi tesztek azt mutatják, hogy még rosszabbul teljesít, mint egy GPU-val. Ennek oka szintén a régi motorban keresendő. Mivel ilyen környezetben nem teszteltem, így csak a neten fellelhető írásokra tudok alapozni. Egy megoldással találkoztam, miszerint egy olyan programra készítenek profilt az xFire menüben, ami támogatja ezt az üzemmódot, majd manuálisan kicserélik az exe file-t (pl: farcry.exe a profilba át lesz írva fsx.exe-re) ekkor állítólag működésre lehet bírni xFire üzemmódban.

Az első futtatás alkalmával érdemes windowed módban ellenőrizni, hogy minden CPU magot használ-e a program. Ha csak egy magon fut, akkor valószínűleg nem sikerült az Acceleration/SP1+SP2 telepítése. Ebben az esetben reinstall, lehetőleg nulláról, mert ha nem megfelelően távolítjuk el, akkor sok idő feláldozásával csak újra generáljuk a problémát.

Több megjelenítős üzem.

FIGYELEM! A több megjelenítős üzem mindig újabb problémákat hoz elő. Az első teszteket, beállításokat egy monitoron végezzük, úgy hogy a többi kijelző nincsen csatlakoztatva. A csatlakoztatott kijelzőnek a kártya már címez erőforrást, ami váratlan teljesítmény ingadozásokat okozhat.

Több megoldás is kínálkozik több monitoron való játékra. Az első, és mindenki számára elérhető változat az:

Extended desktop használata. Ebben az esetben windowed módba (alt+enter) kapcsolunk, megnyitunk egy nézetet, jobb klick, undock window, és mint külön ablakot, áthúzzuk a másik monitorra. Amennyiben ez nem csak 2D egy műszerfal ablak, hanem mondjuk külső nézet, vagy másik nézőpont, ami 3D-ben van renderelve, akkor meg is felezzük az FPS-t, mert egy teljesen új render szálat nyitunk vele, tehát ugyan azt a dolgot kétszer számoltatjuk a CPU-val. És ez a fontos! Hogy mindig CPU-ból dolgozik az FSX. Három 3D (külső nézet, virtual cockpit) ablak esetén már harmadoljuk az erőforrásokat.

A következő megoldás az ATI eyefinty, illetve a Matrox 3HeadToGo. Ebben az esetben 2-3 vagy Eyefinty üzemmódban több, akár 6 kijelzőt egy nagy monitornak lát a rendszer, így az FSX-is. Így egy render szálon tudunk több kijelzőt meghajtani. Ez az üzemmód, ahol elkezd számítani a videó kártya, mert itt már a nagy pixel szám miatt meg is kell tudni jeleníteni a dolgokat. Ebbe a kategóriába proci oldalon a natív 4 magos CPU a belépő, de nem sértő a több mag, és natúr teljesítmény.

Az nVidia sourround megoldás jöhet még szóba, mely két videó kártya meglétét feltételezi, megfelelően beállítva, ami hasonló megoldást kínál mint az ATI, illetve 3H2Go. Mivel ezzel semmilyen tapasztalatom nincs, nem tudok nyilatkozni róla.

Ezennel elérkeztünk oda, ami jelenlegi írásunk fő témája, a Tweak kérdéséhez.

Mivel az FSX régebbi kódokra íródott, így rá kell bírnunk, hogy jobban muzsikáljon a mai hardvereken. (nem mintha a régieken tudott volna muzsikálni, inkább csak nyekergett, mint első éves zeneiskolás a hegedű vizsgán)

Az FSX minden főbb program beállítását egy .cfg file-ban tárolja. Ez egy egyszerű txt, amit könnyen szerkeszthetünk. A file helye: C:\Users\ (userneve) \AppData\Roaming\Microsoft\FSX\

Mielőtt nekiesnénk, csináljunk belőle biztonsági másolatot. Ha nincs, és nagyon össze kavartuk a dolgokat, akkor sincs baj, mert egyszerűen kitöröljük, és a következő futtatásnál újra generálja a program a gyári alap beállításokkal.

FONTOS! Az FSX tweak-nek nincs "szent Grál-ja" ami egycsapásra megoldja problémáinkat. Minél jobban belemászunk, annál több változót figyelve kell eljárnunk.

FONTOS! Nem minden itt tárgyalt beállítás van benne a cfg-ben alapértelmezetten. Több dolgot nekünk kell beírni! Itt csak azokat a részeket tárgyaljuk, amik a teljesítmény szempontjából fontosak.

Mielőtt azonban bármit állítanánk, nézzük meg, hogyan használja rendszerünket az FSX! Csak akkor tudunk eredményt elérni, ha tudjuk, mi a szűk keresztmetszet a rendszerünkben, ami lerántja a teljesítményt. Ez egy igazi "Ki a leggyengébb láncszem" játék több fordulóval, és keserű tanulságokkal. Sok esetben olyan a rendszerünkbe fellelhető anomáliákra jöhetünk rá, aminek megoldása meghaladja tudásunkat.

Mindennek az alapja a folyamatos rendszer monitorozás.

Töltsük le (ha nincs eleve meg) a GPU-Z programot, amivel nagyon jól tudjuk monitorozni a videó kártya kihasználtságát.

Nyissuk meg a windows feladat kezelőt, és a teljesítmény fülre kattintva nézzük a CPU kihasználtságát.

A beállítások kipróbálása folyamán ezeket folyamatosan ellenőrizzük, így rá tudunk jönni, hogy hol szorulunk meg erőforrások tekintetében.

AZ FPS-t az FSX-ben nem a GPU állítja elő nekünk, az csak megjeleníti. Az FSX maximális megjeleníthető FPS-e tekintetében mindig a CPU az elsődleges. A GPU csak azt határozza meg, hogy ebből mennyit tud kirajzolni. Ha bármelyik folyamatosan 100% körül teker ( a 89, 91, 96 is maximális terhelést jelent) akkor az az elem elkezd stutter-t generálni nekünk, elkezd ingadozni az FPS.

Pár példa a működésre: egy alap FS scanery a GPU-t fogja jobban terhelni, mert a rengeteg autogen fát, alap textúrákat nem kell annyit számolni, csak tömegével megjeleníteni. Ha még felhő, és víz is van akkor még a shadereket is rá kell húzni mindenre, így lehet hogy a CPU 70-100% között ingadozva dolgozik, de a GPU kikoppan a terhelés alatt, és nem tud mindet kirajzolni, ezért újra számoltatja a CPU-val, ami FPS-vesztést okoz, mert ugyan azt kétszer kell kiszámolni. Ez a jelenség legtipikusabban az ATI kártyáknál tud jelentkezni felhős időben, mert mint írtam, itt bugos "kicsit" a rendszer, és az AA nagyon megfogja a videó kártyát.

A másik véglet amikor a GPU míg vígan szaladna, de CPU belefullad a melóba, mert nem tud mindent időben kiszámolni. Tipikusan ilyen egy Budapest 2.0, amikor állunk Liszt-Ferihegyen és az addigi jó FPS-ünk lent poroszkál 10 környékén, holott a GPU csak 30-60% körül unatkozik. Ha itt átpillantunk egy picit a CPU használatra akkor látjuk hogy (alap beállításokat feltételezve) egyes CPU magunk ( core0 ) folyamatosan 100% közelében van. (a többinek most nincs nagy jelentősége) Ez azt jelenti, hogy mire kiszámolta a CPU a 3D vázat, és kiszámolta rá a textúrákat, és ez elküldte a GPU-nak addig az nem nagyon csinált semmit.

Esetleg ha végleg le akarjuk fektetni a rendszert, akkor sok felhő, ég-szakadás, föld-indulás, meg PMDG, meg BP2.0. Ekkor valószínűleg mind a core0, mind pedig a GPU maximális terhelésen fog futni, ha ingadozik az ezért van mert hol az egyik, hol a másik vár a másikra, teljesen összezavarva egymást, és a rendszer "átesik".

A feladat tehát az, hogy olyan megoldást keressünk, amit a CPU adott idő alatt ki tud számolni, a GPU meg tud jeleníteni, és az adat forgalom alatt nem omlik teljesen össze a memória vezérlő, meg IDE/SATA vezérlőnk. (azt hiszem ezen a ponton látszik hogy ehhez mindenképpen szükségünk lesz egy fekete kakasra, babér levélre, és sápadt holdfényre....)

Az első dolga mindenkinek az legyen, hogy a könnyebb kezelhetőség érdekében az FSX.CFG-ben üssön egy üres sort minden kapcsos zárójellel kezdődő sor elé. Így könnyebben megkereshetőek, átláthatóak az egyes részek.

A Te fsx.cfg-d nem ebben a sorrendben fogja tartalmazni a bejegyzéseket, mert ahányszor újra generáltatod a cfg-t annyiszor lesz más a dolgok sorrendje. Azt hiszem erre mondják hogy ez nem bug, ez már fícsör.

[BufferPools] Nincs benne alapból

Nagyon fontos rész! Ez grafikus adatok CPU/GPU közötti cserélgetésért felelős. Ha valamit kiszámolt a CPU, elküldi a GPU-nak, aki jobb esetben megjeleníti azt. Két eset van, a GPU-nak van ideje nyugodtan átvenni az adatokat, mert ráér, és memóriája is van szabadon, vagy nincs, és akkor baj van. Ha nincs kapacitás, akkor viszont elveszik az adat és újra kéne számolni a CPU-nak. Erre van BufferPool, ami egy átmeneti tároló. Van viszont vele egy kis gond, hogy lassú, és további CPU időt vesz el a vezérlése.
Ha túl sok adat jön a CPU-tól akkor viszont "átesik" a sok adattól a GPU. Tehát ha gyors a CPU az is gondot okoz, mert ugrál a táj a gép alatt, "stutterel" miközben az FPS elég magas. Ha viszont nem etetjük a GPU-t akkor meg csak malmozik, és mivel az FSX motorja szabja meg a dolgot, a CPU azt fogja hinni hogy a GPU le van terhelve, és nem küld neki több adatot, beáll a lagg, esik az FPS. Remélem a leírásból érthető, hogy kényes a dolog, és kísérletezni kell vele.

A másik gond, hogy ezekkel a beállításokkal azt is meghatározzuk, hogy az FSX kezelje a videó kártyát, vagy átadjuk azt a driver-nek. És ahány driver, annyi gond....

A mai kártyákon, 4870-től, 8800Gt-től fölfele, 1GB vRam mellett egy monitoros üzemben elméletileg az a jobb ha kikapcsoljuk, mert a GPU elég gyors, és van elég memóriája fogadni az adatokat, ha driver is úgy akarja. Ennek ellenére előfordulhat, hogy vissza kell kapcsolni mert instabil lesz a futás.

Ha ki akarjuk kapcsolni, írjuk be az fsx.cfg-be:

[BufferPools]
UsePools=0

Ha viszont azt vesszük észre, hogy textúra csempék feketék lesznek, égig érő fenyőfa szerű képződmények ugrálnak, akkor a GPU átesett, nem stabil a rendszer. Ezt futtatással, és folyamatos GPU-Z figyeléssel ellenőrizzük. Ha a GPU csak 70-80%-ig kihasznált, de mégis grafikai hibákat tapasztalunk, annak CPU oldalon kell keresnünk az okát, vagy egyszerűen nem tudjuk elég gyorsan mozgatni az adatokat. ( VGA sávszélesség probléma, vagy lassú HDD)

Ekkor be kell kapcsolni, és azzal kell próbálkozni, hogy a kis méretű adatokat (autogen tipikusan ilyen) bedobja a tárolóba a program a GPU-nak, az meg majd "kiválogatja" ha van ideje rá.

Itt két dolgot tudunk állítani:

PoolSize=

Ami megadja hogy mennyi memóriát akarunk fenntartani erre a célra, mennyi videó memóriát kezeljen az FSX. Itt van egy lehetőség, ami vagy bejön, vagy nem: PoolSize=0 ebben az esetben a videó memória kezelése driver szintre kerül, (gyakorlatilag mintah kikapcsolnánk, de a driverek nem mindegyik megoldást szeretik) ami viszont azt eredményezheti, hogy az FSX lefagy, szétesik, kigyullad, összedől. 1GB vRam alatt ez nem használható! Az hogy a pool használatát eleve tiltjuk, vagy nulla értéket adunk meg neki, azt gyártó, és driver egyaránt válogatja. Próbálkozni kell. Fontos viszont, hogy ha az előbbiek bármelyike nulla, akkor a következő beállítást ne használjuk.

A PoolSize értéke: 1000000 = 1Mb-ot jelent, a default 4000000. Van aki 200000000 értéket javasol, van aki kevesebbet. Itt nincs Arany szabály, csak próbálkozás. Minél nagyobb a szám annál valószínűbb hogy valami másnak nem talál az FS memóriát, és stuttert okoz, vagy fagyást.

Máshol javasolt értékek próbálkozáshoz:

Poolsize=XXXXXXXX // 10000000 - 15000000 /512MB vram, 35000000 / 640MB vram, 70000000 768MB vram 100000000 és 490000000 között (100 - 490MB) nagyobb vram-os, egy magos videó kártyákhoz.

RejectThreshold=

Ami azt határozza meg, hogy mekkora méretű adat után adja át direkt a poolt megkerülve GPU-nak az adatot. Így lehet az hogy a kis méretű dolgok, mint autogen kivárják a sorukat, a nagy dolgok (pl nagy 3D objektumok) meg egyből betöltődnek.

Néhány példa, amiből ki lehet indulni a próbálkozások során:

524288 = 512K
262144 = 256K
126976 = 128K
98304 = 96K

Ezek az érvényes értékek, ha mást írunk be, az érvénytelen érték, és default-ra áll be, amit nem tudok megmondani hogy mennyi.

Mindenkinek a UsePools=0 beállítást ajánlom 512Mb vRam-tól felfele, és ha teljesítményben a kártya felette van egy 8800GT-nek.

Ha az nem stabil, akkor innen érdemes indulni

[BufferPools]
PoolSize=100000000
RejectThreshold=524288

És először a RejectThreshold értékét érdemes csökkenteni, megkeresni a legstabilabb működést, és utána szükség szerint emelni vagy csökkenteni PoolSize méretét. 512Mb vRam-ig nem érdemes 100Mb felé menni, mert gondokat okozhat.

[GRAPHICS]

Ezeket többségét is CPU-ból oldja meg az FS, nem a GPU feladata!

ForceWindowedVSync=1/0
ForceFullScreenVSync=1/0

Ha szétcsúszik a kép fordulóban (vízszintes csíkozódás, lagg) , akkor ez lehet a gond, viszont ekkor ugye nem tudunk a monitor frissítési frekije felé menni FPS-ben. Ha viszont nagyon magas az FPS, de stutterel a grafika, akkor kapcsoljuk be, és valószínűleg kisimul, Bővebben erről a Frame limit részen lesz szó.

FONTOS! Az FSX felbontása, és frissítése egyezzen meg a windows desktop felbontásával, és frissítésével. Ha nem egyezik, akkor belaggol, nem textúráz rendesen, stb.

AC_SELF_SHADOW=0
Ez legyen nulla, mert nagyon bug-os. És akkor is számolja, ha fülkében ülünk. Ha valakinek fontos, és másra nem kell a teljesítmény, bekapcsolhatja. (így leszenek árnyékok a virtual cockpit-ban is, ha natív FSX modell a gép amivel repülünk.

AIRCRAFT_REFLECTIONS=1
Fény, tükröződés a gépen, külső nézetben van jelentősége, nincs vele gond. Kisebb teljesítményű VGA esetén megéri kikapcsolni. ( =0 )

AIRCRAFT_SHADOWS=1
Legyen-e árnyéka a repülőnek. Max 1-2 FPS veszteség, ha be van kapcsolva.

D3D10=0
Dx10 üzemmód. Használata nem, vagy megkötésekkel ajánlott, mert nem lett kész, nincs optimalizálva, és egy bug hegy. Több kijelzős üzemben viszont jobb megoldásokat hozhat. Külön kitérünk rá a későbbiekben.

GROUND_SHADOWS=0
szigorúan nulla, mert ha nem akkor minden kis 3D objektumnak árnyékot számolna. Akinek alapból van 200 FPS-e Manhattan felett, az tehet vele egy kísérletet.

HIGHMEMFIX=1
FONTOS!! BE KELL ÍRNI! SP1 óta létező paraméter. A textúra kezelés memória használatát helyezi új alapokra, sokkal stabilabb, simább működést biztosít, és nem fogy ki a memóriából az FS, igy nem fagy le (remélhetőleg) több órás repülés közben.

TEXTURE_MAX_LOAD=1024
A legnagyobb textúra méret amit betölt az FSX. Ha REX telepítve van a HD textúrákkal, akkor átírja, ami úgy is marad mindaddig, amíg a menüben arrébb nem rak az ember egy csúszkát, mert akkor vissza áll 1024-re, és HD 4096x4096 felhőkből is csak a negyede töltődik be. Ha REX-ből indítjuk az FSX-et, akkor mindig beírja az ott megadott értéket.

STALE_BUFFER_THRESHOLD=1024
Fontos! Nincs benne! Be kell írni! Stabilitást és sebességet is növeli. Nem malmozik a textúrákkal, meg írogatja ki virtuális memóriába fölöslegesen.

[TrafficManager]
AIRPORT_SCENERY_DENSITY=0
AirlineDensity=0
FreewayDensity=0
GADensity=0
IFROnly=0
LeisureBoatsDensity=0
ShipsAndFerriesDensity=0

Ha ezeket a menüben nem vettük le, akkor itt most minden nulla. Rengeteg CPU idő kell a sok kis vacak, alias forgalom kiszámításához, ami nekünk még a tweak elején másra kell. Majd ha minden megy rendesen akkor óvatosan lehet emelni ezeken, de csak azokon ami kell is.

[Weather]

CLOUD_COVERAGE_DENSITY=7
Mennyi felhőt rajzoljon ki 1-8 lehet az érték, jelentős befolyása van az FPS-re. De a kevés felhő nagyon vérszegénnyé teszi az FSX-et.

CLOUD_DRAW_DISTANCE=5
mennyire nagy területen rakja ki az előzőekben meghatározott felhő mennyiséget ( 1-8)

DETAILED_CLOUDS=1
Rendes 3D-s felhők legyenek, vagy FS2004 szerű default 2D pamacsok.

THERMAL_VISUALS=0
Termik látszódjon-e. 1-nél madarak köröznek benne (CPU zaba) 2- nagy ződ spirál ahogyan látod nyáron a termiket.

[Main]

DisablePreload=1 (nincs benne)

indításkor hamarabb jön be a menü, mert nem kezdi el betölteni a beállított default flight-ot.

FIBER_FRAME_TIME_FRACTION=0.33
Mennyi időt szánjon a 3D "csontváz" számolására a CPU, ms-ben megadva. A default 0.33. Lassabb gépeknek több idő kelhet, hogy minden a helyén legyen, gyorsabb, több magos gépeken kevesebb elég. A több magos gépeken ez a core0-n fut alapértelmezés szerint. (ha nincs máshol belepancsolva a dologba) egy I5-I7 gépen kisebb érték magasabb FPS, mindaddig, amíg annyi idő alatt végez a proci az egész leszámolásával. Ha nem, akkor jön a lagg, meg az ugráló objektumok, meg egyéb bajok. I7-en állítólag 0.15 jó érték (4Ghz). Az így felszabadult időben van ideje a procinak inkább többi marhaságot le renderelni, mint pmdg műszerfal, meg terminál épület tetején csillanó napfény. Viszont az is lehetséges, hogy a mag le van terhelve az operációs rendszer által dolgokkal, amik miatt ennek a magnak a teljesítménye (kihasználtsága) ingadozni kezd. Ekkor megint jelentkezik a "stutter" jelenség. Ennek megoldását lásd [JOBSCHEDULER] illetve a bevezetőben említett Game Booster segíthet.

Ezt a beállítást teljesen külön kell tesztelni mindentől. Sok esetben az hoz jobb megoldást, ha teljesen kihagyjuk, máskor meg lehet hogy vagy az érték növelése, vagy csökkentése hoz jobb eredményt. Fontos, hogy mindig összefügg a viselkedése az affintiy mask beállításokkal. Tehát ha ott változtatunk, akkor futás közben nézzük a magok terhelését, és ha kell térjünk vissza ide. Ez igen idő igényes próbálgatás, de másképp nem megy sajnos.

FONTOS: Ha az affinity mask úgy van beállítva, hogy a core0 szabadon marad (nem fut rajta az FS) akkor ezt a bejegyzést vegyük ki, illetve ne írjuk be, mert a fiber mindig a core0-n fut, tehát ez akkor is ott marad, ha a magról a main thread le van tiltva. Ha bent marad, fölöslegesen lekorlátozzuk a számítási kapacitást.

Update: 4 fizikai mag esetén használjunk 3-at, és FIBER_FRAME_TIME_FRACTION=0.66, és használjunk külső frame limiteret, amit 1-2 Fps-el kevesebbre veszünk, mint egy általunk preferált terület felett mérünk. (NE BP 2.0 legyen, pmdg-vel, de azért sok objektum legyen)

Az a jó, ha mondjuk 31-32 fpst minimumot ki tudunk sajtolni a rendszerből, és limitáljuk 27-ben a külső limiterrel.

ProcSpeed=
Itt egy szám lesz utána. Ez egy viszony szám, ha kitörlöd ezt a sort, újra generálja, kb windows élmény index, 11K felett már egész jó, de PMDG737+Budapest 2.0+REX-hez nem nagy gond ha 20K-hoz van közelebb, mert ekkor várhatunk reálisan 30 FPS körüli értéket. 13-14K alatt maradnak tinédzser FPS-ek Budapesten, nem lehet jobb a dolog, mert egyszerűen kifogy a CPU a szuflából. Fontos, hogy ha valakinek ez egy I5 vagy I7-es procival csak 7K-körül van az több dologra is enged következtetni. A legfontosabb, hogy speed step a BIOS-ban engedélyezve van, így amikor megvizsgálja a program a sebességet, akkor még nem pörög a proci teljes teljesítményen. A másik ok a hyperthrading/multithreading lehet, mert a virtuális magokkal nem tud számolni (így használni sem) az FSX. A multithreading-et ki kell kapcsolni FSX-hez. Az FSX szereti a CPU túlhajtását. Amit el lehet érni a fizikai magokon túlhajtással, azt ki is fogja használni. (viszont: stabilitás, stabilitás, stabilitás)

Fontos!: Az FSX CPU magonként limites. Tehát bármelyik CPU szál koppan ki, ott a rendszer teljesítőképességének határa. Az egyes szálak ha túl terhelődnek nem kerülnek át másik, még szabad erőforrással rendelkező szálra, hanem CPU limitbe ütközünk. Egy nagy mennyiségű 3D objektumot tartalmazó add-on-nál a fiber lesz a szűk kereszt metszett, egy rengeteg textúrát tartalmazó, fotó realisztikus dolognál meg T&L egységek fognak kikoppanni. A nagyfelbontású tájjal rendelkező rengeteg 3D objektumot tartalmazó, agyontextúrázott ORBX meg kőbunkóval veri le a CPU-t.

Update: Érthetőbben megfogalmazva: A CPU magok sebessége azt mutatja milyen gyorsan tud valamit kiszámolni, a száma pedig hogy milyen gyorsan tudja feltextúrázni.

[Display]

BLOOM_EFFECTS=0
Bugos, és CPU zabáló, mert prociból akarja számolni.

TEXTURE_BANDWIDTH_MULT=
MAX_TEXTURE_DATA=
Ez egy trükkös része a dolgoknak. Sok különböző dolgot próbáltam, olvastam, de egy volt ami tényleg úgy tűnik hogy jó, és bevált. A teljes leírás itt található. lényeg, hogy a két értéket ki lehet számítani, ha tudod VGA-d adatait, amire kiválló a GPU-Z nevű program, ha valakinek nem ismerős.
A target frame legyen 33 ami ideálisnak tekinthető, viszont SZERINTEM a kapott értéknek csak kb 90%-át szabad ráereszteni a kártyára, ezért kalkuláció 39 FPS-re is, és valahol ott lesz az igazság a kettő között. FONTOS HOGY EZ CSAK EGY KIJELZŐRE IGAZ! TÖBB KIJELZŐVEL KÉSŐBB FOGLAKOZUNK!

Figyelem, ezeket az értékeket elállíthatja az FSX, ha összeomlás után újra indul, vagy átállítasz valamit a menüben!

Update: AZ előző bejegyzéshez képest a régi fejlesztői blogokban megtaláltam a TEXTURE_BANDWIDTH_MULT= működését. A belső frame limiternek lett kitalálva, hogy hány fps-re számolva kezdje el benyomni a videó vezérlőbe a textúrákat. Tehát ez egy elvárt fps értéket jelez. És itt van a kutya elásva. Elvileg annyira állítsátok, vagy egyel kevesebbre mint ahány fpst ki szeretnétek sajtolni a gépből. Magán vélemény, hogy az eredményezheti a stabil jó futást ha belőjük úgy az FSX-et, hogy mindenütt, mindennel tudja tartani a 33 fps-t röcögés nélkül. (nekem még nem sikerült, de dolgozom rajta)

Tehát PMDG-LHBP stb fertőzöttség esetén ez ne legyen több mondjuk 25 nél vagy 30-nál. (szerintem)

UPPER_FRAMERATE_LIMIT=0
Fontos! SOHA nem használjuk az FS saját frame limeterét, mert bekavar! Ha túl sok az FPS sima autogen felett, és emiatt stutterel, akkor külső frame litert használunk. A beépített frame limiter nagyon bugos, egy gyilkos a teljesítményt illetően.

Dx9 módban mindenképpen javaslom a külső frame limiter használatát, mert sokkal simább futást tesz lehetővé. Sok esetben ugrál az FPS 110-90-70-30-100-22 értékek között függően attól, hogy mennyit kell számolgatni. A limiterrel be lehet lőni hogy ne szaladjon túl, optikailag kisimítva a futást. Érdemes a frissítési frekvencia felére venni a számot, tehát 30-33 FPS körül. Persze ha soha nem esik 60 alá, csak felette van, akkor meg érdemes lehet 60-ban korlátozni, ha ennyi a frissítés, meg adni vsync-et, de ez csak elmélet ilyet én még nem láttam.

TextureMaxLoad=6 (nincs benne)

értéke lehet 3, 6, 9, ez egyszerre betöltendő textúrák számát korlátozza. Ha a GPU kikoppan akkor érdemes beírni, de textúrázási hibákat okozhat

WideViewAspect=True
már ha nem hagyományos 4:3-as monitorunk van. Ez kell a több megjelenítős üzemmód helyes működéshez is különben nem lehet rendesen kizoomolni. Tehát majdnem mindenkinek kell.

[JOBSCHEDULER]
Nincs benne, ha szükséges lehet, be kell írni

AffinityMask=

meg tudjuk adni melyik magokon fusson az FS, és melyiken nem. Sokan letiltják a core0-ról, hogy ne kelljen a rendszerrel osztoznia, ami laggolást, stuttert okozhat, mert ugye alapból core0-n fut a render, meg a 3D váz számolása. Nekem ez csak FPS csökkenést hozott 4 magon, DX9-alatt, semmi mást. Állítólag 6-8 fizikai magon jó hatással tud lenni az eseményekre, de megoszlanak a vélemények. Utolsó dolgok között legyen szerintem, amit elkezdtek állítgatni. Ha minden magon fut rendesen az FSX a monitorozás szerint, és más programok nem kavarnak alá, az a legjobb szerintem. Ha viszont DX10 alatt fut az FSX, vagy más programok is futnak vele, amiknek nagy az erőforrás igénye, akkor 4 fizikai mag esetén:

[JOBSCHEDULER]
AffinityMask=

ekkor a core0 szabadon marad a rendszernek, meg egyéb alkalmazásoknak, jelentősen csökkentve ez által a laggolást, illetve stabilabb simább futást biztosít. Ez esetben a fiber (3D váz) számolására is külön tud valószínűleg a core0-n időt adni, de ez nem bizonyított. Próbálkozni kell.

A neten sok helyen megtalálható hibás javaslattal szemben ezt nem arra használjuk, hogy az összes magon fusson. Az összes magon (fizikain) kell futnia az FSX-nek ha jól van telepítve. Az Affinity arra használható, ha azt akarjuk, hogy valamelyik magon NE fusson. Az hogy az adott magot letiltjuk, azzal csak az FSX main threading alól, azaz a fő program szál alól tiltjuk ki. Ha többi szál megszalad, akkor lehet hogy a rendszer mégis ad időt nekik a core0-n. Sajnos sem az Aces-nél, sem az Intel-nél nem dolgoztam, hogy tudjam mi van a gyári kódban, és ettől kevésbé már csak a Microsoft avatott be a win7 és társai erőforrás gazdálkodásába.

Lehetséges értékek, példák:

1 = 1 core 0001
3 = 2 cores 0011
7 = 3 cores 0111
14= 3 cores 1110
15= 4 cores 1111

1 uses 0
2 uses 1
3 uses 0 & 1
4 uses 2
5 uses 2 & 0
6 uses 2 & 1
7 uses 2, 1, & 0
8 uses 3
9 uses 3 & 0
10 uses 0, 1, 2, & 3

az utolsó mindig a core0, amit szabadon akarunk hagyni, tehát 4 FIZIKAI mag esetén AffinityMask=14,
6 FIZIKAI mag esetén pedig AffinityMask=62.

Ha core0 szabadon marad, akkor a main thread nem fut rajta. Érdekes lehet monitorozni a CPU kihasználtságot, mert ha core0 terhelése így is 50% körülire kúszik fel, akkor valami vagy nagyon terheli a rendszerünket fölöslegesen, és azért stutterel(t), vagy a fiber számításokra nincs elég CPU idő a bonyolult scenreyk felett, és ad neki időt a rendszer. Próbálkozni kell, de ne ezzel kezdjük!

[JOBSCHEDULER]
AffinityMask=14

abban az esetben ha 4 FIZIKA (nem, nem HT) magos rendszerünk van, I7 esetén kapcsold ki a biosban a HT-t. Elvileg így a legstabilabb, és várhatóan röcögés mentesebb a rendszer

[SCENERY]

LENSFLARE=1

Érdemes bekapcsolni, mert ekkor lesz rendes nap, e nélkül csak egy paca (sp1-óta)

SmallPartRejectRadius=3.0 (nincs benne)

Mekkora pixel felett kezdje el megjeleníteni a dolgokat. Ha "ugrálnak" "hullámzanak" a horizont felé távolodva az autogen dolgok akkor érdemes használni, 5.0 felett már viszont olyan dolgok is eltűnhetnek amiknek látszani illene, pl a repülőgép futó szára, szárnya, stb. Mivel kevesebb dolgot kell megjeleníteni, így növeli a grafikus teljesítményt, 3-5 FPS-t hozhat, ha beírjuk.

[TERRAIN]

LOD_RADIUS=4.500000

Mekkora területet töltse be az autogent, és a részleteket a gép körül. Ram-vRam függő. 2.5 és9.5 között lehet változtatni, ha kisebbre vesszük, akkor bár kevesebbet kell számolni a CPU-GPU párosnak, viszont nagyon sokat kell tölteni a HDD-ről, Ha magasabbra vesszük, akkor messzebbre látunk a tájban, nem látszik hogy kirajzolja az objektumokat, de rendesen adunk a memóra-CPU-GPU terhelésnek. Felső kategóriás gépeken 7.500000 lehet egy jó érték, egyéb esetben ne nagyon változtassunk rajta. Menüben csúszka állítás vissza állítja.

WATER_EFFECTS=4

Nem érdemes feljebb venni, mert a látvány emelkedése nem áll arányban a teljesítmény igénnyel.

AUTOGEN_DENSITY=5

Ha nagyon levesszük az utogent, akkor az is okozhat ingadozó teljesítményt. Csak akkor kezdjük vissza venni, ha más reálisan nem segített. Ez sajnos egy bug a motorban.

Update: Javaslom hogy első körben az FSX-en belül a Normal beállításokkal kezdjen. A túl sok autogen elsődleges oka lehet az ugráló FPS-nek. Ha nagyon Ingadozik az FPS, (egyszer 80, aztán 30, aztán megint 80) akkor első körben itt keressük a hibát.

SWAP_WAIT_TIMEOUT=10 (nincs benne)

lehet 1-99, ideális értékek 10-20-30-33 érdemes össze nézni a Fiber_Frame beállításokkal, és kicsit fölé belőni. Ez kell ha kamera forgatás, meg töltés közben a textúra csempék egy része (2-3 db általában) fekete négyzet, és csak utána töltődik be. Azt határozza meg mennyi a textúra "elévülési" ideje. Ha hamar lekapjuk, akkor lehet nincs kiszámolva az új textúra. Kisérletezést igényel, de mát ne állítsunk a tesztelések között, ha ezt próbálgatjuk.

A következőt nem ajánlom csak kis teljesítményű gép esetén!!!!!!!!!

TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=2000
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=3000

Ezekkel le korlátozzuk az autogen-t, ez lesz a extrém érték maximuma, és ha vissza vesszük, akkor ezt fogja osztani. Sok gubancot okozhat, rengeteg objektum eltűnhet, de néha csak ez segít. Viszont fs2004 szintűre szelídül a fák és házak mennyisége. Mind két érték default 4500.

Ezek a legfontosabb kapcsolók a cfg-ben.

Amit meg lehet próbálni még:

Az autogen xml szerkeztése, hogy csak 8-bitben dekódolja. Ez az egyetlen xml az FSX-ben ami 16 bites. Én azt tapasztaltam, hogy így is kevesebb lesz az autogen fa egy kicsivel, de még nem zavaró.

\(FSX-könyvtár)\Autogen\default.xml

nyissuk meg szerkesztésre, és az első sorát:

<?xml version="1.0" encoding="utf-16"?>

írjuk át erre:

<?xml version="1.0" encoding="utf-8"?>

3-5 FPS-t tudunk vele nyerni.

9-ről 30 FPS-re

Itt egy videó a "varázslatról".

Mindenkit óvatosságra intenék, mert tényleg működik, DE!:

- csináljunk mentést a scanery mappáról, mert véglegesen lecseréli a tartalmukat. Így ha nem tetszik a végeredmény, és vissza akarjuk állítani, akkor backup híján csak a reinstall marad.

Működésének lényege:

egy jobban (nagyobb veszteséggel) tömörített textúra pack-ot rakunk fel, aminek kisebb a mérete, és gyorsabban dekódolható mint a gyári textúra formátum. Csak a default dolgokra van hatással, az addon dogokra nincs, kivéve amelyik a default textúrákból építkezik. ( A legtöbb fizetős scanery is ezekből az objektumokból építkezik, kivéve pl orbx, BUD2.0 amiknek teljesen saját textúra készlete van) Tehát nem statikus gyorsulást hoz, de mindenütt segít egy kicsit, viszont érzékelhetően rondábbak lesznek a textúrák (nem vészes, de észrevehető), ezért kell a mentés, és ha nem bejövős, akkor vissza másoljuk a gyárit és kész.

Innen lehet letölteni. a RAR file jelszava: whiskeymike

FPS Limiter

Ha még mindig stutterel a kép, és az FPS mérés is azt mutatja hogy nagyon ingadozik az FPS, akkor mindenképpen próbáljuk meg a frame limitert.

Egy .bat file-t kell létrehoznunk, vagy parancsikon, és azt szerkesztjük amiben ilyesminek kell szerepelni:

start g:\util\fpsl\FPS_Limiter.exe /r3D9 /f:33 "F:\fsx\Fsx.exe

g:\util\fpsl\FPS_Limiter.exe (ahova az FPS limitert raktad)

/r3D9 (dx9 alatt korlátozunk, sajnos dx10-et még nem tud)

/f:33 (hány frame legyen, ez 33 körül ideális, de próbálhatsz átlag FPS-t mérni, és az alá lődd be kicsivel)

"F:\fsx\Fsx.exe (értelemszerűen az FSX.EXE helye nálad)

A az= : D egybe írva, csak a html itt bekavar

Update: Vannak új megoldások az FPS limitre, hamarosan frissítem a cikket. Az új megoldás lényege, hogy egy külső .dll és .cfg bemásolásával, amit az FSX automatikusan betölt, egyből a DirectX-be piszkál bele, megkerülve az FSX motorját. Le lehet cserélni az AA mode-ot, annak mértékét, a grafikai effekt készleteket, és még FPS is lehet limitálni. A gond hogy még nem találtam meg a teljesítmény/látvány/kompatibilátás aranyháromszögben a stabil megoldást.

Update: Teszteltem a d3d9 antilag programot.

Telepítés: be kell másolni az FSX gyökér könyvtárába a d3d9.dll file-t, és az antilag.cfg-t. A cfg notepaddal szerkeszthető.

Nagyon le lehet terhelni az effektekkel a videó kártyát, nagyon látványos tud lenni, de a rengeteg beállítási lehetőség és egyebek miatt erről egy későbbi bejegyzésben elmélkednék. Majd... egyszer...

Türelmetleneknek instant javaslat:

ezeket írd be a cfg-be. Nem lesz tökéletes a dolog ezért kell elolvasni a fentebbieket.

[GRAPHICS] bejegyzés alá

highmemfix=1

módosítani:

[Display]

UPPER_FRAMERATE_LIMIT=0

ha 16:9-es monitorod van akkor ugyan itt módosítani

WideViewAspect=True

beírni zárójelestől:

[BufferPools]
UsePools=0

[JOBSCHEDULER]
AffinityMask=14

utolsót abban az esetben ha 4 FIZIKA (nem, nem HT) magos rendszerünk van, I7 esetén kapcsold ki a biosban a HT-t.

Ha ez megvan, akkor olvasd el a cikket, és rájössz miért kellett volna elve azzal kezdeni

A bejegyzés frissülni/folytatódni fog folyamatosan. Ha valami nem tiszta, vagy tapasztalat mást mutat nálad, várom észrevételed, véleményed. Az írás célja a segítség, és könnyebb megérthetőség, így kérlek ha mondandód, hozzáfűzni valód van, azt szintén segítő, és emberi hangon tedd meg.