FAQ - [FSX] Configuration poussée (AVSIM)

Avatar de l’utilisateur
Karel TESSARO
Administrateur - Site Admin
Messages : 2140
Inscription : 12 avr. 2007, 12:53
Prénom / Nom : Karel TESSARO

FAQ - [FSX] Configuration poussée (AVSIM)

Message par Karel TESSARO »

Voici un texte extrêmement intéressant issu de la ML Cyberavia, lui même issu du forum AVSIM lui même issu de Jesus Altuve. J'espère n'avoir oublié aucun des intermédiaires... C'est en français et c'est compréhensible. Technique mais compréhensible.

http://forum.avsim.net/topic/282217-tra ... try1751033
Voici la traduction du message <a href="http://forums1.avsim.net/index.php?showtopic=281538" target="_blank">The BP=0 conclusions, FSX improvement by Jesus Altuve aka "Bojote"</a>.
J'espère ne pas avoir trop déformé ses propos.

Jean-Paul


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

Salut les pilotes

Voici la conclusion de plusieurs mois de recherches menées par Jesus Altuve et abordés dans le plus long fil de discussion de l'histoire d'Avsim :--)
Pour son travail phénoménal et son dévouement envers notre communauté, l'équipe d'Avsim tient à remercier chaleureusement son auteur.
Ce guide n'est pas un document à la « fais comme-ci, fais comme-ca » mais une explication détaillée de chaque concept ou élément, le rendant compréhensible même pour les non-spécialistes.
Ces derniers mois, Jesus a également passé des heures et des heures à expliquer/former des utilisateurs qui pourront prendre la relève si jamais vous avez des questions, laissant un peu de répit à l'auteur. C'est pour cela que nous verrouillons ce fil en même temps que le fil BP=0 et que nous vous invitons à utiliser normalement le forum pour toute question ou information.
<b>Si jamais vous copiez ces lignes ailleurs sur la toile, nous vous demandons de mettre un lien vers le document original et de donner à l'auteur, Jesus Altuve, tout le crédit qu'il mérite.</b>

Merci d'avance.

David

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


Attention
Ce que vous êtes sur le point de lire PEUT PRODUIRE DES RESULTATS INDESIRABLES en fonction de votre configuration ou de la position de vos curseurs. Ce n'est donc pas une solution à TOUS les problèmes mais simplement une astuce non documentée pour FSX qui peut vous faire gagner 30% de performances.

Avant que je ne commence, un peu d'historique. J'utilise cette astuce depuis plus d'un an. Deuxièmement, j'ai passé pas mal de temps à essayer de comprendre l'astuce, son but et pourquoi il apporte une telle augmentation des performances. Donc s'il vous plait, N'ESSAYEZ PAS si votre configuration actuelle n'est pas parfaitement stable ou si vous ne COMPRENEZ pas ce j'essayerai de vous expliquer dans les lignes qui vont suivre.

Voyons d'abord comment des programmes tels que FSX fonctionnent (je ne vais pas rentrer dans les détails). Lorsque vous « volez » dans FSX, chaque image est comme une photo nécessitant à CHAQUE FOIS que des objets et des textures y soient intégrés. Lorsque vous mettez bout à bout et en succession rapide ces « photos », par exemple 25 photos par seconde (ndt : 25 frames per second ? 25 FPS) , vous obtenez une impression de mouvement.

Dans FSX, le « rendu » ou « dessin » de ces objets se fait image par image. Plus le nombre d'images par seconde augmente, plus l'application devra « dessiner » d'objets. C'est le processeur qui envoie l'instruction de ce qui est à afficher à votre carte vidéo. Chaque instruction est mise en file d'attente dans une mémoire tampon (ndt : buffer). FSX détermine la limite de remplissage de cette mémoire puis transfère le contenu vers une autre mémoire appelée « Command ring buffer ».

Le but de cette première mémoire tampon est de synchroniser le flux d'instructions entre CPU et GPU. Si cette mémoire tampon n'existait pas, vous pourriez, dans certaines circonstances, TOTALEMENT PLANTER FSX, la « Command ring buffer », à partir de laquelle la carte vidéo reçoit ses instructions, étant totalement surchargée.

