[Index Software] Coin des développeurs :]

[Tugdual]

J'imagine qu'à cette époque, c'était de l'assembleur... 40 mnémoniques par page ...

Oui, de l'assembleur. Pour les amateurs,
le code source d'Apollo-11 est sur github ...

[Benoit]

Ils avaient quand meme un 'langage' de generation de code:
https://en.wikipedia.org/wiki/Universal ... s_Language

[Tugdual]

J'imagine qu'à cette époque, c'était de l'assembleur... 40 mnémoniques par page ...

Pour la photo (la pile de livres), je les soupçonne
d'avoir forcé sur la documentation et les annexes.
L'ensemble du code devait tenir sur 72 Ko (plus
exactement 36 Kmots) de mémoire morte, ce qui
tient dans un seul bouquin, même en assembleur.

Les 16 Ko en assembleur du système de mon C64
tenaient tranquillement sur un tout petit bouquin ...

Ils avaient quand meme un 'langage' de generation de code: [...]

Il me semble qu'à l'époque d'Apollo, c'était plus des
modèles qu'un véritable langage de programmation.

En tout cas, le code publié sur github semble bien être
de l'assembleur, qui plus est commenté manuellement ...
Peut-être ce code résulte-t-il d'une phase d'optimisation ?

[philigram]

J'ai connu des fous de l'ASM qui ont développé des jeux de bagnoles entièrement en ASM, sans autre méta-langage, juste avec un éditeur et un débuggeur.
Pas le choix, car il fallait optimiser. J'ai moi même écrit des fonctions 3D (facettes et texturage) en ASM car à cette époque aucun processeur graphique ou librairie pour le faire.
C'était en 1990. Le code Apollo était bien moins complexe à coté du code pour ces jeux. Alors j'imagine que dans les années 60, développer en ASM était le meilleur moyen. Il fallait en plus s'interfacer avec les divers instruments de la capsule et surement balayer des centaines de ports.

Par contre, la partie fonctionnelle devait être costaud. Les docs doivent aussi contenir les cahiers des charges, spécifications, conceptions, tests, exigences .... Le plus gros boulot est surement là, en amont, et pas dans le codage pur et dur.
Pour avoir travailler sur le Rafale ou l'A380, le codage (en volume, temps et ressources) représente bien peu par rapport au projet global.

[Benoit]

Je vois tout de même une différence significative entre développer pour un "produit" et pour un jeu video.

Dans le premier cas, il est rarement admis de tailler à la tronçonneuse dans les fonctionnalités pour tenir les délais, alors que c'est le b.a.-ba du deuxième.

[philigram]

Oui il arrive de tailler pour optimiser. Je parle surtout d'optimisation au niveau temps de calcul, et place mémoire. Et c'était principalement pour avoir un affichage fluide et donc l'optimisation se faisait surtout sur la partie calcul graphique (je rappelle sans aucune librairie, du genre DirectX, ni processeur dédié) Tout le calcul caméra, texture, éclairage, facettes ... était entière logiciel. Le moteur du jeux ne demandait pas autant de travail pour être optimisé.
Certaines partie de la simulation (tenue de route, rapports ....) étaient simplifiées.
Et en effet, ça ne peut pas être le cas pour l'Apollo ou le Rafale !

Je ne dénigre pas le travail remarquable des codeurs de l'époque. Je pense que la pile de doc n'est pas le code uniquement et que développer en ASM était naturel pour les développeurs de l'époque.
Dans le jeu, quand il a fallu passer au C, et utiliser Visual par exemple, ce fut source de tension. Des codeurs ASM pourtant âgé de 18 ans qui ne voulaient pas s'éloigner de la "machine" et passé leur temps à démontrer qu'ils étaient plus performant en codant en ASM que le compilateur C de l'époque.
Ils ont du reconnaitre leur erreur quand les processeurs ont permis le multi-thread et paralléliser certaines opérations.
Ils continuaient à développer la partie graphique en ASM malgré tout et la partie moteur en C.
Et à l'arrivée de Directx ou autres librairies utilisant les capacités de CGU, ils ont du se résoudre à abandonner l'ASM, qui a la facheuse tendance à être illisible et non réutilisable.

