Mejoras en FSX

[NOA]

No sé si habéis seguido el tema BP=0 en AVSIM. Al final, se ha convertido en la entrada más larga de la historia en los foros de AVSIM. El tema trata sobre la mejora de rendimiento en FSX. Han dejado fijo un resumen del tema. Algunas conclusiones son contradictorias con las “antiguas creencias” -mejoras de NickN-. En mi caso, me ha servido para mejorar, aún más, el rendimiento de FSX y también a comprender por qué necesito limitar los FPS en mi nVidia.

 

Todo el crédito es de Jesús Altuve (Bojote)

 

DISCLAIMER:

 

What you are about to read CAN PRODUCE UNFAVORABLE RESULTS depending on your particular setup and slider settings, so this is NOT a 'solution' to any problem, this is simply a hidden, undocumented tweak that can be applied to Flight Simulator X to obtain aproximately a 30% performance improvement.

 

Before I begin, a little background.. I've used this tweak personally, for more than a year, second, I have dedicated considerable time 'understanding' the tweak, its purpose, and specially the 'reasons' why there is such a 'dramatic' performance increase. So please... DO NOT TRY if you have 'issues' or problems in your current setup, only try it *IF* you are absolutely certain that you have a fairly stable setup and that you UNDERSTAND what I'm explaining in the following lines:

 

Lets first discuss 'how' applications, 'particularly' FSX works (I will keep it simple)

When you 'fly' in FSX, each 'frame' its like a 'photo' it contains certain objects and textures that need to be 'drawn' for EACH 'photo'. When you play this 'photos' in rapid succesion, say, for example 25 'photos' per second, the perceived sensation is that you are 'moving' FPS = Frames per Second, each 'frame' is the 'photo' I'm talking about.

 

In FSX, the 'rendering' or 'drawing' of this objects, occurs, on a per 'frame' basis.. the higher the frames per second, the higher the number of objects that need 'drawing' This 'drawing' works by having the 'CPU' instruct your 'video card' what to 'draw' on screen. Each 'instruction' the CPU sends to the video card is 'queued' in a 'buffer' FSX, then 'determines' the 'threshold' where that buffer is 'filled' to flush all the commands to 'another' buffer, this one is called the Command 'ring' buffer.

 

This happens, so FSX can syncronize the CPU and the GPU in terms of instructions proccesed. If this 'buffer' the one created by the application, didn't exist, then you could 'under certain conditions' COMPLETELY CRASH FSX. The reason for this 'crash' is that FSX would have to send the intructions 'directly' to the 'Command Buffer', which is the one that the Video card reads to 'draw' the objects on screen.

 

If the video card is not fast enough to process the INCREDIBLY high number of 'draw calls' sent by the CPU per each frame (photo), then STALLING occurs. Stalling, means that the CPU 'writes' into the command buffer FASTER than what the video card is capable of proccesing (the command buffer its a ring) its finite it can hold 'certain' number of instructions at a given time, if the video card doesn't read it fast enough it gets overwritten and video corruption occurs (you'll know this because spikes come out from the AUTOGEN)

 

If you understand the above correctly, then you also must understand that 'application managed' buffers (aka BufferPools) 'cost' some CPU usage, and particularly in FSX this usage is MASSIVE! however, this is NOT a bad thing, its a 'safety' mechanism that the application uses so its almost imposible that it will 'fill' the command buffer with instructions. The 'Aplication managed' buffer, is like a 'middle man' it coordinates what goes into the command buffer and 'how' to keep things in sync so you don't batch an exessive ammount of objects for the video card to process.

 

So, why does Microsoft includes an 'application managed' Buffer (also called Explicit Vertex Buffers)? they did so, so ANY ONE could use FSX regardless of setup and ensure 'up to a point' that this will perform reliably indepently of hardware. So, DONT BLAME MICROSOFT!! they did the right thing and this is NOT a bug.

 