Si la carte vidéo n'est pas assez rapide pour traiter la quantité PHENOMENALE d'ordres (ndt : draw calls) envoyés par le CPU pour chaque image, alors le processus « décroche ». Décrocher veut dire que le CPU écrit plus rapidement dans la « Command ring buffer » que la carte vidéo n'est en mesure de traiter. La « Command ring buffer » ne peut contenir qu'un nombre fini d'instructions à la fois et si la carte vidéo ne la lit pas assez vite, les données y sont écrasées, provoquant des défauts d'affichage (le plus souvent des pointes surgissant de l'autogen).
Si vous comprenez ce qui précède, il faut également que vous compreniez que les mémoires tampon gérés par l'application (BufferPools) coutent de l'occupation processeur, particulièrement dans FSX où cette occupation est MASSIVE. Ce n'est pas forcément mauvais car c'est une mesure de sécurité empêchant le remplissage de la « Command ring » Les mémoires tampon gérées par l'application (BufferPools) sont comme des intermédiaires qui régulent le flot d'instructions pour ne pas surcharger la carte vidéo.

Alors pourquoi est ce que Microsoft a inclus une mémoire tampon gérée par l'application (également appelée Explicit Vertex Buffer) ? Ils l'ont fait afin que CHACUN puisse utiliser FSX quelque soit sa configuration. Alors NE BLAMEZ PAS MICROSOFT !! Ils ont fait le bon choix et ce n'est PAS un bug.

Alors, que se passe-t-il quand vous demandez à FSX de ne pas utiliser cette mémoire tampon et d'envoyer DIRECTEMENT au « Command Ring » pour être traité par la carte vidéo ? (pour les esprits chagrins, les instructions sont en fait envoyées à l'API D3D, mais je préfère donner des explications simples). Et bien, ce qui se passe c'est que FSX n'a plus besoin d'intermédiaires et qu'il n'a plus besoin de contrôler ni ce qu'il dessine ni quand il doit le faire. Il lui suffit de pomper un maximum d'instructions dans la carte vidéo, LIBERANT massivement des ressources qui pourront être utilisées pour votre vol !!! Maintenant vous comprenez pourquoi cette astuce est SI puissante mais également SI dangereuse pour la stabilité de votre machine. Il faut que vous soyez en mesure de savoir ce qui se passe dans votre machine. Il faut que vous connaissiez exactement les limites de votre GPU et c'est là que les choses deviennent intéressantes.


Comment pouvez-vous être sûr que votre carte vidéo est en pleine forme et est capable de tout traiter ? Rappelez-vous ... Il ne s'agit pas de puissance brute ... Il s'agit de la capacité du GPU à traiter les commandes plus rapidement que le CPU ne les envoie C'est comme une course et c'est le GPU qui doit être le plus rapide ! C'est particulièrement vrai pour les utilisateurs d'I7's overclockés @ 4.2 . Ne faites pas confiance aux utilitaires de mesure d'usage GPU qui ne montrent que la mémoire utilisée ... sans vous fournir d'informations sur le taux d'utilisation du «noyau» (système), utilise pour traiter les commandes dans la file d'attente .. Et s'il vous plaît, ne comparez pas FSX à Crysis ?, etc. Ce sont des jeux optimisés pour l'utilisation de shaders hardware programmables! Ils sont parfaitement équilibrés!

Donc, vous devrez commencer par oublier TOUT ce que vous avez appris au cours de ces 4 dernières années .. En particulier des choses comme

l'Antialiasing, mais seulement quand elle est contrôlée par nHancer
Le filtrage Anisotrope, encore une fois, seulement si elles est contrôlée par nHancer
VSync activé (c'est un tueur)
Plusieurs écrans (même en mode cloné)
L'utilitaire ENBSeries

Ce qui précède tue la capacité du GPU à traiter des commandes, mais pas la capacité à dessiner ou à afficher les objets donc si vous avez absolument besoin de ce qui précède, vous pouvez arrêter de lire dès maintenant ;) .

