Mur du son

[Vladimir2000]

Re: Mur du son

Alors là , Bravo vous avez taper dans le meal.
c'etait pile ca,le modele de vol.
Je l'ai mis sur trois et aucun pb .je suis meme aller j'usqu'en survitesse.
Mais dites moi ce que ca change si on augmente le model de vol du paneu des options et alarmes?
A quoi ca correspond?

[arno54]

Re: Mur du son

simplement le nombre de fois que l'attitude de l'appareil est calculé par cycle. Sur des appareils très lègers et/ou très rapides, ça peut changer beaucoup le comportement.

[Vladimir2000]

Re: Mur du son

Ca joue beaucoup sur le ralisme? où je doit pas m'en scoucier plus que ca?

[andertal]

Re: Mur du son

Ça joue sur le réalisme dans le sens, où le comportement de l'aéronef est calculer plus souvent encore... Donc un comportement encore plus proche de la réalité.
Mais alors pourquoi ne pas mettre par défaut ce truc au max?!?!
Et bien pour la bonne et simple raison que si le comportement de l'aéronef est encore meilleur, ton ordinateur, lui, devrais alors calculer plus souvent le modèle mais aussi il devra toujours garantir un FPS minimum... et donc faire encore plus de calcule là où il peinait déjà.....
Tu observera peut être que si ton F22 ne part plus en sucette, le FPS lui n'a pas décoller pour autant, voir même pourrait être descendu...

Il faut faire un compromis entre la fidélité du modèle de vol, et le rendu visuel.
plus de calcule sur le modèle donne un comportement plus fidèle
plus de calcule sur le modèle donne un "visuel" moins précis
un visuel moins précis donne des réaction du pilote moins précises
des réaction du pilote moins précises donne un comportement moins fidèle
donc plus de calcule sur le modèle donne un comportement moins fidèle :evil:
hors plus de calcule sur le modèle donne un comportement plus fidèle
il faut trouver le juste milieu et chaque machine à une capacité qui lui est propre, un juste équilibre entre processeur et carte graphique, option visuel et comportemental, FPS et modèle mathématique.....

andertal


PS : cette démonstration est une démonstration par l'absurde, tout y est exagérément exagéré ;)

PS 2 : dans ton cas Vlad., si avec 2 calcule par image tu retrouve un comportement "réaliste" il ne sert a rien de le porter a 3 encore moins à 4 ou 5 qui ne ferait que dégrader le comportement au final... bien sur si a 2 ça sautille encore un peu, le porter à 3.... trouver le juste milieu ;)

[PhM]

Re: Mur du son

...C'est le simu qui va garder les valeurs de drag de l'avion chargé précédemment, si tu charges un 737 avant le CF-104 ou le Concorde par exemple, tu n'arrivera souvent même pas à passer Mach1- tu recharge l'avion et hop, tout roule - ça n'a rien à voir avec le code de l'acf mais bien avec X-plane lui même, et le problème est ancien car je l'e rencontrais déjà sous v7 ...

C'est pas vrai Quel bordel ça doit être le code source de X-Plane :roll:

PhM

[david_dtc]

Re: Mur du son

ben disons que si l'on compare le code d'X-Plane à celui de MS Office, c'est du clair, net, frais, précis et nettoyé.. par contre, la simulation du vol supersonique est un point faible d'X-Plane depuis toujours et il semble qu'Austin traine ce problème sans pouvoir s'en débarrasser complètement pour l'instant - c'est pas forcément le code qui est en bordel, c'est plus probablement un bout du code étant dédié au calcul du modèle de vol qu'il faudrait complètement réécrire pour se débarrasser du problème. Encore une fois, il suffit le plus souvent de charger l'avion supersonique deux fois de suite pour s'en débarrasser. Gênant mais pas rédhibitoire.

[PhM]

Re: Mur du son

ben disons que si l'on compare le code d'X-Plane à celui de MS Office, c'est du clair, net, frais, précis et nettoyé.

