F100

Moi, je m'amusais bien aussi, jusqu'à ce qu'un clown en F22 passe le mur son à 500pieds et me démonte les vitres du beaver. Les gens n'ont plus de limites...

Christian, il faut utiliser un hébergeur de photo externe et gratuit, comme http://www.hostingpics.net/ , et transmettre le lien en clickant le neuvième icone de la barre d'outil (les maillons de chaîne avec un petit rond vert dessous). Avant on avait un bouton pour joindre directement un document, mais il a disparu... Gerard, j'ai deux probleme semblables : - Portland (Oregon) de Orbx : à 10 nautiques, je vois la ville, à 5, elle disparaît d'un coup, et je ne vois que la scene par défaut. - Orcas (Orbx) : j'ai une zone de vision ou tous les bâtiments disparaissent. si je change de point de vue d'un poil, tout revient. Je pense que la façon assez différente que P3D à de traiter le graphisme y est pour quelque choses. Les auteurs devraient recompiler leurs œuvres avec les outil du Sdk P3d V2.2

Wath ever you want !! 25 à 30, c'est pas mal.

Dernier conseil : mets le fps en illimité dans Fsx et utilise le frame limiteur de Nvidia Inspector : cela donne de l'air aux cpu et gpu. Bons vols

FIBER_FRAME_TIME_FRACTION : Si tu visualises l'activité Cpu, tu verras qu'il y a un coeur qui fonctionne différemment des autres. C'est lui le patron, mais c'est aussi lui qui bosse le plus. FIBER_FRAME_TIME_FRACTION défini le pourcentage de temps que ce cœur alloue à la reconstruction de l'image. Mais, il ne faut oublier qu'il n'a pas que cela à faire : gestion du vol, des Ai, Radio, de ses copains etc etc. Le réglage n'aura pas le même effet selon (entre autre) la position des curseurs d'Ai (avions, autos, bateaux) et bien sûr la config du système. En pratique 50 à 60 sont plus raisonnables. Le bufferpool conseillé par JBouze est juste une c***rie. Bufferpools : contrairement à ce qu'il pense, ce paramètre n'a rien à voir avec la taille de la ram vidéo, mais dépend de la capacité de la carte graphique à avaler ce que le cpu lui envoie. En clair, si la carte est costaude il n'y a pas besoin de buffer, le cpu pouvant envoyer à la volée tout ce qu'il veut. Dans le cas contraire, bufferpools définit un tampon rempli par le Cpu, et vidé par la carte graphique. JBojote à publié plusieurs posts sur le sujet (Forum avsim US). Ce n'est pas simple appréhender si le paramètre est nécessaire et quelle valeur lui donner. Si tu as beaucoup de saccades, il faut un peut plus de buffer. Les valeurs usuelles sont : 512Kb -> 524288, 256Kb -> 262144, 124Kb -> 126976, 96Kb -> 98304. Ne pas dépasser les 512, sous peine de crash OOM (erreur mémoire) sur les scènes denses. Mais il faut essayer de tourner sans, puisque que cette option bouffe de la ram et du temps cpu (qui sont les points critiques de Fsx) TEXTURE_BANDWIDTH_MULT. Pour que ce paramètre soit actif, il faut fixer un plafond aux Fps (25 frames/seconde, par exemple). En "illimité" Fsx l'ignore. Ce paramètre joue sur le flou des textures. Il semble qu'au dessus de 120, cela ne serve plus à rien. La difficulté est que Fsx est un monde compromis.Le paramétrage qui va bien sur une machine peut en mettre une autre au tas. Il y a des liens subtils et pas vraiment identifiés entre les paramètres du .cfg entre eux et avec la config hardware, qui font que chacun doit tenter ses ajustements lui-même. Il faut aussi se méfier des fonctionnement chimériques qui ne seront jamais possibles à obtenir sur une petite ou moyenne configuration (et même sur une grosse). Il faut savoir redescendre les curseurs d'un cran. TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=4500 et TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=3000 peuvent (doivent?) être réduits pour libérer un peut de temps Cpu (3000 et 2000 par exemple). En pratique, l'ajustement à la JBojote donne de bons résultats. Dans les derniers temps, je l'utilisais tel quel. Si tu lis l'anglais, fais des recherches dans le forum US avec le nom des paramétrés qui intéressent, il y plein (quelque fois trop) d'infos, et surtout des gars balaises qui maîtrisent le sujet.

Merci JP Hier j'ai volé à 1000/1500 pieds/sol pendant 2 heures au dessus de SAK/Tongass/PNY sans accrocs coté OOM. La mémoire reste sagement autour de 2 Go (autogen à toc) Je continue à avoir un petit pb de fluidité. Bien que je limite à 25Fps, et que ni Cpu, ni carte graphique ne sature, j'ai des "micro"-saccades. L'AffinityMask n'y change rien Le changement de vue est assez onéreux en reconstruction d'image. Si je passe de l'intérieur de l'avion à l'extérieur : pas de pb, par contre au retour dans l'avion, j'ai droit à une reconstruction complète du décor qui dure bien 10 à 15 secondes. Je n'ai pas regardé de très près l'antialias, mais il me semble qu'il y ait un mieux : en réglage par défaut les câbles verticaux des ponts nets. D'autres retours ?

