Jump to content

Fsx Sp1 New Tweaks


zaar69

Recommended Posts

TRADUCCIÓN COMPLETADA!! ;)

 

I just thought I'd fire these over here from Phil's blog.

 

There is a tweak to control scheduling of threads on cores.

 

 

 

It is not recommended to change these settings unless you have a performance reduction and/or maxed out CPU loads in the PerfMonitor. The tweak is

 

Edit:Fixed a typo here

[JOBSCHEDULER]

AffinityMask=n

where

n num of cores scheduled

1 = 1 core 0001

3 = 2 cores 0011

7 = 3 cores 0111

15= 4 cores 1111

 

 

Este es un apaño pora el control de programación de tareas en los núcleos

No es recomendable cambiar estos ajustes a menos que tengas una reducción de rendimiento y/o cargas de CPU maximizadas (¿?) en el PerfMonitor. El truco es:

 

Edito: corregida una errata aquí

[JOBSCHEDULER]

AffinityMask=n

donde

n numero de núcleos programados

1 = 1 core 0001

3 = 2 cores 0011

7 = 3 cores 0111

15= 4 cores 1111

----

 

 

 

There is additional code to reduce blurries. If you get random texture tiles that appear in a solid color this may help.

 

 

 

In some cases, the textures generated from this code can get throttled and will be timed out. The time out config value is

 

[TERRAIN]

 

SWAP_WAIT_TIMEOUT=<number_of_frames>

 

The default is 30 frames.

 

Otro código más para reducir los blurries. Si tomas azulejos (cada porción de terreno, los famosos cuadraditos que vemos en altura) de textura aleatorios que aparecen en un color sólido quizás esto ayude.

En algunos casos, las texturas generadas por este código pueden estar aceleradas y ser timed out (¿descartadas?). El valor de configuración de time out es:

 

[TERRAIN]

 

SWAP_WAIT_TIMEOUT=<numero_de_frames>

 

Por defecto 30 frames.

--

 

 

 

There are new config items to control VSYNC for fullscreen and windowed separately

 

 

 

[DISPLAY]

 

ForceFullScreenVSync, default is TRUE

 

ForceVSync, default is FALSE

 

 

 

We have seen cases where when VSYNC is on in fullscreen causing major fluctuations in frame rate especially when setting the rate limiter above 45. If you run into widely fluctuating FPS in fullscreen when aiming for above 45, try turning VSYNC off or reducing below 40.

 

Hay nuevos puntos de configuración para controlar el VSYNC (¿Sincronización de V(algo)?) independientemente para pantalla completa o maximizado

 

[DISPLAY]

 

ForceFullScreenVSync, default is TRUE

 

ForceVSync, default is FALSE

 

Hemos visto casos en los que cuando VSYNC está activado en pantalla completa causando graves fluctuaciones en los frames por segundo, especialmente cuando el ajuste de limitación de frames es superior a 45. Si te rula normalmente con fluctuacioens de FPS en pantalla completa cuando tiene máximo por encima de 45, prueba desconectando VSYNC o reducir los FPS por debajo de 40.

 

--

 

 

 

For the dusk/dawn textures some people feel, subjectively, the result is too dark or too light. There are 2 items that allow the transition time to be changed:

 

[GRAPHICS]

 

DAY_THRESHOLD

 

NIGHT_THRESHOLD

 

 

 

acceptible values are 0 to 65535.

 

Defaults:

 

DAY: 32768

 

NIGHT: 4096

 

 

 

These represent the amount of 'ambient' light at the ends of the day/night blend threshold. Zero is perfect dark, 65535 is full day sun at noon in the summer.

 

Para las texturas de amanecer/atardecer, a alguna gente le parece, subjetivamente, que el resultado es demasiado oscuro o demasiado claro. Tenemos dos cosas que permiten cambiar el intervalo de transición

 

[GRAPHICS]

 

DAY_THRESHOLD

 

NIGHT_THRESHOLD

 

 

 

el rango de valores está entre 0 y 65535.

 

Por defecto:

 

DAY: 32768

 

NIGHT: 4096

--

 

 

 

There is a tweak that helps with panel updates, especially the glass panel. If you use the glass panel and notice very slow updates. There is a 2 part tweak:

 

[GRAPHICS]

 

DirtyRegionUpdateLimit=<integer>

 

 