Si vous voulez essayer cette astuce, vous devrez commencer par laisser FSX gérer l'antialising et le filtrage anisotrope, vous devrez également débloquer le vSync, et n'utiliser qu'un seul écran. Vous pourrez ainsi utiliser votre carte Vidéo de façon optimale ... Surtout si vous avez une Nvidia (les ATI n'ont pas ce problème, mais on en reparlera plus tard).

Un petit aparté: l'ATI 5870 et la 285GTX d' NVidia sont toutes deux d'excellentes cartes ... mais elles ont des architectures complètement différentes. Les ATI ont beaucoup de minuscules processeurs pour les shaders mais ils sont lents, en face, les processeurs shader des nVidias sont bien moins nombreux, mais deux fois plus rapides... Comment cela affecte-t-il la capacité des cartes à traiter les instructions?

C'est à vous de décider: l'ATI a 1600 petits processeurs appelés «les processeurs shader". Plus en vous avez, meilleure sera la capacité de carte à faire du «multitâche» et du traitement de processus en parallèle. L'ATI lit la mémoire tampon du « Command ring » plus vite que n'importe quelle autre carte (même que la nouvelle NVidia GTX 480, également connue sous le nom de code Fermi). Avec une ATI vous pourriez être au nirvana si FSX envoyait toutes les instructions directement sans passer par le BufferPools .. Malheureusement, il y a un hic. Etant donné que les ATI ont des processeurs shader plus lents (ils fonctionnent qu'à 700 MHz, tout comme l'horloge de base). Les paysages détaillés, les nuages ou les avions complexes feront considérablement chuter vos FPS. Encore une fois, c'est à vous de décider ... Si vous ne pilotez que des avions par défaut, et que vous souhaitez mettre à fond CHAQUE CURSEUR, bloquer le vsync, utiliser nHancer, ENBSeries,... alors l'ATI est faite pour vous ! Il est impossible de la planter! J'ai pourtant essayé pendant 2 jours, avant de la renvoyer car avec elle baissait mes FPS de 6 images/seconde : inacceptable à mes yeux.