Dommage, oui, mais l'équipe de LockeedMartin fait du bon boulot avec Prepar3d. J'ai migré il y un an et je ne regrette pas.

Je sèche. Si tu n'as pas besoin des fonctions évoluées de Fsuipc, la solution est peut-être de revenir au couple 4.70b et 4749c qui semble fonctionner. Ce qui m'étonne, c'est que ce problème, apparu il y à 2ans, ait complètement disparu avec les évolutions de Fsuipc, et qu'il réapparaisse maintenant, sans que les solutions actuelles ne le fixe. Bizarre

Question : dans le menu de Fsx, y a t'il un item "Add-On" ? si oui, Fsuipc existe-elle dans la la liste déroulante? Si ce n'est pas le cas, Fsuipc est soit mal installée, soit pas lancée par Fxs

Restons calme... Faut pas tout écrire en gras, on a l'impression que tu cries - La correction du bug G3d est incluse dans la partie gratuite de Fsuip. - L'installation de Fsuipc se fait avec l'installateur, et ne nécessite pas de supprimer la version précédente. - WideFs n'est pas nécessaire. C'est un module permettant, dans la version enregistrée, de connecter plusieurs Pcs pour déporter des fonction de Fsx. - BufferPool est en relation avec la carte graphique. Si la carte est assez rapide pour ne jamais se laisser déborder par Fsx (quant elle 'déborde', il apparaît des artefacts ou des flashs à l'écran), c'est mieux de ne pas avoir de buffer. Le fait d'activer bufferpool crée une zone tampon, donc évite les problèmes graphiques, mais se paie sur les Fps. J.Bojote à créé un site qui permet l’optimisation de Fsx.cfg. C'est par ici :http://www.venetubo.com/fsx.html. L'optimisation de Bojote ajoute assez sytématiquement Bufferpool. Il faut essayer sans (juste mettre // (2 fois /) en debut de ligne) Bons vols

Loic, J'ai bien reçu ton message. Mais, j'ai réfléchi (si, si, ça m'arrive...) et j'ai relu le topic en anglais de l'époque. La manip décrite ici n'était justifiée que par le coté 'temps réel' de la solution du problème. P.Dowson n'est pas du genre à trouver une solution et à la laisser pourrir ensuite. Le fichier d'historique de Fsuipc (contenu dans fsx\modules\fsuipc documents) confirme que le code fixant l'erreur G3d.dll a été intégré à toutes les versions postérieures à la 4.70, depuis la 4.80 et suivantes. La version actuelle 4.929 compatible Fsx et Pd3 (sur le site http://www.schiratti.com/dowson.html ) doit donc fixer ton problème. Fais nous savoir comment cela se passe.

Coté OOM, les choses sont l'air bien fixées. Les jeux d'ombre peuvent être superbe (vue extérieure de l'avion qui passe dans l'ombre d'un nuage) mais la carte graphique en a très vite plus qu'elle ne peut en avaler. Ce qui me gène, ce sont les saccades : en coupant les ombres, dans un décors avec peu d'autogène (cpu et gpu à +/-70%), j'ai un Fps à +/-50, mais ce n'est pas fluide comme l'était la 1.4.

Signe avec ton prénom, c'est mieux J'ai la 4.70b en archive. Contacte moi par message perso en me fournissant une adresse email où je puisse te transmettre les fichiers.

je viens de faire un essai rapide après install de l'update (et c'est le moment que mon joystick à choisi pour me lâcher). Première impression sur les Tongass : occupation mémoire sévèrement réduite (d'un giga au moins). J'ai touché un peu les nouveaux curseurs de gestion d'ombre : mon Gpu en à plein la gueule (Gtx680). Je m'y remets ce soir à tête reposée. Mais, à priori, ça sent bon :smile:

Merci Aimé. Ca charge...

En simplifiant, le plantage de Fsx par OOM (Out Of Memory) est dû à plusieurs choses: - Fsx est un programme 32bits, donc le système ne peut lui allouer que 2^32 bytes soit +/- 4.2Gigas. - à cette allocation, il faut retrancher : l'occupation du code de Fsx lui-même et une "grosse" fenêtre d'accès à la mémoire de la carte graphique. En pratique, les OOM apparaissent à +/-3.2 Giga d'occupation "utile". - la mémoire est utilisée par tous les objets et simulateurs (AIs, Radios...) de Fsx, et surtout par les textures qu'il doit transmettre à la carte graphique. En fonctionnement normal, Fsx charge et décharge en permanence les objets et les textures en fonction de la position de l'avion, les angles de vue, le rayon de vision, (etc). De ce fait, il existe une première façon de planter Fsx : c'est d'utiliser des scènes extrêmement chargées en objets (bâtiments variés, arbres variés) avec les curseurs et des paramètres d'autogen à fond. Mais il existe un autre mécanise très pervers (bug) : si un objet réclame une texture que Fsx ne peut pas trouver, la mémoire allouée pour cette texture n'est jamais libérée. Donc à chaque fois que l'objet est rechargé, le même phénomène se reproduit et, à terme, cela fini par un OOM. Il y a plein de raisons pour que ce genre de chose se produise : scenerie amputée, mal installée, ou "droits d'accès insuffisants" qui rendent le(s) fichier(s) invisible(s) à Fsx et provoque ce phénomène de pompage. Le contournement par l'attribution des tous les droits à tout le monde a comme danger principal d'autoriser n'importe quel code honnête ou malfaisant à faire ce qu'il veut, donc en terme de sécurité ce n'est pas top. La meilleure façon d'éviter ce problème, c'est l'installation de Fsx et ses addons dans un répertoire différent de c:\program files(x86) qui est la propriété du system (TrustedInstaller) et qu'il vaut mieux ne pas tripoter. Idéalement, Fsx et addons s'installent sur une partition à eux, si possible placée en début de disque. Cela résout le problème de droits d'accès, améliore la vitesse, et facilite la maintenance.

Sur le site de "Return to misty moorings", page "Enhancements"(http://return.mistymoorings.com/enhancements/), au milieu de la page, ils fournissent des repaints pour le beaver d'aerosoft en deux versions : clean et dirty. Peut être qu'en regardant de près les textures cela peut t'inspirer

Waou.. C'est juste impossible... Ce type n'est pas un pilote, c'est un magicien. Merci Dominique.

Jp, je confirme ce que dit Dom : le bouton "Attach Files" a disparu. (IE11 et Chrome)

Alors, Dominique, c'est quand qu'on la voit cette vidéo ? :wink:

C'est du bon boulot. J'ai toujours eu beaucoup de respect pour ceux qui passent du temps sur des addons distribués gratuitement. Par contre, dans la vraie vie, les avions sont souvent un peu "crades". J'aime bien les livrées style "j'ai déjà des heures de vols, et le Kärcher est en panne". Signe avec ton vrai prénom, c'est plus sympa

Bonjour Frank Sans connaitre ta config (Cpu, MoBo) difficile de dire, mais tu n'aurais pas eu intérêt à compléter tes 8 Go actuels avec de 2x4Go de Vengence 1600 ?

Je pense que P3d va devenir incontournable. Il se dessine comme l'évolution (dans le bon sens) de Fsx, avec Dx11, un sérieux transfert de charge vers le Gpu, et, même si tout n'est pas fixé, la compatibilité avec les acquis Fsx A la décharge des gars de LM, j'imagine le boulot de dingue que représente la prise en mains des milliers de lignes de codes d'Esp, et les bugs qui découlent obligatoirement des modifs. Et il faut reconnaitre leur capacité à apporter des solutions aux mal-fonctions qu'on leur remonte. A l'époque Microsoft, on prenait le simu comme il était, et on espérait que la mouture suivante réglerait les problèmes. Le dernier point qui m'ennuie, c'est de voir un des cœur du Cpu au taquet, alors que les autres se tournent les pouces. Peut-être avec une version en 64bits ?

Lm nous a appris à être prudent, mais il faut reconnaitre que ça va dans le bon sens. Il faudra qu'ils envisagent sérieusement la gestion du Sli, les cartes graphiques vont enfin commencer à chauffer

Carte graphique : Fsx et P3d v2 => deux cas très différents Fsx : Le programme se charge de l'essenciel du "pré-travail" graphique, et la carte est assez peu sollicitée. Il suffit pour s'en convaincre de faire tourner l'affichage de charge de NvidiaInspector pour se rendre compte qu'une vieille 9800Gt tourne à 70/80%. Par contre, la gestion de la mémoire est fait par partage de la Ram alloué à Fsx avec la ram du Gpu. Cela signifie que le 1 giga de la carte graphique, vient en soustraction des 4.3 gigas que le systeme peut allouer à Fsx. Donc, méfiance, une grosse capacité mémoire Gpu peut provoquer des OOMs, et une carte puissante n'apporte pas grand chose. P3D V2 : là, tout change. P3D sollicite très fort la carte surtout pour les effets d'ombre et de réflextion (DX11), d'ou l'importance d'avoir un Gpu (très) musclé. La gestion de l'échange en mémoire P3d et Gpu se fait par page, donc la taille de la Ram Gpu n'impacte que peu les 4.294gigas (allocation ram max en 32 bits =2^32).