Tu as eu accès aux sources ? Moi non, mais j'ai vu un morceau de code qui est dit provenir d'Austin, voir ici, et dans ce bout de code bswapi et bswapf me font me poser pas mal de questions, c'est en tout cas loin d'être clair, frais , précis et nettoyé. Si tout est comme ça je comprends les problèmes de fps.

par contre, la simulation du vol supersonique est un point faible d'X-Plane depuis toujours et il semble qu'Austin traine ce problème sans pouvoir s'en débarrasser complétement pour l'instant - c'est pas forcément le code qui est en bordel, c'est plus probablement un bout du code étant dédié au calcul du modèle de vol qu'il faudrait complétement réécrire pour se débarrasser du problème. Encore une fois, il suffit le plus souvent de charger l'avion supersonique deux fois de suite pour s'en débarrasser.

Je ne vois pas en quoi les calculs en mode supersonique peuvent être responsables du fait qu'un avion garde des valeurs d'un avion précédent. Mais si tel est le cas c'est pour cela que je dis que ça doit être le bordel.

Dans un simulateur de vol l'avion est une des sources d'informations utilisées par la physique pour calculer au final la position du-dit avion à chaque pas temporel. On lit des valeurs, les combine avec d'autres dans des calculs pour produire un résultat, il n'y aucune partie des informations provenant de l'avion à stocker dans ce processus, c'est juste du traitement. C'est le b-a-ba, des objets qui font ce qu'ils ont à faire sans se préoccuper de ce que fait le voisin, du cloisonnement.

Gênant mais pas rédhibitoire.

Si il est avéré qu'une partie du code censée faire uniquement du traitement de données stocke en fait certaines de ces valeurs d'entrée c'est effectivement gênant. Si en plus elle ne stocke même pas correctement au changement d'avion ce qu'elle estime devoir stocker, c'est embarrassant.

PhM

[Vladimir2000]

Re: Mur du son

Merci pour vos reponses

[david_dtc]

Re: Mur du son

Tu as eu accès aux sources ? Moi non, mais j'ai vu un morceau de code qui est dit provenir d'Austin, voir ici, et dans ce bout de code bswapi et bswapf me font me poser pas mal de questions, c'est en tout cas loin d'être clair, frais , précis et nettoyé. Si tout est comme ça je comprends les problèmes de fps.

ben bien sûr que non, mais je comparais à MS Office, qui est un monument érigé à la philosophie qui veut qu'on ne touche pas au code d'un autre, sous peine de le vexer et qu'on se trimballe ainsi du code vieux de vingt ans... Je ne parlais pas de la qualité du code "dans l'absolu", paramètre sur lequel je n'ai franchement pas beaucoup d'infos.

Je ne vois pas en quoi les calculs en mode supersonique peuvent être responsables du fait qu'un avion garde des valeurs d'un avion précédent. Mais si tel est le cas c'est pour cela que je dis que ça doit être le bordel.

C'est pas ce
que j'ai voulu dire, je me suis mal exprimé et fait un amalgame un peu rapide - c'est juste que ce problème d'x-plane qui garde les valeurs de drag du zinc précédent devient plus facilement visible en passant d'un cessna à un supersonique, surtout pour ceux qui n'ont jamais piloté dans la vrai vie et utilisent X-Plane plus comme un joujou que pour ses valeurs de simulateur.

Dans un simulateur de vol l'avion est une des sources d'informations utilisées par la physique pour calculer au final la position du-dit avion à chaque pas temporel. On lit des valeurs, les combine avec d'autres dans des calculs pour produire un résultat, il n'y aucune partie des informations provenant de l'avion à stocker dans ce processus, c'est juste du traitement. C'est le b-a-ba, des objets qui font ce qu'ils ont à faire sans se préoccuper de ce que fait le voisin, du cloisonnement.

On est bien d'accord -> effectivement, le code doit être moins exemplaire que je ne le croyais jusque là

Si il est avéré qu'une partie du code censée faire uniquement du traitement de données stocke en fait certaines de ces valeurs d'entrée c'est effectivement gênant. Si en plus elle ne stocke même pas correctement au changement d'avion ce qu'elle estime devoir stocker, c'est embarrassant.
PhM

là aussi on est d'accord, mais bon, on est pas à ce bug près sous X-Plane - on nous à habitué à pire déboires...