Nvidia, et plus particulièrement la GTX 285, a exactement 240 processeurs shader cadencés à 1476Mhz (et certaines cartes peuvent être overclockées), cette carte est un monstre ... et même si l'ATI (en vitesse pure) est plus rapide, la nVidia peut générer une scène complexe bien plus rapidement (surtout sur des élément dépendant des shaders comme les nuages, l'eau, les bâtiments, etc), de sorte que le CPU n'a pas à attendre une scène soit générée. Rappelez-vous, plus vite la carte génèrera une scène, plus vite le processeur pourra en « commander » d'autres ! Vous voyez, il doit y avoir un «équilibre». Rappelez-vous que tout système complexe sera limitée par la vitesse de son composant le plus lent. Maintenant, retournons à nos comparaisons entre cartes vidéo : L'inconvénient des nVidias est leur lenteur à lire les instructions de la mémoire tampon « Command ring » et elles peuvent décrocher si le processeur est rapide et l'autogen trop élevé (ce qui remplit le Command ring plus rapidement, surtout après le SP2, le nombre d'objets à créer par image ayant énormément augmenté).

Il est donc primordial de bloquer vos FPS à 25 ou 30 et de baisser l'autogen. (en plus des mesures déjà mentionnées : Vsync Off, un seul écran, pas d'ENBSeries, l'AA et l'AF contrôlés par l'application). mais ne vous inquiétez pas .. Très prochainement, la GTX 480 va changer la donne:) Il a 480 processeurs shader:) même si c'est moins que l'ATI, ce sera assez pour atteindre le nirvana de la simulation de vol, transfigurant FSX. Le rêve sera enfin accessible : fluide avec tous les curseurs à fond (sauf le trafic routier), l'eau à 2.0 Max (qui est un tueur) ou l'effet Bloom (un autre tueur de fps), mais vous pourrez toujours avoir pas mal de trafic AI tout en atteignant les 20-25 FPS, même dans les situations les plus difficiles. C'est la bonne nouvelle.

Alors ... Si vous COMPRENEZ les informations ci-dessus et que vous êtes assez compétent pour modifier votre fichier fsx.cfg, alors allez-y .. Sinon, n'essayez même pas, et s'il vous plaît, ne m'envoyez pas de messages privés car je n'y répondrai pas. Je donne ces informations pour la communauté toute entière.

Les réglages que vous devez ajouter au fichier fsx.cfg sont les suivants:

[BufferPools]
UsePools=0
(À noter que PoolSize est ignoré si UsePools est égal à 0. Utilisez 1 si FSX plante)
Lorsque vous voyez des « interrupteurs »» (1 ou 0), cela signifie ON ou OFF - UsePools utilise cette valeur ON / OFF (1 ou 0)
PoolSize a comme valeur une taille (en octets) Si vous «désactivez» les Pools, vous obtiendrez plus de performance, mais aussi, de l'instabilité si vous n'avez pas un «équilibre» entre les composants et des curseurs
En cas d'instabilité, il vous suffit d'utiliser les Pools en mettant la valeur UsePools à 1 et en ajustant la taille du PoolSize. SOYEZ PRUDENTS et oubliez tout ce qu'on a pu vous raconter jusqu'à présent. NON, Il n'utilise pas de mémoire vidéo, POINT. Il utilise la mémoire système, parce que c'est un type spécial de buffer appelé Explicit Vertex Buffer qui N'UTILISE PAS LA MEMOIRE VIDEO à moins d'avoir un interrupteur (ndt : « Flag ») très particulier (qu'il n'a pas - plus d'infos ici: <a href="http://msdn.microsoft.com/en-us/library/ff539490.aspx)" target="_blank">http://msdn.microsoft.com/en-us/library/ff539490.aspx)</a>
Testez le vous-mêmes : augmentez la taille du Poolsize et vous verrez que le taille du processus fsx.exe augmente en même temps.

[GRAPHICS]
HIGHMEMFIX=1
Corrige les erreurs d'adressage de texture des modes WDDM1.0 et 1,1 si vous utilisez beaucoup de mémoire vidéo
Le HIGHMEMFIX = 1 corrige un bug dans le moteur de FSX sur la façon dont il gère les modes d'adressage de texture (Wrap, Clamp) et les « initial render states » des shaders à seule passe. Cette astuce évite la disparition des textures de batiments et de cockpits ! Ce «bug» apparaît lorsqu'il y a une situation d'utilisation élevée de la mémoire vidéo. C'est mon cadeau à cette communauté qui, au fil des ans, m'a tant donné.


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

FACULTATIF

[GRAPHICS]
SHADER_CACHE_VERSION = 1 / / incrémentez ce nombre à CHAQUE reconstruction du fsx.cfg (il reconstruit tout simplement le cache des shaders)


[DISPLAY]
TextureMaxLoad = 9 / / Attention. Peut provoquer des saccades sur les petites configurations ! Utilisez seulement des multiples de 3 (3, 6, 9, etc) parfait pour les scènes photoréalistes et PNW

TextureMaxLoad : comment déterminer la valeur optimale (Merci à Steve Lacey : <a href="http://www.steve-lacey.com/blogarchives ... ries.shtml)" target="_blank">http://www.steve-lacey.com/blogarchives ... ries.shtml)</a>

Si UPPER_FRAMERATE_LIMIT (ndt : nombre auquel sont bloqués les fps) existe, alors:
MAX_TEXTURE_DATA = (TEXTURE_MAX_LOAD * (TextureMaxLoad * TEXTURE_BANDWIDTH_MULTIPLIER)) / UPPER_FRAMERATE_LIMIT

If UPPER_FRAMERATE_LIMIT n'existe pas (UNLIMITED FRAMES) (ndt : fps sur illimités) alors:
MAX_TEXTURE_DATA = TextureMaxLoad * TEXTURE_MAX_LOAD

Comme vous pouvez le voir ci dessus, TEXTURE_BANDWIDTH_MULTIPLIER n'est qu'un coefficient multiplicateur. Bien sûr, le modifier change des choses mais si vos FPS sont en ILLIMITES, ça ne sert A RIEN, donc vous faites mieux de jouer directement avec la valeur TextureMaxLoad. Soyez prudents, le résultat de la formule (MAX_TEXTURE_DATA) correspond au nombre MAXIMUM de bytes que le GESTIONNAIRE DE TEXTURES est autorisé à envoyer par image. Si cette valeur en bytes (MAX_TEXTURE_DATA) est TROP ELEVEE, vous surchargerez votre GPU (et vous provoquerez une saccade). C'est donc une valeur que vous devrez expérimenter. L'impact sera surtout visible sur des scènes à textures haute-définition complexes comme PNW ou des scènes photoréalistes. Il est important de noter que CETTE valeur n'impactera PAS votre CPU multicoeur car les fils (ndt : threads) du gestionnaire de textures sont placés dans les coeurs dédiés au chargement de textures et au traitement d'objets (qui sont les 3 derniers si vous avez un quadcore).

Ce qui suit nécessite une explication détaillée. Donc lisez attentivement. Considerons que vous avez un I-7 avec l'Hyperthreading (HT) desactivé (ndt: Hyperthreading se désactive dans le BIOS) donc vous disposez des :

CORE0 CORE1 CORE2 CORE3 (ndt : CORE = coeur de CPU)

le CORE0 est en charge des « fibers » et du planificateur principal (NDT : main scheduler)
les CORE1, CORE2 et CORE3 s'occupent du gestionnnaire de textures ET du traitement d'objets (Autogen)

Les "fibers" sont comme des petits processsus qui font des "choses" avec d'autres processus (oui, je suis désolé, c'est pas vraiment hi-tech comme explication - j'essaye juste de rester simple) Dans FSX, les « fibers » s'occupent du chargement du système de terrain. Ils ont besoin de communiquer avec le planificateur principal (qui fonctionne lui aussi sur le CORE0) afin de coordonner en multitâche la génération de scène à chaque fois qu'une image est créée.

On vient de voir que les deux (« fibers » ET le planificateur principal) travaillent sur LE MEME COEUR. Alors voici une astuce:
« Fibers » est bloqué sure le CORE0 et ne peut être déplacé
Par contre VOUS POUVEZ déplacer le planificateur principal vers un autre coeur !
Donc, si vous ajoutez à votre fsx.cfg:

[JOBSCHEDULER]
AffinityMask=14

Vous demandez à FSX d'utiliser uniquement les CORE1, CORE2 et CORE3 .. alors, qu'en est-il CORE0? Il va ENCORE gérer les « fibers » ! Car ils ne sont pas liés à l'AffinityMask. Ce réglage rend FSX bien plus efficace.

Dorénavant, FSX utilisera les

CORE0 CORE1 CORE2 CORE3

le CORE0 se chargera des « fibers »
le CORE1 s'occupe du planificateur principal
les CORE2 et CORE3 s'occupent du gestionnaire de textures ET du traitement d'objets (Autogen)

C'est bien mieux équilibré! (et ça entraine aussi un léger gain en performances!) C'est pour cela que tant d'utilisateurs disent que modifier le FRAME_TIME_FRACTION affecte leurs performances
Quand ils le baissent, bien sûr! C'est le cas et nous allons parler en maintenant:)

Maintenant, micro-ajustons les « fibers » et le système de chargement du terrain. Considérons ceci:
[MAIN]
FIBER_FRAME_TIME_FRACTION=0.25

la valeur ci-dessus signifie que 0.25 (ce qui signifie 25% - un pourcentage !) est le pourcentage de «temps» que les « fibers » « coopéreront avec le planificateur principal afin de créer le terrain. Supposons de vous avez vos fps bloqués à 25 ? Ce qui fait donc 25 images/secondes, n'est ce pas ? 1 seconde = 1000 millisecondes. Donc, si vous divisez 1000 millisecondes / 25 images qu'est-ce que obtenez ? Vous obtenez des millisecondes par image. Ce nombre est de 40 millisecondes.
Donc, maintenant nous savons que la création de CHAQUE IMAGE, prend environ 40 millisecondes (si vous bloquez les fps à 25). Mais sur ces 40 millisecondes par image,
combien de temps ou % du temps voulez vous que les « fibers » coopèrent en multitâche avec le planificateur principal ? Bien .. Si vous lisez, re-lisez et à analysez ce qu'Adam (ndt : Adam Szofran) à écrit à Phil Taylor, vous comprendrez qu'Adam a laissé entendre que la valeur optimale serait de 10 ms. C'est pour ça qu'ils donnent 0.33 (lire ici :http://blogs.msdn.com/ptaylor/archive/2 ... -or-2.aspx)

Donc, cette valeur doit être ajustée en fonction de vos fps. Bien sûr, ça n'aura pas d'impact A MOINS d'avoir un processeur SIMPLE c?ur (sur lequel vous ne pouvez pas déplacer le planificateur principal sur un autre c?ur) ou si vous utilisez Tileproxy ou tout autre programme TRES lourd. Pour ces cas, je suppose que 10 ms ne suffiront pas et que vous devrez allouer plus de temps, sinon, les floutages seront TERRIBLES

Et en parlant de floutages, de temps alloué au terrain et aux fibres ... :) Nous avons également:

[TERRAIN]
SWAP_WAIT_TIMEOUT=10

Et vous vous demandez pourquoi '10' 10 quoi ? Des « frames » (ndt : images) ? Selon Phil s'agit d'une valeur comprise entre 1-60 «frames»
Sans mettre en doute la parole de Phil,, ce SWAP_WAIT_TIMEOUT n'a un impact CHEZ MOI que lorsque j'alloue plus de temps aux « fibers ».SWAP_WAIT_TIMEOUT n'agit pas sur les « frames » mais sur des délais d'attente en millisecondes (par image), Phil a certainement dit que c'était des « frames » pour ne pas nous embrouiller ;) Vous pouvez jouer avec cette valeur (surtout si votre FIBER_FRAME_TIME_FRACTION est élevé), mais ne vous attendez pas à gagner des fps. Par contre, il y aura un effet sur les temps de chargement de textures et les floutages. Vous pouvez donc ajuster ce délai d'attente a votre FIBER_FRAME_TIME_FRACTION. Moi, j'ai '10'


Maintenant ... parlons des fps bloqués

Vous devez comprendre les éléments suivants:

Lorsque vous "volez" dans FSX, chaque image est comme un "photo » qui contient des objets et des textures et qui doivent être "dessinés" pour chaque « photo ». Lorsque vous mettez bout à bout et en succession rapide ces « photos », par exemple 25 photos par seconde (ndt : 25 frames per second ? 25 FPS) , vous obtenez une impression de mouvement.

Il est très important de comprendre ce concept car dans FSX, toutes les opérations (création de terrain, placement d'objets,...etc) se font dans cet «espace» qu'est la création de cette « photo »
Que est ce que ça vous inspire ? Plus les fps seront élevés, plus FSX devra travailler. Par exemple, vous aimez voler à 30 fps mais quelqu'un vous met en tête que ce ne sera réaliste qu'à 60 FPS. Bien, en passant de 30 à 60 FPS, vous DOUBLEZ la charge de travail de FSX ! Ne soyez donc pas surpris de voir des illuminations de Noël et l'autogen qui grimpe au ciel :). Je ne rentrerai pas dans ce débat qui pourrit nos foras depuis les premiers jours. Réglez vos fps comme vous les voulez ! Personnellement, je me suis HABITUE à les bloquer à 25, et vous savez quoi ? Ca me va bien, parce que je m'y suis HABITUE. Au début, c'était affreux, mais après une semaine, mes yeux s'y sont faits.

Alors, faut-il utiliser un limiteur de FPS ou les laisser en illimité ? Eh bien, tout dépend de votre style de pilotage ... Si vous n'utilisez que des avions par défaut ou peu gourmands ou seulement des cockpits 2-D, alors votre CPU ne sera pas surchargé. .. Dans ce cas, il suffit de verrouiller vos fps dans FSX .. POINT.

Maintenant, si vous ne volez que dans des avions COMPLEXES, surtout en cockpit virtuel, vous devrez mettre vos fps en illimité ! Mais ... il y a un problème ;), ne vous ai-je pas dit que FSX avait plus de travail si on augmentait les fps ? Qu'advient-il quand les fps bondissent de 30 à 60 puis retombent à 25 pour repartir à 60 de plus belle ? Est-ce équilibré ? Et si vous avez UsePools = 0 ? Que croyez vous qu'il se passera quand soudainement vous passez 70 FPS? CRASH! ;) En plus ... la sensation «perçue» (parce que c'est pas vrai) quand les fps varient brusquement est que ça « saccade ». Il faut de la constance dans la fluidité et c'est là qu'un limiteur externe de fps peut vous aider ;) capiche ? (ndt : FPS_limiter 0.2 : <a href="http://www.caveofdistraction.com/fpslim ... er_0.2.rar" target="_blank">http://www.caveofdistraction.com/fpslim ... 0.2.rar</a> )

Maintenant ? utilisez ces réglages comme REFERENCE ... surtout si vous avez UN CPU PUISSANT, augmentez les curseurs de complexité de scène et d'autogen cran par cran et bloquez vos fps, soit dans FSX, soit avec un limiteur externe (mais avec le curseur sur illimité dans FSX) jusqu'à ce que vous trouviez VOTRE COMPROMIS, ou le point à partir duquel votre GPU ne suivra plus (vous pouvez vous aider d'un outil de monitoring de GPU, même si ce qu'il vous montre n'est pas exact à 100%).

<img src="http://forums1.avsim.net/uploads/monthl ... 647262.jpg" border="0" class="linked-image" />

<img src="http://forums1.avsim.net/uploads/monthl ... 647272.jpg" border="0" class="linked-image" />

<img src="http://forums1.avsim.net/uploads/monthl ... 647278.jpg" border="0" class="linked-image" />

<img src="http://forums1.avsim.net/uploads/monthl ... 647284.jpg" border="0" class="linked-image" />

<img src="http://forums1.avsim.net/uploads/monthl ... 647292.jpg" border="0" class="linked-image" />

REMERCIEMENTS:
Je tiens à remercier sincèrement et publiquement PMDG car ils ont été les seuls développeurs à avoir pris l'initiative d'organiser les recherches sur les problèmes de corruption de textures et d'y avoir participé activement. Sans leur implication, on y serait certainement pas arrivés. Donc, les gars, montrez votre gratitude et achetez leurs quelque chose :) je me suis basé en grande partie sur le travail et les théories de Ryan (ndt : Ryan Maziarz ? PMDG) .. alors, s'il vous plaît ? ILS MERITENT VOS REMERCIEMENTS;
Pour tous les gars à Avsim, David Roch, Stephen, Mitch, David Alexander, J van E, Jjjallen, pingpong, DJJose et tous ceux qui m'ont soutenu depuis LE PREMIER JOUR grâce à leurs test, leur retours et leurs encouragements, et ce malgré certains qui auront tout essayé pour me discréditer à grands coups d'explications pseudo-techniques, aussi erronées que stupides.
Hé les gars, J'AI VRAIMENT besoin d'une pause donc ne vous inquiétez pas si elle se prolonge un petit peu ! ;) (vous voudrez également excuser les fautes éventuelles, l'anglais n'étant pas ma langue maternelle).

Jesus Altuve, avril 2010
<a href="http://www.linkedin.com/in/jaltuve" target="_blank">http://www.linkedin.com/in/jaltuve</a>
Jean-Paul
ImageImage
«Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait.» Marcel Pagnol
Répondre

Revenir à « FSX »