Bien oui à force de travailler avec des dinosaures de l'air paléontologique on se traine avec un fossile à 32 bits..! mais ils étaient au courant de l'époque   ..!
*
et Dieu créa la femme et nous on reste des *Bleus bits* enfarinés

Donc le 64 sera XPLANE   l'unique et seul miraculé ...!

Neptune

Va falloir que je regarde X-plane de plus près ...
Pasque.
Si P3d y traine encore des codes de...     çà !

-
Là, c'est sûr que y a souci !!   ;-))
-
M'enfin si on revient à la version "première".
Côté FPS on devrait commencer à respirer.
-
Comment çà, c'est pas beau ??
N'empêche !
Là, on doit taper dans le 300000 FPS !!
-
Cé pas grave tout çà.
On est trop nombreux pour qu'on nous oublie.
Nous et nos "sous" surtout ! :-))
-
Y a plein de gens qu'y pensent à nous $$$$$$$$$$$ ....0_o

Daniel

moi j avais commence sur le trs 80... etienne

http://www.volny.cz/havlikjosef/historyenglish.htm

Hello
De l'assembleur dans FsX? La vache, pas si moderne que ça le bouzin finalement.
C'est clair que s'ils doivent se retaper de l'assembleur avec ces milliers de ligne de code pour faire pas grand chose et le retranscrire en langage de haut niveaux moderne, ils ont du pain sur la planche.

Pour ceux qui se demande ce que c'est que de "l'assembleur" c'est un vieux langage de programmation de bas niveaux très proche du langage machine qui elle (la machine) ne comprend que des 1 ou des zéro'.
Langage de bas niveaux certes, mais coté programmation, c'est du haut vol.
La je suis bluffé.

Apres faut voir comment se presente l'architecture de ces modules codes en assembleur.
Y'a deux possibilites: ou bien tu les modifies pour les passer en 64 bits, ce qui sous-entend qu'il faut d'abord les comprendre, puis les alterer, donc a peu pres ce qu'il y a de plus chiant pour un codeur... ou bien tu les remplace purement et simplement par d'autres fonctions codees avec un language moderne, et directement en 64 bits avec ton code a toi. La c'est mieux, pour le developpeur.

Mais souvent, lorsqu'un truc est (bien) code en assembleur, c'est tres difficile (voir impossible) de faire un truc plus performant avec un language normal.

nah en 77 c etait de l assembleur bien lourd et bien optimal avec des astuces de souix pour que ca depote. Je sais j ai pratiqué.

Exemple classique: driver reseau d'un router developpé selon les methodes "propres" de couches, langage object vituel, fonction bien explicitées etc contre gros hack bien illisible lineaire en assembleur optimisé à donf et complètement non maintenable, raport final de performance: de 1 a 20....

Pourquoi? car le codeur en assembleur va toujours aller chercher le micro code qui correspond exactement a ce dont il a besoin, alors que le compilateur suit sa propre logique qui n est pas toujours optimale (push pull de stack, non utilisation de certaines fonctions dediees a un processeur donne etc).

Etienne

Clair de l assembleur dans clipper ca devait etre chaud...

J ai serieusement bidouillé en 90-91 sur un campus US, le pire ? Pas sur, peut etre la fois ou m a demandé d optimiser le compilateur c d unix a l epoque apres l avoir décompilé, oui bien d ecrire des virus snoopers sur les sockets unixs?

Maintenant je fais des chateaux... c est plus modeste

Etienne

Bonsoir,
Le 6502 ... c'est Rockwell il me semble et pas Motorola...faut pas confondre avec le 6802 (je dois en avoir encore quelques puces de 6502, 6802 ou Z80 à 40 pattes dans mes tiroirs) . Le 6502, c'est l'Apple II et il y avait déjà un simulateur de vol sur cette bécane en 1979 ... en 3D Filaire bien sur...Si c'est beaucoup de jeux ...avec Visicalc, c'est le premier PC utilisable autrement qu'en contrôle de processus et je parle pas du Pascal UCSD. J'ai énormément programmé la dessus à mes débuts. Pfff...c'était ma jeunesse et ça valait pas loin de deux briques avec 64K et 2 drives!
Cordialement,
JMC

Dernière modification par gastonj (30-11-2012 20:01:01)