So, what happens when you tell FSX to 'bypass' this 'application managed' buffer and send all the 'draw' instructions DIRECTLY to the command buffer for the video card to process? (instructions are really sent to the D3D API, I'm just keeping the explanation simple for our sarcastic folks out there) well.. what happens is that FSX doesn't need the middleman anymore, what happens is that FSX doesn't need to control what to draw or when to draw it. Now, it simply pumps all the information as fast as it can to the Video Card, and by doing so you FREE a massive ammount of resources that are now allocated to your current flying session!! Now.. Do you understand why this tweak is SO powerfull, but at the same time, EXTREMELY dangerous for stability? It is because you need to have an INTIMATE knowledge of WHAT is going on in your computer!! you need to know 'exactly' how much is 'too' much for the GPU to process.. and this is, where things get interesting.

 

How can you be 'sure' that your video card is in TOP shape and able to process ANY and EVEYTHING you throw at it? remember... this is NOT about 'raw' power... this is about the card ability to 'process' the commands sent by the CPU, FASTER than the CPU ability to 'send' those commands.. its like a 'race' and the GPU needs to be faster! so, this holds specially true for folks using overclocked i7's @ 4.2 and DONT BELIEVE your GPU % Usage meter! it only shows USER SPACE... it doesn't tell you how much the 'kernel' (system) is using to process commands in the queue.. AND don't compare FSX to Crysis please... those are games OPTIMIZED to make full usage of hardware programable shaders! they are perfectly balanced!

 

well, you need to start forgeting EVERYTHING you have learned in the past 4 years.. specially things like:

 

(AntiAliasing) but only when it is controlled by nHancer

(Anisotripic Filtering) again, ONLY if controlled by nHancer

vSync set to ON (this is a KILLER)

Multiple Monitor setups (even clone mode)

The ENBSeries mod

 

the above, KILL the card ability to process commands 'but not the ability to RENDER or DRAW the objects' so if you absolutely NEED the above, you can stop reading now

 

So, if you want to give this tweak a try, you need to start by using the application controlled AntiaAlias and Anisotropic filters, you need to also force vSync to OFF, and make sure you are running a single monitor setup. this will ENSURE, that the card is in top shape to process commands 'as quick' as it can... specially, if using nVidia cards (ATI's dont have this problem, more on that later)

 

One side note: ATI's 5870 vs nVidias GTX 285 they are both EXCELENT cards... but they have completely different architectures, the ATI's have LOTS of tiny 'slow running' shader processors, the nVidias have fewer shader processors (a lot less) but they are TWICE as fast... so, how does this affects the cards ability to 'process' and 'render' draw commands?

 

well.. its up to you to decide: the ATI's have 1600 small processors, they are called 'shader processors' the more processors you have, the better the card ability to 'multitask' and do parallel processing so, the ATI's are FANTASTIC reading the command buffer faster than ANY card on the planet (even the new nVidias GTX 480, also called by their codename Fermi) so with an ATI you could practically have FSX nirvana if FSX were to send all draw instructions to the command buffer bypassing the BufferPools.. however, THERE IS A CATCH. Since ATI's have more shader processors, they need to run 'slower' (they run at 700Mhz) same as the core clock. so, complex scenery, clouds, add-on aircraft will considerably LOWER your total average FPS. so, again, its up to you to decide... if you only fly default planes, and want EVERY SINGLE SLIDER MAXED out, vsync, nHancer, ENBSeries mode etc. then the ATI is for you, ITS IMPOSSIBLE TO CRASH IT! I could crash mine (I only owned it for like 2 days) no matter what I tried, but I lost 6FPS! to me thats unnaceptable.

 

Now.. the nVidias, particularly the GTX 285, have exactly 240 Shader processors, they run at 1476Mhz (and some can be overclocked even higher) this card, is a monster... and even though the ATI's (in raw speed) are faster, the nVidias can render 'complex' scenes much quicker (specially things that relay on shaders such as clouds, high water settings, buildings etc.), so the CPU doesn't have to wait for a particular scene to be rendered. Remember, the FASTER the card 'renders' a scene, the faster the 'frames' will be processed and the CPU will keep producing them! so, as you see, there needs to be 'BALANCE'. remember, that any complex system will be limited by the speed of the slowest running member on the system. Now, back to video card comparisons: The downside to the nVidias?? THEY SUCK at reading instructions from the command buffer fast enough, so they can be stalled by the CPU IF you are running high frame rates and using complex autogen (which is what fills the command buffer quicker, specially after SP2 where there is massive object batching per frame) so when using nVidias LIMITING your framerate to 25-30FPS and lowering autogen is paramaunt. (including the steps I have already mentioned) like vsync OFF, single monitor setup, No ENBSeries and application controlled AA and AF. but don't worry.. The GTX 480's will change all that :) they have 480 shader processors :) still much less than the ATI's but enough to give you Flightsim nirvana and turn FSX into a whole new ball game. So, IT IS completely possible to achieve what everyone though was a dream. FULL MAXED sliders and fluidity (I don't include car traffic) MAX 2.0 Water (which is a killer) or bloom (the other killer) but you can still have pretty descent AI traffic and easily achieve 20-25 FPS under the most demanding conceivable situation, thats quite good.

 