By default this UINT32_MAX (i.e. four billion or so) so it has no effect.

 

Setting it to zero effectively forces full texture updates instead.

 

Setting it to smaller numbers (1-1000) might improve performance if the card is slow at full texture updates and does not have a high overhead for incremental updates.

 

 

[GRAPHICS]

 

MergeDirtyRegionUpdates=<0/1>

 

 

 

By default this is 0 (i.e. disabled) so it has no effect.

 

Setting it to 1 (enabled) causes us to merge all of the dirty rects into a single large dirty rect. This means that we will only do a single partial texture update.

 

 

 

This may work well if the card is slow at full texture updates and does have high overhead for incremental updates.

 

Este es un truco que ahuda con los refrescos del panel, especialmente en los paneles de cristal. Si usas paneles acristalados y notas un refresco muy lento (prueba a modificar estos parámetros).

Este es un truqui en 2 partes:

 

[GRAPHICS]

 

DirtyRegionUpdateLimit=<integer*> (*enteros, sus negativos y el cero)

 

Por defecto este UINT32_MAX (por ejemplo cuatro mil millones o más) no tiene ningún efecto.

 

En cambio, poniéndolo a 0, fuerza un refresco completo de texturas más efectivo.

 

Valores más pequeños (1-1000) podría mejorar el rendimiento si la tarjeta (de vídeo) va lenta con refresco completo, y no tiene una gran capacidad para refrescos incrementales (¿?)

 

[GRAPHICS]

 

MergeDirtyRegionUpdates=<0/1>

 

Por defecto está en 0 (desconectado) por lo que no tiene ningún efecto

Cambiándolo a 1 (conectado) nos causa una fusión de todos las rects (¿?) sucias en una sola y gran rect (¿?) sucia. ( :blink: ) Esto significa que solo haremos un refresco parcial de una textura.

 

Podría funcionar bien si la tarjeta va lenta con refresco completo de texturas y tiene una alta capacidad para refrescos incrementales (¿?)

 

---

 

 

 

There is a scenery tweak to eliminate very small objects, which can reduce render time.

 

 

 

[sCENERY]

 

SmallPartRejectRadius=<pixels>

 

 

 

Basically this culls out small model parts (e.g. air conditioners on roofs of buildings, aircraft doors) if their radius would occupy less than the specified number of screen pixels.

 

 

 

The default is 1.0 (i.e. 1 pixel). 2, and 4 are the next 2 settings we advise. Can significantly improve performance but may cause "popping" of small objects

 

Acouple of other things to note, which hve been mentioned but worth bringing them together.

 

Texture_bandwidth= Setting a higher value pre SP1 did help with blurries, this can now have a detremental effect using SP1. Mango and I managed to get find a nice happy medium by setting the value to 40. This helps eliminating stutters.

 

FIBER_FRAME_TIME_FRACTION= This has a smaller effect on ground texture loading now as these processes have been moved onto the second core.

Again lifted from PT's blog.

So here is an idea. Occasionally I will publish information on various "tweaks" to the product and what they do. A "Tweak of the week" if you will.

 

 

 

So let's start with the mysterious sounding FIBER_FRAME_TIME_FRACTION.

 

 

 

There are page after page of google, I mean livesearch, hits on this term. Obviously people have been talking. That's probably due to the post Adam, our resident terrain guru, made here.

 

 

 

Now we hope people don't hurt themselves with settings that deeply affect the engine like this, because there is always the possibility of misuse. Usually that is outweighed by the value of being informed, and the great thing about the community is sometimes interesting questions do crop up out of people using these settings.

 

Este truqui de escenarios sirve para eliminar objetos demasiado pequeños, que pueden reducir el tiempo de renderizado.

 

[sCENERY]

 

SmallPartRejectRadius=<pixels>

 

Básicamente esto selecciona partes pequeñas de los modelos (por ejemplo, aire acondicionado en los tejados de edificios, puertas de aviones) si su radio ocupa menos de los pixels especificados.

 

El valor por defecto es 1.0 (por ejemplo 1 pixel). 2, y 4 son los dos siguiente parámetros que recomendamos. Pueden mejorar el rendimiento significativamente, pero podrían causar ¿saltos? de objetos pequeños.

 

Un par de cosas más que señalar, que se han mencionado pero que merece la pena poner juntas.

 