[Tugdual]

Moins on a le droit à l'erreur, plus on travaille
"avant", avec du formalisme, des modèles ...

Sur le sujet, une petite conférence intéressante
de Jean-Raymond Abrial (le site est une mine) :

• Spécification, construction et vérification de programmes :
  le parcours d'une pensée scientifique sur une trentaine d'années ...

[Benoit]

Je pense qu'ils n'avaient pas de Validation ou de Vérification à l'époque "antique" à la NASA.
Du coup les développeurs considéraient que ça faisait partie de leur travail de prévoir toutes les erreurs possibles.

Pas comme pour Mars Climate Orbiter...

[Bubu]

Ça y est ! J'arrive enfin à connecter les utilisateurs aux services Google Play !
Tentative de connexion automatique au début, connexion manuelle et déconnexion....
Et si la connexion échoue, proposer les résolutions !
Proposer d'installer Google Play Jeux, ou proposer de créer un compte Google Play Jeux.

En fait, nul besoin dans l'appli de demander à l'utilisateur de s'identifier, c'est automatique via Google Play Jeux.
Bon, il faut traficoter dans la console de développeur, mais ce n'est pas si compliqué.

Je vais enfin pouvoir passer aux services 'utiles' : sauvegarde en ligne, achats en lignes, bannière de pub (que j'enlève dès le premier achat).

[Bubu]

Je vois tout de même une différence significative entre développer pour un "produit" et pour un jeu video.

Dans le premier cas, il est rarement admis de tailler à la tronçonneuse dans les fonctionnalités pour tenir les délais, alors que c'est le b.a.-ba du deuxième.

Dans le premier cas, on est dans du temps réel strict.
On ne peut pas se permettre de mettre aléatoirement "Now loading, please wait". Il pourrait y avoir mort d'homme. (pour une mission spatiale, ou même pour un avion)
Et il faut prouver mathématiquement le code.

Dans le second cas, c'est plus souple.
Si ça met du temps à charger, ou si ça saccade, on y est pour rien ( ) : Achetez un meilleur matériel !

Après des problématiques existent pour les deux approches, et sont tout autant difficiles à résoudre.

[EDIT] Pour le premier cas, je prends en exemple le cas d'Apollo pour lequel on utilise le temps réel strict (ou dur), mais il y a aussi des programmes en temps réel "mou" qui répondent aux mêmes critères que tu as donné.

Pour l'infographie :
Pour les jeux, on utilise la rasterization. (Remplissage de polygones)
Pour les films, on utilise le lancer de rayon. (Pour un rendu photoréaliste)

Le lancer de rayon est infiniment plus simple que le rendu en rasterization.
Pour des raisons de performances, on utilise la rasterization dans les jeux. Techniquement c'est beaucoup plus compliqué, mais au moins c'est utilisable en temps réel.
Le lancer de rayon est très couteux en performances. Et de nos jours impossible à utiliser en temps réel pour rendre une scène avec un framerate correct.

(Mais on s'en y approche. )

[Bubu]

Les démarches entre le lancer de rayon et la rasterization sont opposées.
En rasterization, on part du pixel qu'il faut colorer.
Dans le lancer de rayon, on part d'un rayon entre l'origine (de la vue) et un certain pixel sur l'écran, pour voir ce qu'il touche.
On cherche le polygone, au lieu de l'avoir en temps qu'objet à rendre.

Pour la rasterization, on énumère simplement les polygones du mesh, et on les remplis.
En lancer de rayon c'est l'inverse, on ne sait pas quel polygone on va toucher.
Il faut chercher quel polygone est touché, et où exactement.

On comprend vite du coup pourquoi c'est aussi gourmand en performances.

Admettons qu'on ait un écran 1024 x 768 en résolution.
Ça fait presque 800 000 pixels à colorer.
Maintenant admettons qu'il y ait 1 000 000 de polygones dans la scène.

Naïvement, il faudrait lancer du coup 1 000 000 de rayons pour chacun des 800 000 pixels de l'écran, pour déjà savoir ce qui est touché par le rayon.
On voit normalement pourquoi ce n'est pas possible en temps réel.

(L'astuce réside en stoker les polygones non pas dans une liste linéaire, mais dans un arbre hiérarchique).

Un contre exemple : du lancer de rayon en temps réel (enfin c'est une technique hybride, qui mêle les deux (rasterization et raytracing). Notez que vous ne verrez pas ce niveau de qualité dans les jeux avant plusieurs années.


Le rendu accéléré 3D par les GPU est hyper efficace pour les surfaces non transparentes, et sans réflexions.
Mais dès qu'il s'agit de transparence, de reflets, et même de simples ombres, ça devient infernal.

Si on passe par les lancers de rayons, ça devient hyper facile. On perturbe le rayon selon la réfraction ou la diffraction, (on en lance d'autres). Un pixel est dans l'ombre ou pas ? Il suffit de lancer un rayon depuis la source jusqu'au point cible. S'il y a un obstacle, c'est ombré, et éclairé sinon. Donc fini les gros carrés pour les ombres, c'est précis au pixel près là!
La partie la plus technique est d'organiser la scène selon un arbre spatial (kd-tree ou octree) pour éviter d'avoir à énumérer toutes les surfaces de la scène. C'est utilisé tout le temps, même pour les films, sinon il faudrait des années pour obtenir la moindre image !

[Benoit]

Dans l'outil que j'utilise en ce moment (excellent, sa qualité n'est pas en doute), en plus de déclarer les variables binaires comme des variables binaires ils vont jusqu'à expliciter qu'elles doivent prendre des valeurs comprises entre 0 et 1.

C'est un logiciel allemand, comment continuer à lutter contre les clichés après ça.

[Bubu]

Cet exemple est très beau.
Il montre le potentiel de cette technique.
Par contre, il est irréaliste, dans le sens où il ne prend pas en compte les objets de formes arbitraires, définis pour leur surface par des polygones arbitraires.

[Bubu]

Toujours abruti par les services Google ....

Tout est asynchrone : la connexion au service, le chargement de la sauvegarde, la sauvegarde de la sauvegarde ....
Du coup je me retrouve à devoir synchroniser je ne sais même pas combien de threads ...
Alors il y a des alternatives synchrones (bloquantes), mais on ne peut tantôt pas les exécuter sur tel thread, tantôt sur l'autre sinon ça plante ....

Mais de base, j'arrive à connecter le client, et à sauvegarder et charger sa progression depuis le service. Mais ce n'est pas encore complètement au point.
Maintenant, c'est la structure de mon programme qu'il faut que je revoies.

J'ai du boulot encore ....

[Bubu]

Bon enfin, la sauvegarde sur les serveurs Google marche parfaitement.
Pour les histoires de threads, j'ai triché.
Pour toutes les méthodes problématiques, j'ai rajouté un booléen qui précise s'il faut bloquer ou non.
(La méthode joint() de Thread)
Du coup plus aucun problème.
Je lance la méthode sur un thread, et selon ce booléen, je bloque ou non.
Pour les sauvegardes critiques, je bloque (achat, déblocage d'aide, langue et son), sinon, je fais en arrière plan.
Le pendant, c'est que quand je bloque, ça freeze le programme, les animations. (enfin pendant 1/4 de seconde )

Il me reste à savoir si je garde l'ancien système de sauvegarde, local.
Ce qui permettrait à un joueur parano, de ne pas se connecter au service, d'avoir sa progression enregistrée quand même.