So... IF you understand the above information COMPLETELY and you are a competent guy that knows how to tweak your fsx.cfg file, then by all means, give this a go.. otherwise, don't even think about trying it, and please, don't private message me because I'll not respond. I'm providing all this information for the benefit of the community.

 

The tweaks that you need to add to the fsx.cfg file are:

 

[bufferPools]

UsePools=0

(note that PoolSize is ignored if UsePools equals 0. Use 1 if you experience crashes )

When you see 'toggle' values (1 or 0) it means ON/OFF - UsePools its an ON / OFF value (1 or 0)

PoolSize its a 'size' value (in bytes) If you 'DISABLE' the pools, you will get increased

performance, AND ALSO, instability if you don't 'balance' your components and sliders

apropiately, in case of instability, then simply DO use pools by changing the value of UsePools

to 1 and 'adjust' PoolSize. BE CAREFUL (and forget everything you have been told about this value)

it does NOT use video memory, PERIOD. it uses SYSTEM memory, because its a special type of pool

called Explicit Vertex buffer which DOESN'T GO INTO VIDEO MEMORY unless they have A VERY SPECIFIC FLAG

(and they don't) more info here: http://msdn.microsoft.com/en-us/library/ff539490.aspx

you can also do your own tests and see how 'increasing' PoolSize affects the size of the fsx.exe process proportionally.

 

[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.

 

 

---------------------------

 

OPTIONAL

 

[GRAPHICS]

SHADER_CACHE_VERSION=1 // Increment this number EVERYTIME you change fsx.cfg (it simply rebuilds the shader cache)

 

 

[DISPLAY]

TextureMaxLoad=9 // Carefull. CAN induce stutters on LOW END systems! use multiples of 3 *ONLY* (3, 6, 9 etc) perfect for PhotoRealistic scenery and PNW

 

The formula on how to determine your 'optimal' TextureMaxLoad goes like this (credit to Steve Lacey here http://www.steve-lacey.com/blogarchives/20...blurries.shtml)

 

If UPPER_FRAMERATE_LIMIT exists, then:

MAX_TEXTURE_DATA = (TEXTURE_MAX_LOAD * (TextureMaxLoad * TEXTURE_BANDWIDTH_MULTIPLIER)) / UPPER_FRAMERATE_LIMIT

 

If UPPER_FRAMERATE_LIMIT doesn't exist (UNLIMITED FRAMES) then:

MAX_TEXTURE_DATA = TextureMaxLoad * TEXTURE_MAX_LOAD

 

As you can see above, TEXTURE_BANDWIDTH_MULTIPLIER its just that, a multiplier. Evidently, changing it DOES change things, however,

when running UNLIMITED frames, it is USELESS, so you are better of playing with TextureMaxLoad directly. be VERY CAREFULL, the 'resulting'

value of this formula (MAX_TEXTURE_DATA) corresponds to the MAXIMUM number of bytes the TEXTURE MANAGER is allowed to 'upload' per

frame. If the resulting value (in bytes) for MAX_TEXTURE_DATA is TOO HIGH you will spike your GPU! (and cause a stutter), so this is a

'test and see' value. Ideally, you'll see an impact on COMPLEX high resolution textures sceneries like PNW and/or PhotoReal scenery.

It is important to mention that THIS value does NOT have an impact on CPU if you are running a Multiple core setup, due to the texture

manager threads running in the cores responsible for texture loading and object batching. (which are the last 3 if you have 4 cores)

 

Now, the following requires a careful explanation... please, READ. This 'assumes', you have an i7 With Hyperthreading OFF.. so, it goes like this;

 

CORE0 CORE1 CORE2 CORE3

 

CORE0 is responsible for: Fibers and main scheduler

CORE1, CORE2 and CORE3 are responsible for the Texture Manager AND Object Batching (Autogen)

 

'Fibers' are like small processes that do 'things' cooperatively with other 'processeses' (sorry, I know this is not I high tech explanation)

I'm just trying to cater for everyone. In FSX. Fibers are responsible for the 'loading' of the terrain system. They need to communicate with the

main scheduler (which also RUNS on CORE0) to 'coordinate' and cooperatively multitask on terrain rendering every time a 'frame' is rendered.

 

Those two, the fibers AND the main scheduler are running on the SAME CORE... now, here's a trick. Fibers are STUCK to CORE0, you can not move them

out of there, however, YOU CAN move the main scheduler to run on another core!! so, if you do this:

 

[JOBSCHEDULER]

AffinityMask=14

 

you are telling FSX to use only CORE1, CORE2 and CORE3.. so, what about CORE0? it STILL runs the FIBERS! because they are not bound to the AffinityMask

setting. so, what you are doing is making things now much more efficent. So now, FSX will run like this:

 

CORE0 CORE1 CORE2 CORE3

 

CORE0 is responsible for: Fibers

CORE1 is responsible for: main scheduler

CORE2 and CORE3 are responsible for the Texture Manager AND Object Batching (Autogen)

 

thats great balance! (and a little increase in performance too!) thats why so many people say FIBER_FRAME_TIME_FRACTION affects their performance

when they lower it! of course it does, we'll talk about that now :)

 

Now, lets micro manage the 'fibers' and the terrain loading system. Consider this:

 

[MAIN]

FIBER_FRAME_TIME_FRACTION=0.25

 

the above value means that 0.25 (which means 25%) percentage! is the % ammount of 'time' that the 'fibers' will 'cooperate' with the main scheduler

to 'render' the terrain system. So, assume you run you sim LOCKED to 25 FPS... thats 25 Frames EACH second, correct? 1 second is the same as

1000 miliseconds. So, if you divide 1000 miliseconds / 25 frames what do you have? you have Miliseconds PER frame. That number is 40 Milisecond.

so, now we KNOW that EACH frame, takes aproximately 40 Miliseconds to render (if running frames locked at 25). Now, out of those 40 milliseconds

PER frame, HOW MUCH time (or % of time) you want the fiber to cooperatively multitask with the main scheduler? well.. if you read re-read and analyze

what Adam told Phil Taylor you'll see Adam hinted Taylor on 'what' the 'optimal' time is to do just that, Adam 'optimal' value required for the fiber

to communicate with the thread is 10ms read here: (thats why they came up with the 0.33)

 

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

 

So, that value should be adjusted according to your frame rate. Of course, it REALLY doesn't have any IMPACT whatsoever UNLESS you are running a SINGLE core machine (so you can not offload the scheduler) or you run tileproxy or something VERY heavy. For cases like tile proxy or VERY complex terrain I assume 10ms is simply not enough so you need to give the fiber MORE TIME

otherwise, the blurries are going to be TERRIBLE!

 

And talking about blurries, terrain and fiber time... :) we have:

 

[TERRAIN]

SWAP_WAIT_TIMEOUT=10

 

And you sure are asking why I have '10' there? 10 what? frames? well.. according to Phil this is a value between 1-60 'frames'

regardless of that Phil said, this SWAP_WAIT_TIMEOUT only has an impact when the time allocated to fibers is increased.. to me

SWAP_WAIT_TIMEOUT is not about 'frames' is about 'timeouts' in Miliseconds (per frame) so probably it was easier to say it was 'frames' so we would

not get confused play with it (specially if using HIGH FIBER_FRAME_TIME_FRACTION values) but don't expect a SINGLE frame in performance

increase.. this only helps with terrain loading and blurries. so try to adjust the timeout to the time fraction that it takes for the fiber to communicate

with the main thread. thats why I have '10' there.

 

Now... lets talk about 'frame locking'

 

You need to understand the following:

 

When you 'fly' in FSX, each 'frame' its like a 'photo' it contains certain objects and textures that need to be 'drawn' for EACH 'photo'. When you play this 'photos' in rapid succesion, say, for example 25 'photos' per second, the perceived sensation is that you are 'moving' at 25 frames per second. FPS = Frames per Second, each 'frame' is the 'photo' I'm talking about.

 

So, the above is VERY important to take into account, because in FSX, all operations! terrain rendering, object batching etc occur at the single 'frame' level... what does that mean to you? I means, the HIGHER the frames, the MORE work FSX needs to do.. so, say for example, that you run your SIM at 30 FPS and you like it.. but, then someone got into your head the idea that if its not 60 FPS then it is NOT real, well.. from 30 to 60 FSX will DOUBLE the ammount of things that it needs to do! so, don't be surprised when you start seening a christmas tree and strange spikes coming from the ground :).. I won't get into the 'FPS eye perceived thing' that has plaged our forums since day 1. run the sim at the FPS you like! I personally, got USED to run at 25, and let me tell you its perfectly fine to me.. because I got USED TO IT.. I hated it, but after a week, you simply 'adjust' your eyes to it.

 

So, should you use the FPS limiter or run to UNLIMITED? well it depends on your flying style... if you run default planes or non CPU intensive planes or only 2-D cockpits, then your CPU is NOT going to be overworked.. in that case, simply go for the frame lock inside FSX.. period.

 

Now, if you fly COMPLEX a/c specially using the VC you NEED to set it to unlimited! however... there is a problem what happens with what I just told you about the sim working HARDER the higher the frames? what happens if frames start jumping from 30 to 60 then to 25 and again to 60? where is the 'balance' here?? what if you have UsePools=0? what do you expect will happen when you get a 'sudden' jump to 70 FPS? CRASH! besides... the 'perceived' sensation (because is not real) when frames 'jump' is a 'stutter' so you need 'smoothness' consistency... and thats were the EXTERNAL frame rate limiter can help you capiche?

 

Now... use this as a REFERENCE... specially if using a HIGH SPEED CPU, and simply increase the Scenery Complexity and Autogen on at at time, and run your frames locked either in FSX or with the external limiter and setting the option to unlimited inside the sim. you want to find your 'sweet' spot, or the point where the GPU is not being overworked, I suggest, as 'reference' you use a GPU monitoring tool.. again, as reference, because what you see there is NOT 100% accurate.

 











 

 

 

SPECIAL THANKS:

 

To all the guys at Avsim, specially Ryan (from PMDG), David Roch, Stephen, Mitch, David Alexander, J van E, Jjjallen, PingPong, DJJose and all those who supported me since DAY 1, trying stuff, reporting back and being extremely supportive, despite the Party Poopers that tried to (using stupid baseless technical explanations) to discredit me. and guys... I REALLY need a break, so don't freak out if I take a long one! (also excuse any mispellings, english is not my mother tongue)

 

Jesus Altuve, April 2010

 

 

NB:

Because there is still a lot of things to discover, this thread will be updated every time el señor Bojote provide us with factual and accurate info so stay tuned!

 

Enlace a la entrada original en AVSIM

[rush]

Pues he probado a poner el BufferPool a 0 como dice, el affinity mask y limitar los frames a 40 como dice sin tocar nada mas y parece que me va mejor.

 

En plataforma del Barajas de Aerosoft consigo unos 25fps con el 737 De Wilco. Tendria que provar un vuelo en final que es cuando va peor, pero creo que hay una mejora apreciable.

 

Como FSX supongo que se programó hace unos añitos las targetas no serian tan potentes y el BufferPools se hacia necesario, pero conforme van siendo mas potentes se puede desactivar esta opción quitando una carga para la CPU, así tiene mas tiempo para otras tareas.

 

Gracias por la información.

[NOA]

Yo he pasado el Antialiasing y el Anisotropic Filter a la opción “controlada por la aplicación” en el nHancer. Y el vSync a Off. Además he añadido en el cfg algunas cosas de las que no tenía. FPS limitadas a 30. Estoy seguro que el rendimiento ha mejorado, sin embargo, creo que nHancer trabaja mejor el Antialiasing y el filtrado. Lo he notado en algunas líneas muy finas en los instrumentos de la Piper Cub de A2A, pero poco más. También puedo apreciar un barrido vertical cuando desplazo la vista con el track-IR. Probaré con vSync On, a ver que tal.

 

En plataforma del Barajas de Aerosoft consigo unos 25fps con el 737 De Wilco. Tendria que provar un vuelo en final que es cuando va peor, pero creo que hay una mejora apreciable.

 

No está mal, teniendo en cuenta que Barajas tiene algo que no le hace ir tan bien como otros aeropuertos similares.

 

Como FSX supongo que se programó hace unos añitos las targetas no serian tan potentes y el BufferPools se hacia necesario, pero conforme van siendo mas potentes se puede desactivar esta opción quitando una carga para la CPU, así tiene mas tiempo para otras tareas.

 

Exacto

[nOkEm]

Oro gran post NOA, gracias.

 

Casualmente tras formatear el disco duro llevo un par de días instalando y optimizando FSX asi que ya comentaré si noto mejoras.

[iceberg]

Hola compañeros. Donde esta esta la instrucción UsePools ya que dentro de fsx.cfg de FSX no la encuentro.

 

Un saludo.

[rush]

Hola compañeros. Donde esta esta la instrucción UsePools ya que dentro de fsx.cfg de FSX no la encuentro.

 

Un saludo.

 

La tines que añadir tu.

 

Busca la sección [bufferPools] y le añades debajo el UsePools=0

Si no tienes la sección [bufferPools] la añades tu y debajo el UsePools=0

[NOA]

Puedes escribirla tú.

 

[buferpools]

 

UsePools=0

 

Por ejemplo, al principio de tu cfg

 

Edito: sorry rush!

Edited April 8, 2010 by NOA

[iceberg]

Gracias compañeros.

 

Un saludo.

[nOkEm]

Bueno, me quedan muchas cosas por afinar y hacer, pero la primera impresión es que la ganancia de frames es evidente y también que muchas de las cosas que antes daba por sentado que mejoraban el rendimiento de FSX han resultado ser falsas.

 

Sigo teniendo problemas con los blurries y el tráfico AI mata la CPU, por lo que lo tengo puesto a cero. Todo esto sin el OC, es decir a 2.66 Mhz. A ver si me llega la memoria nueva y le vuelvo a hacer el OC...

 

Ya os iré comentando más cosas que vayan saliendo, pero desde luego Jesús Altuve ha hecho un grandísimo trabajo, y muchas gracias NOA también por hacernoslo llegar.

Edited April 9, 2010 by nOkEm

[nOkEm]

Por cierto, una pregunta. Al añadir el valor de MAX_TEXTURE_DATA ME HA SALIDO 91.8 ---> [9*(9*34)]/30. Creo que la operación está bien hecha, pero ¿pongo diréctamente ese valor o lo reondeo a 91 ó 92?

[NOA]

Por cierto, una pregunta. Al añadir el valor de MAX_TEXTURE_DATA ME HA SALIDO 91.8 ---> [9*(9*34)]/30. Creo que la operación está bien hecha, pero ¿pongo diréctamente ese valor o lo reondeo a 91 ó 92?

 

Ten en cuenta que TextureMaxLoad no es el mismo parámetro que TEXTURE_MAX_LOAD. El primero está en la sección [DISPLAY] y el segundo en la sección [GRAPHICS]. Por ejemplo:

 

[GRAPHICS]

 

TEXTURE_MAX_LOAD=1024

 

[DISPLAY]

 

TextureMaxLoad=9

 

 

TEXTURE_BANDWITH_MULTIPLIER es un multiplicador (120 por ejemplo)

 

 

Por tanto, si tienes los FPS limitados a 30

 

[1024*(9*120)]/30=36864

 

El resultado es la cantidad de datos en bytes que el gestor de texturas maneja cuando dibuja cada frame. Realmente, el parámetro es un limitador que te permitiría tener un control fino de las cosas. Pero pienso que te llevará tiempo averiguar cual es el multiplicador que mejor va, puede ser 120, 1000, 1500, ...

 

Yo no lo uso.

 

Por cierto, ¿alguien con un Q6600 quiere probar?

 

[JOBSCHEDULER]

AffinityMask=14

[bufferPools]

UsePools=0 // Use 0 or 1 if you experience crashes (if ENABLED PoolSize defaults to 4000000 bytes, 4 MB)

 

[Display]

TEXTURE_BANDWIDTH_MULT=40

TextureMaxLoad=9 // new variable, 9 is good

UPPER_FRAMERATE_LIMIT=0

WideViewAspect=True

RUNWAY_LIGHTS_SURFACE_SCALAR=0.7 //scales edge,center,end,touchdown,runways

RUNWAY_LIGHTS_VASI_SCALAR=0.6 //scales VASI lights)

RUNWAY_LIGHTS_APPROACH_SCALAR=0.5 //scales approach light bars

RUNWAY_LIGHTS_STROBE_SCALAR=0.5 //scales RAILs and ODALs)

 

Q6600@3.2, 4GB PC800 RAM, 9600GT 512MB, WinXP32

 

FPS limiter at 24. Road traffic=0.

 

Very smoooth...

[rush]

Yo tengo un Q6600 y he puesto el AffinityMask como dice, no se si da alguna mejora o no porque también le he puesto lo de BufferPools.

[gonvise]

Aunque no he hecho caso respecto a lo del AA, AF y Vsync (dejarlo que lo controle FSX), ya que:

 

1. Con el trackir, si no pongo el vsync con el panel de control nvidia, sale una linea muy molesta al mover la vista.

2. El AF del FSX es bastante peor que el de la tarjeta (este último a 16x). Solo hay que mirar el mar en la lejanía, así que tempoco paso por ahí.

3. Y ya puestos a que lo anterior lo dejo que lo controle la tarjeta, pues que controle también el AA.

 

... Tan solo con el BP=0 y el affinity a 14 (Tengo Q6600), la mejoría es notable. Tengo los FPS ilimitados en FSX y limitados a 30 con el fps limiter. En escenarios FTX, por ejemplo YPEC, al girar la vista con el trackir va mas fluido que nunca... tengo que probar con mas tiempo en escenarios muy complejos tipo barajas, en los que tengo muy controlados los fps en determinadas circunstancias, aver que tal van.

Edited April 9, 2010 by gonvise

[nOkEm]

He rectificado lo que me apuntas NOA, y no se si son las ganas de que sea así, pero sí que noto una ligera mejora en los frames.

 

He hecho varias pruebas ya y bueno, a falta de meterme en un aeropuerto tipo Aerosoft con otro comeframes como el Maddog 2008 (en las pruebas estáticas ha ido bien), en mi opinión la mejora de frames es apreciable. A parte de que las tengo limitadas a 30 no es que vayas a 250, pero la verdad es que ahora el FSX es mucho más volable. Eso sí... olvidándome del AI Traffic.

 

La tarjeta de crédito está temblando ya...

[alfsoft]

Ostras, siempre he creído que los cambios en el .cfg no eran muy sustanciales, la verdad.

Pero he cambiado el BP=0 y el affinity=14 y se me han quedado los ojos como platos. He mejorado el rendimiento bastante.

A falta de pruebas más objetivas.... un 10 para el cambio. Pero si parece que he cambiado de Hard y solo he modificado dos lineas.....

Totalmente recomendable. Al menos para mí, que tengo un Q6600.

 

Un saludo y gracias NOA.