Bonjour,
Je crains qu'il n'y ait pas d'avenir 64 bits pour P3D! Une refonte du système s'imposerait pour le passage et l'assembleur n'est pas le seul problème. Même pour un programme écrit en "C", il faut faire attention à la taille des variables, notamment les nombres entiers, l'arithmétique des pointeurs mémoire etc...Un travail colossal pour les dizaines de millier de lignes de code et un coût énorme, presque aussi important qu'un nouveau développement. Sans compter que l'architecture du programme est déjà issue d'un replâtrage pour les processus concurrents (ce qu'on appelle la gestion des multi-cores). Tout ce que je pense qu'il est raisonnable d'espérer, c'est une correction des nombreuses boggues  qui doivent encore trainer dans un programme sans maintenance depuis de longues années. Une meilleure adaptation à W7 ou W8 et directX aussi sans doute... bof, j'espère me tromper mais il me semble qu'ils visaient un meilleur réalisme pour en faire un outil de simulation professionnelle.
Cordialement,
JMC

Bonjour,
Tu as sans doute raison! Cependant, par expérience, je peux te dire que ce n'est pas la faisabilité technique qui tranchera le sujet de son portage mais son aspect économique. Toutefois, ce n'est pas vraiment notre problème!
Cordialement,
JMC

gastonj a écrit:

Bonjour,
Je crains qu'il n'y ait pas d'avenir 64 bits pour P3D! Une refonte du système s'imposerait pour le passage et l'assembleur n'est pas le seul problème. Même pour un programme écrit en "C", il faut faire attention à la taille des variables, notamment les nombres entiers, l'arithmétique des pointeurs mémoire etc...Un travail colossal pour les dizaines de millier de lignes de code et un coût énorme, presque aussi important qu'un nouveau développement.

Ce n'est pas si colossal que cela surtout avec les outils de recherche dans le code.

Pour les bouts de code en ASM, j'ai la même vision que Daube. Je n'en vois plus réellement l'utilité aujourd'hui avec les compilateurs modernes. Autant réécrire directement ces fonctions avec des bouts de code moderne.

Après, avoir la volonté de le faire, est une autre histoire...

gastonj a écrit:

Sans compter que l'architecture du programme est déjà issue d'un replâtrage pour les processus concurrents (ce qu'on appelle la gestion des multi-cores).

Là, je diverge complétement sur ton analyse.
Qu'il ne puisse pas encore être optimisé, là surement!... Comme tout code d’ailleurs...
Par contre, comme tu m'as l'air d'être du métier, regarde et analyse son mode de fonctionnement et tu t'apercevras qu'ils ont utilisé les techniques de développement les plus performantes pour FSX.
Comme je l'ai déjà mentionné ici même, la seule chose que je vois qui pourrait améliorer le fonctionnement du code, c'est de mettre le thread de l'ATC qui est monolitique et qui tourne sur le core principale du processeur (en même temps que le thread principal...) ailleurs. Le mieux étant de le "fibreriser" est de dispatcher ceux ci sur l'ensemble des cores. Malheureusement cela doit poser quelques problèmes de synchro...
Mais, je pense que l'équipe de P. Taylor à l'époque, ne l'a pas fait uniquement pour des questions de gestion des priorités.

Sinon, pour être honnête, si j'étais propriétaire du code aujourd'hui, ma priorité sur celui-ci ne serait pas de le passer en 64 bits!...

Dernière modification par Ptipilot (01-12-2012 18:49:45)

gastonj a écrit:

Oui, je suis du métier. Ils ont fait sans doute au mieux avec les possibilités à l'époque ...

Le problème, c'est que la technique n'as pas vraiment évoluée dans ce domaine ces dix dernières années...
Là, je serai curieux de connaitre ce que tu pourrais y incorporer en plus et qui améliorerait (ent) le fonctionnement du moteur????......

gastonj a écrit:

mais bon, c'est ce que j'appelle un replâtrage en touchant superficiellement ce qui pouvait l'être.

En informatique, il est vraiment très, très , très rare que l'on réécrive tout... Donc, si tu vas par là, 99,9 % des programmes qui tournent de part le monde ne sont que des replâtrages.

gastonj a écrit:

Cependant, l'amélioration est très sensible et justifiait bien l’appellation  "accélération".

Accéleration, n'as apporté aucune évolution technique.
Son but n'était juste que d'apporter quelques fonctionnalités complémentaires. Ce n'est pas la même chose....

Les avancées techniques ont eu lieu, d'une part entre le passage de FS9 à FSX RTM, et d'autre part avec le SP1 où ils ont touché en profondeur la gestion du moteur pour le rendre multicore.
Le SP2 lui, ne corrigeant que quelques bugs + ajout de l'implémentation DX10.
Ensuite, Acceleration ramène quelques fonctionnalités supplémentaires en s'appuyant sur cet ensemble.

Dernière modification par Ptipilot (01-12-2012 18:57:37)