Texture_bandwidth= Ajustando un valor mayor antes del SP1 ayudó con los blurries, pero ahora puede ir en detrimento usando el SP1. Mango y yo probamos para encontrar un buen valor ajustandolo a 40. Esto ayuda eliminando los tartamudeos (¿saltos?)

 

FIBER_FRAME_TIME_FRACTION= Este tiene un efecto menor sobre la carga de las texturas de tierra. Ahora esos procesos han sido movidos sobre el segundo core. De nuevo, fusilado desde el blog de PT.

 

Ahí va una idea. Ocasionalmente publicaré información sobre varios trucos para el FS y lo que hacen. Un "Truco de la semana, si quereis llamarlo.

 

Así que vamos a empezar con el misterioso sondeo FIBER_FRAME_TIME_FRACTION.

 

Hay páginas y páginas en google, y quiero decir muchas, resultados sobre este término. Obviamente, la peña ha estado hablando sobre ello. Probablemente debido al post de Adam, nuestro residente gurú del terrenos, posteado aquí.

 

Ahora esperamos que la gente no se haga daño (en los pc's) con los ajustes que afectan profundamente al motor (gráfico) como este, porque siempre existe la posibilidad de un uso incorrecto. Normalmente esto pesa más por el valor de ser informado y lo grande de la comunidad son las, a veces, interesantes cuestiones ¿que cultivan? (¿?) a la peña usando estos ajustes.

 

Christian Buchner, author of TileProxy, recommended that Win64 users of TileProxy set FIBER_FRAME_TIME_FRACTION to 2.0 when the base value is .33. A lot of speculation about what that would be doing cropped up.

 

 

Adam Szofran, our resident terrain guru, gave out the skinny for everyone. I posted it first on avsim.com, but wanted to repost it here so the information didn't get lost.

 

 

 

Here are 2 quotes from Adam, verbatim:

 

"

 

FIBER_FRAME_TIME_FRACTION determines the maximum amount of time per frame that we will run fiber jobs on the primary thread. We measure how long it took to simulate and render and then multiply that time by FIBER_FRAME_TIME_FRACTION to determine how long to run the fibers. For example, if it took 10 milliseconds to simulate and render and FIBER_FRAME_TIME_FRACTION was set to the default value of 0.33, then we would allow the fibers on the primary thread to run for up to 10 * 0.33 = 3.3 milliseconds. For fraction values of 1.0 and 2.0, the time given to fibers would be 10 milliseconds and 20 milliseconds, respectively.

 

 

 

The operation of FIBER_FRAME_TIME_FRACTION on single core machines has not changed since RTM.

 

 

 

On multi-core machines in SP1, we moved many fiber jobs off of the primary thread and onto secondary threads. Since FIBER_FRAME_TIME_FRACTION only affects scheduling of jobs on the primary thread, it will have less of an impact on the performance of Flight Sim on multi-core machines. In fact, we moved so many jobs off of the primary thread that there probably isn't enough fiber work left to soak up the full time allowed by the default value of 0.33.

 

 

 

Therefore, on multi-core machines, there's very little reason to tweak the fraction because it really only impacts performance of single core machines.

 

"

 

 

 

and

 

 

 

"

 

Please emphasize the pointlessness of tweaking this value on multi-core machines.

 

 

 

Further, setting it to values greater than the default value on single-core machines can increase frame rate volatility because it increases the amount of time we *might* allocate to fibers if there is adequate work waiting in the queue. When the queue is full, we'll allocate the full amount of time to fibers but when the queue is empty, fibers get no time because there is no work to do. If the rate of new jobs entering the fiber queue is bursty and the full time allowed for fibers is large, then you can imagine how this would increase volatility.

 

 

 

If people feel like the fibers aren't getting adequate resources, they would be better off leaving the fiber fraction alone and just lowering the frame rate limit slider, which helps divert more CPU time to primary thread fibers without increasing volatility.

 

"

 

I'd take those words as golden.

 

 

 

He also wanted me to mention that TileProxy is using a FS9 path, basically because it is the only path available for the style of source data involved. However, that path requires massive amounts of file I/O and because of the huge number of files involved it completely blows the texture cache used by the terrain texture compositor. So there is a limit to how efficient that will ever be until we rework the architecture to be more accommodating.

 

 

 

Another question was does photo-scenery benefit from the multi-core work, and Adams' answer was:

 

"

 

Photo scenery loading, like loading of all terrain data, benefits greatly from our multi-core work. The more cores the better.

 

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

 

TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=

 

TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=

 

This is still valid with a maximum value of 6000

 

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

After looking round several forums it seems simmer are not taking note of one important thing regarding SP1. It's been mentioned so many times but here we go again.

To guarantee the best results using SP1 Aces request that you install on a FRESH copy of FSX, or RTM as it's celled (This is your DVD version)

Again information supplied from Phil's blog

 

FSX SP1:Preparing to Install

 

Setting up for SP1

 

 

 

SP1 needs a pristine RTM.

 

 

 

That includes no add-ons. Many 3rd party add-ons can cause crashes, especially if they load dlls. In that case they will likely need to be refreshed.

 

 

 

If you really don't want to do this, then perhaps you can consider running FSX from the command line using

 

 

 

>fsx /ManualLoad

 

 

 

This provides a dialog for every dll or xml exe that gets loaded so you track down who is the offender if there is an issue.

 

 

 

However, most people don't know how to run FSX from the command line, thus it's safest to uninstall all add-ons.

 

 

 

If you have performed any file modification tweaks, you will need to uninstall or repair RTM.

 

 

 

Then install SP1.

 

 

 

Then start installing your add-ons 1 by 1.

 

 

 

Note:

 

Uninstalling RTM deletes ALL content of -

C:\Documents and Settings\All Users\Application Data\Microsoft\FSX

C:\Documents and Settings\USERNAME\Application Data\Microsoft\FSX

 

That is EVERY subfolder & file in that branch.

 

If you don't back up and save, you will loose config files, flights, logbook, and rewards.

 

Two files to consider saving:

 

Logbook.bin &

GrantedRewards.bin

 

 

 

FSInsider.com will have an article live that discusses the uninstall scenario in more depth, please take the time to read it.

 

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

 

I'll keep adding things as tweaks become available but to be honest, I think SP! rock as it is lol !!!!!!

 

Christian Buchner (como el filtro :lol::lol: ), autor de TileProxy, recomienda que los usuarios que usen Win64 ajusten FIBER_FRAME_TIME_FRACTION a 2.0 cuando el valor base es .33. Salieron montones de especulaciones acerca de lo que ese ajuste estaría haciendo

 

Adam Szofran, nuestro gurú de terrenos, soltó el flaco (¿dio los detalles?) para todos. Lo he posteado antes en avsim, pero he querido repostearlo aquí para que la información no se pierda.

 

Aquí van dos citas de Adam, textualmente:

"FIBER_FRAME_TIME_FRACTION determina el la máxima cantidad de tiempo por cada frame que correremos ¿trabajos de fibra? (debe ser algo de la gráfica que no sé traducir) sobre el primer hilo (referido a la fibra) Medimos cuánto tiempo tomó para simular y renderizar, entonces multiplica ese tiempo por FIBER_FRAME_TIME_FRACTION para determinar cuanto tiempo (empleará) para ejecutar las fibras. Por ejemplo, si tomó 10 ms para simular y renderizar, y FIBER_FRAME_TIME_FRACTION está ajustado al valor por defecto de 0.33, entonces permitiríamos a ejecutarse a las fribras del primer hilo hasta 10*.33=3.3 milisegundos. Para valores fraccion de 1.0 y 2.0, el tiempo dado a las fibras sería de 10 ms y 20 ms respectivamente.

 

La operación de FIBER_FRAME_TIME_FRACTION sobre equipos de un sólo núcleo no han cambiado desde RTM (¿?).

 

Por tanto, sobre máquinas multi-núcleo, hay una razón muy pequeña para modificar la fracción, porque realmente solo tiene impacto sobre el rendimiento de máquinas mono-núcleo."

 

y

 

"Por favor, enfatizar lo absurdo de modificar este parámetro en máquinas multi-core.

 

Más allá, ajustándolo a valores mayores que por defecto en máquinas mono-core, puede incrementar la volatibilidad de los FPS porque incrementa la cantidad de tiempo que *podríamos* destinar a las fibras si hay el trabajo adecuado esperando en la cola. Cuando la cola está completa, destinaremos la cantidad total de tiempo a las fibras pero cuando la cola está vacía, las fibras no tendrán timepo porque no hay trabajo que hacer. Si la proporción de nuevos trabajos entrando en la cola de la fibra es brutal y el tiempo total permitido a las fibras es grande, entonces puedes imaginar como incrementará la volatibilidad.

 

Si a la gente le parece que las fibras no están tomaando los recursos adecuados, podría ser mejor dejando solamente la fracción de fibra y bajar un poco el deslizador de FPS, que ayudará a desviar más tiempo de CPU a los fibras de hilo primario sin incrementar la volatibilidad."

 

Guardo estas letras como oro en paño.

 

Él también me pidió que mencionara que TileProxy está usando la ruta de FS9, básicamente porque es la única ruta disponible para el tipo de datos de origen involucrados. Sin embargo, esa ruta requiere grandes cantidades de Entradas/Salidas de archivos y debido a la enorme cantidad de archivos involucrados, revienta completamente la caché de texturas usadas por el compositor de texturas de terreno. Por lo que existe un límite para cuán eficiente será mientras re-trabajamos (¿?) la arquitectura para estar más cómodos.

 

Otra pregunta fué ¿benefician los foto-escenarios desde el trabajo en multi-núcleo?, y la respuesta de Adam fue:

 

"La carga de foto-escenarios, como la carga de todos los datos de terreno, se beneficia gratamente desde el trabajo en multi-núcleo. Cuantos más núcleos, mejor.

 

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

TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=

 

TERRAIN_MAX_AUTOGEN_BUIDINGS_PER_CELL=

 

Esto es todavía válido con un valor máximo de 6000.

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

" (en el texto no lo especifica, pero creo que la cita acaba aquí)

 

Después de mirar alrededor de varios foros, parece que los simuleros no toman nota respecto al SP1. Está siendo mencionado muchas veces pero aquí vamos de nuevo.

Para garantizar los mejores resultados usando SP1, Aces requiere que instales sobre una copia FRESCA (instalación limpia) de FSX, o RTM (¿un modo de recuperación del sistema?), como esté celdado (¿? algún tipo de soporte o disposición de archivos?) (Esta es tu versión DVD)

 

De nuevo, info suministrada del blog de Phil

FSX SP1: Preparando para instalar.

 

Ajustando para SP1

 

SP1 necesita un RTM original

 

Esto no incluye añadidos. Algunos añadidos de terceras partes (comunidad libre?) pueden provocar cuelgues, especialmente si cargan dll's. En ese caso necesitarán ser refrescadas (¿reinstaladas?)

 

Si realmente no quieres hacerlos, entonces tal vez puedas considerar ejecutar FSX desde la linea de comandos usando

 

>fsx /ManualLoad

 

Esto provee un dialogo para todas las dll's o xml ejecutadas que son cargadas para que puedas interrumpir la que está jodiendo la marrana si hay algún problema.

 

Sin embargo, mucha gente no conoce la forma de ejecutar FSX desde la línea de comandos, que es la manera más segura de desinstalar todos los añadidos.

Si has efectuado cualquier truqui de modificación de archivos, necesitarás desinstalar o reparar la RTM (dichosa RTM).

 

Entonces instala SP1

 

Luego comienza a instalar tus añadidos de uno en uno.

 

Nota:

 

Desinstalando RTM (¿copia ya instalada?) borra TODO el contenido de:

C:\Documents and Settings\All Users\Application Data\Microsoft\FSX

C:\Documents and Settings\TUUSUARIO\Application Data\Microsoft\FSX

 

Esto ocurre en TODAS las subcarpetas y archivos de esa rama

 

Si no haces copia de seguridad y la guardas, perderás archivos de configuración, vuelos, logbook y recompensas.

 

Dos archivos para considerar salvarlos:

 

Logbook.bin y

GrantedRewards.bin

 

FSInsider.com tendrá un artículo vivo (¿reciente?) que discute la desisntalación de escenarios en más profundiad, por favor, tomate el tiempo para leerlo.

---------

Mantendré añadiendo cosas y trucos según salgan, pero para ser honesto, creo que SP1 se balancea como es (¿?, es una mierda pinchada en un palo?)

 

Bueno, traducción terminada :heat::heat: , aunque algunos conceptos técnicos no he sabido darles la traducción que merecen por desconocer exactamente lo que significan, así que si alguien puede meter mano ahí... ;)

 

Mi inglés tampoco es que vaya muy allá, así que no os fieis mucho de lo que digo :D

 

Un saludo!! :P

Edited by TzT
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

Some pretty cookies are used in this website