[arno54]

Re: Mur du son

alors, juste pour apporter de l'eau au moulin (à paroles)

je viens de tester concordov vs flamant en 9.41, en rechargeant ou pas et cavok sur lfkb (niveau de la mer)

C'est démentiel...
Concordov chargé deux fois, puis passage au MD : le MD s'envole à 55kt au lieu de 80, grimpe aux murs à 450m/mn et file à la vne (209kt) en 2 mn...
manip inverse :
Concordov ne passe plus le mur, et de loin...

Donc je confirme, il reste des valeurs de l'avant dernier avion quelque part, y compris si xplane a été arrété totalement et redémarré. C'est assez frappant avec ces deux extrêmes...

[Daniel_L]

Re: Mur du son

Donc je confirme, il reste des valeurs de l'avant dernier avion quelque part, y compris si xplane a été arrété totalement et redémarré. C'est assez frappant avec ces deux extrêmes...

Pas tout le temps ou alors pas sur tous les OS car hier soir je suis passé du CirrusJet au F22 sous Linux et du premier coup je suis monté à Mach 1,4.

Daniel

[david_dtc]

Re: Mur du son

Donc je confirme, il reste des valeurs de l'avant dernier avion quelque part, y compris si xplane a été arrété totalement et redémarré. C'est assez frappant avec ces deux extrêmes...

Pas tout le temps ou alors pas sur tous les OS car hier soir je suis passé du CirrusJet au F22 sous Linux et du premier coup je suis monté à Mach 1,4.

Daniel

Ben ce serait peut-être pas inintéressant de voir ce qui différencie (dans les paramètres accessibles dan PlaneMaker) les avions livrés par défaut et les autres...

[PhM]

Re: Mur du son

ben bien sûr que non, mais je comparais à MS Office, qui est un monument érigé à la philosophie qui veut qu'on ne touche pas au code d'un autre, sous peine de le vexer et qu'on se trimballe ainsi du code vieux de vingt ans... Je ne parlais pas de la qualité du code "dans l'absolu", paramètre sur lequel je n'ai franchement pas beaucoup d'infos.

J'avais un petit espoir, du genre il a collaboré sur quelque chose et il a vu des bouts de code, je vais lui soutirer des infos. Raté.

...effectivement, le code doit être moins exemplaire que je ne le croyais jusque là

Tu as été voir l'exemple que j'ai donné ? Moi ça me rassure pas.

là aussi on est d'accord, mais bon, on est pas à ce bug près sous X-Plane - on nous à habitué à pire déboires...

Hélas :roll:

PhM

[david_dtc]

Re: Mur du son

Tu as été voir l'exemple que j'ai donné ? Moi ça me rassure pas.

ooooh oui...et j'y comprend RIEN :D (je le dis fièrement, je ne comprends strictement rien qui aille plus loin que le Basic de mon Phillips VG5000)

[arno54]

Re: Mur du son

Imagine : pour calculer 1+2+3...+9, tu peux soit additionner tous les chiffres, soit considèrer que tu as 4 paires de 10 et un 5 : 1+9, 2+8, 3+7 etc et un 5

Evidemment, 4x10 + 5 = 45 c'est beaucoup plus simple que 1+2+3+4+5+6+7+8+9=45.

S'il fallait additionner tous les nombres jusque 99, tu imagines le bordel... alors que 1+99, 2+98, 49+51...+50, c'est facile : (49*100)+50, même de tête, ça prend un quart de secondes...

C'est le b-a-ba de la structure d'un code : plus c'est court, plus c'est élégant, mieux ça marche.
Plus c'est long, plus c'est complexe, plus il y a de risques d'erreur et plus c'est long à éxecuter et moins c'est facile à débogguer.

Dans l'exemple montré, la réorganisation rationnelle des instructions soumise par phm fait économiser une grande quantité d'instructions, donc accélère beaucoup l'exécution.

Et c'est effectivement inquiètant de voir que les directives sont si mal fagottées...comme un gosse qui veut ajouter tous les nombres mais qui ne sait pas à se servir d'une calculette.