Interlocuteur 1 (00:00) Encore un petit peu. Je suis très, très heureux d'être ici pour vous donner un mot. Je vais dans les conditions particulières, sous le lieu de la technique, les manifestants contre nous ce matin. Donc je vais vous présenter mon talk à [translate:Another World], sur le saut d'architecture logicielle. Et donc, comme le montre, à neuf heures, [translate:Another World] c'est un jeu vidéo. Et...

Interlocuteur 1 (00:23) C'est un jeu vidéo qui est un culte. Culte, même. C'est un jeu qui est sorti au début des années 90, et qui a marqué toute une génération de jeunes gamins à l'époque. Et je vais vous parler de ce jeu pour deux raisons d'une part.

Interlocuteur 1 (00:40) On va porter un petit peu de culture générale sur le sujet. Mais aussi d'autre part parce que je vais vous parler de technique, et ce jeu est une architecture logicielle qui est extrêmement audacieuse pour l'époque.

Interlocuteur 2 (00:51) Et...

Interlocuteur 1 (00:52) On va avoir ça tout de suite. Donc en quelques mots, elles ont héros. Qu'est-ce que c'est ? Donc ça raconte l'histoire. Un scientifique qui fait des expérimentations avec un accélérateur de particules. Il y a un orage qui se produit. Et l'orage frappe son expérience particulière et projette l'expérimentateur dans un monde parallèle. Ça, c'est toute l'histoire.

Interlocuteur 1 (01:12) Là, c'est cet enjeu finalement qui va nous projeter dans une aventure dans laquelle on va devoir réagir, aider pour parvenir à essayer de s'échapper de ce monde. Donc, d'une façon un petit peu résumée, nous serons dans quelques mots. Qu'est-ce que c'est que c'est un jeu d'aventure action cinématique ?

Interlocuteur 1 (01:29) Qui est vrai. C'est vraiment fait penser avec une approche très cinématographique. C'est vraiment très, très innovant pour l'époque. Il a été imaginé, conçu et réalisé par [translate:Éric Chahi], donc qui est développeur, graphiste, et game designer extrêmement connu pour les anciens gamins comme moi.

Interlocuteur 1 (01:46) Puisqu'il a participé quelque part au début de l'aventure du jeu vidéo au milieu des années 80. Et il a été publié par Delphine Software, une ancienne maison de production que certains reconnaissent, et publiée par Interplay aux États-Unis.

Interlocuteur 1 (02:03) Et c'est un jeu donc qui a été commercialisé il y a tout juste 34 ans en novembre 1991. Ça date. Alors, c'est là où j'aurais normalement chez les super hack j'aimerais vous faire sourire.

Interlocuteur 1 (02:16) Mais bon, 1991 en groupe. C'est quoi c'était trente ans. J'étais déjà là.

Interlocuteur 2 (02:24) Et...

Interlocuteur 1 (02:26) Pourquoi j'aime vous parler d'un jeu qui date bien 34 ans. Pourquoi ? Parce que vous qui connaissez et me suivez.

Interlocuteur 1 (02:33) Vous savez très bien que j'aime les gros pixels. Mais pas que, j'aime aussi l'architecture logicielle et j'ai vraiment envie de vous partager un petit peu cette découverte parce qu'il y avait énormément de choses à dire sur ce jeu. Alors, le package du jeu, si je le résume d'un point de vue technique, le package du jeu, c'est un tout petit exécutable pour l'époque.

Interlocuteur 1 (02:52) Alors je parlais de la version Amiga DOS, mais il y a d'abord été développé sur un Amiga. J'arrive après. Donc le petit exécutable, c'est seulement 24 kilooctets d'exécutable avec les données et ressources qui pèsent au total 1,2 Mo.

Interlocuteur 1 (03:06) Donc c'est très, très peu pour l'époque pour un jeu qui est vraiment complet et une durée de vie qui est vraiment assez importante. Mais aussi que ce qu'il faut dire c'est que ça tient pour 16 bits. Et ceux qui connaissent, c'est que ça tient sur une seule disquette 3,5, 1,44 Mo, en tout.

Interlocuteur 1 (03:21) Faites le parallèle avec les jeux plus spécialisés d'aujourd'hui. Vous passez la nuit à télécharger un jeu de plusieurs centaines de gigaoctets. En termes de technique, c'est un jeu donc qui a pris une posture très, très différente de l'époque. On est beaucoup de pixels qui ont travaillé avec des sprites et cetera. Là, il a pris une approche qui, avec un moteur graphique vectoriel polygones, complet.

Interlocuteur 1 (03:41) Pour avoir de belles animations de belles cinématiques. Un moteur son compressé PCM. Donc ça veut dire avec des sources numérisées, ce qui est assez innovant pour l'époque, notamment pour les machines PC qui, pour la plupart, n'étaient pas équipées de cartes son, mais d'un simple haut-parleur. Et le choix de compressé n'est pas normal et revenait à l'heure. Et aussi, et c'est ça qui est très important dans l'architecture du cœur du jeu.

Interlocuteur 1 (04:07) C'est une machine virtuelle complète, avec un bytecode qui permet vraiment de gouverner tout le jeu. Et ça, c'est vraiment la partie très intéressante de la partie technique.

Interlocuteur 1 (04:18) Juste, je vais vous parler d'[translate:Éric Chahi], donc, quand je disais c'est un développeur. Je veux faire cette figure express avant qu'il arrêtait les films sur Twitter. Donc c'est développeur, graphiste et game designer qui a né en 1967 à Liéry, Henri Sonne. C'est vraiment un des pionniers du jeu vidéo en France. C'est un nom qui a vraiment marqué l'histoire du jeu vidéo parce qu'il a participé vraiment énormément de créations dans de nombreux jeux vidéo qui ont marqué en tout cas au moins les plus anciens, les plus anciennes d'entre nous.

Interlocuteur 1 (04:48) Et il a réellement vraiment été très, très actif de l'environnement quatre-vingt-quatre-vingt-dix et un peu moins depuis le début des années 2000. Il a commencé en 1983. Il avait 17 ans chez ASM Diffusion. En 1985, il a rejoint Oritech pour seconder ceux qui connaissent, étaient très présents sur la scène Atari.

Interlocuteur 1 (05:06) Ensuite, il a travaillé chez Infogrames pour travailler sur les productions Amiga et Atari ST. Et il a rejoint en 1989 Delphine Software sur lequel il a travaillé.

Interlocuteur 1 (05:18) Est-ce qu'il y a sur les Voyageurs du temps ? Donc c'est un jeu assez culte, avec Populus. Séc était le co-fondateur de Delphine Software. Et en fin 1989, il débute son travail seul qui durera deux ans sur [translate:Another World]]. Alors, seul quasiment il a travaillé sur l'ensemble du jeu sauf la partie musique.

Interlocuteur 1 (05:39) La création du jeu. Mais à c'est dommage que je n'ai pas de choses à vous montrer. Donc à l'époque, il a utilisé vraiment le top, le top de l'époque. C'est-à-dire il utilisait un Amiga 2000. Donc c'était une machine vraiment très orientée multimédia à l'époque avec des caractéristiques et des capacités sonores et vidéos qui étaient assez avancées. Donc un Amiga 2000 avec un mégaoctet de RAM et un disque dur de 20 Mo. La classe.

Interlocuteur 1 (06:06) Y a-t-il aussi un genlock ? Alors. Un genlock, c'est ce que c'est ? Un genlock, c'est un petit matériel qui vous allez connecter à votre ordinateur qui va vous permettre de d'afficher votre écran ou sur l'impression d'une image qui vient d'un caméscope, d'un magnétoscope et cetera. Dans les années 80, la mise en incrustation était très, très utilisée, notamment en télévision pour faire le petit trajet et le sous-titrage des émissions télé.

Interlocuteur 1 (06:28) Donc chaque fois que vous voyez une émission réalisée par accepter, souvent derrière c'est un Amiga avec un genlock sur lequel la média venait en surimpression imprimée. Les images. Un magnétophone à cassette pour capter les bruitages.

Interlocuteur 1 (06:43) Et c'est à peu près tout. Et ensuite c'est [translate:Éric Chahi]] qui a fait tout le reste. Pour la partie logicielle, encore une fois, il y a des choses que vous devriez voir que nous ne voyons pas.

Interlocuteur 1 (06:52) Il a créé tout un logiciel complexe qui lui a permis de créer le jeu. C'est-à-dire qu'aujourd'hui si vous utilisez, par exemple des moteurs de jeu comme Unity ou Unreal, vous avez un environnement complet qui vous permet de designer votre monde, de créer vos modèles 3D, de les intégrer et cetera. À lui à l'époque, il a créé un logiciel complet en GFAB Basic. Donc sur Amiga, qui va lui permettre donc de modéliser le personnage, de pouvoir créer son animation, de pouvoir décrire son bytecode avec sa machine virtuelle.

Interlocuteur 1 (07:20) Gérer les sons et cetera. Donc il a créé un environnement développement intégré complet pour pouvoir procéder à la réalisation de son jeu. Et il a utilisé en termes de technique, et j'en parlais tout à l'heure avec le genlock, je ne peux pas étudier la rotoscopie.

Interlocuteur 1 (07:35) Alors la rotoscopie, c'est ça, c'est prendre une image vidéo. Donc l'imprimer sur sa machine et ensuite on est traçait à la main avec des polygones, des personnages, un objet, et cetera. Et ça va lui permettre de faire théoriquement gagner du temps. De son propre aveu, il a dit que ça lui a pas fait gagner tant de temps que ça sur les animations.

Interlocuteur 1 (07:55) Mais c'était une technique déjà assez nouvelle pour l'époque de faire le rotoscopie pour un jeu à l'époque. Et évidemment, [translate:Éric Chahi]] n'est pas qu'un développeur mais c'est aussi un artiste. C'est quelqu'un qui a d'ailleurs commencé dans le domaine de la vidéo comme artiste, comme pixel art, et cetera. Donc il a créé vraiment l'intégralité de son monde en faisant des peintures, des croquis, des esquisses. Il y a ce qu'il a numérisé sur son Amiga, qui lui permet donc de pouvoir créer l'ensemble de ses niveaux.

Interlocuteur 1 (08:27) Je passe tout seul à ce que vous ne le voyez pas. Et là, je vais vous parler du moteur du jeu en tant que tel. Alors on va vraiment rentrer dans le vif du sujet. Pardonnez-moi d'avance s'il y a des points extrêmement techniques. Je vais réfléchir. Si j'irai trop vite qui revient. Ça risque, OK, super.

Interlocuteur 1 (08:47) Non, le moteur ça me saoule seulement fini par d'arriver et c'est papier.

Interlocuteur 2 (08:53) .

Interlocuteur 1 (08:54) Le moteur du jeu en tant que tel, une architecture simple mais qui est vraiment relativement très efficace. Alors je vais essayer de vous la décrire avec des schémas. Tout au-dessus vous avez une boîte c'est la green, la machine virtuelle. C'est vraiment le cœur névralgique du moteur du jeu vidéo.

Interlocuteur 1 (09:10) Et c'est une VM dite généraliste. C'est-à-dire on va pouvoir utiliser cette VM avec une forme d'assembleur pour pouvoir décrire toutes les actions avec un langage pour pouvoir dicter le comportement du jeu. Il y a eu cette approche pour une bonne raison : c'est que ça lui a permis d'accélérer le développement du jeu. Et je vais détailler la VM juste après.

Interlocuteur 1 (09:30) Juste en dessous vous avez une boîte, ce sont les ressources. Les ressources de jeu. Alors les ressources se sont les polygones. Ça va être quelques images qui sont utilisées puisque l'ensemble du jeu est globalement vectoriel. Ça va être les sons. Ça va être le bytecode qu'on va charger dans la VM et cetera. Quand il en est un gestionnaire de ressources qui permet de lire, je vais aller chercher sur le disque.

Interlocuteur 1 (09:51) Sur le disque dur, sur la disquette les ressources dont j'ai besoin. On décharge en mémoire et c'est la VM qui va les exploiter. Et en dessous vous avez globalement trois boîtes : la partie vidéo, la partie audio, la partie entrée.

Interlocuteur 1 (10:01) Et sous la partie audio vous avez deux sous-modules, deux sous-modules qui sont la gestion du son, la gestion des logiques. Le tout, ce qu'il faut savoir c'est qu'en termes de l'architecture à l'époque, on travaille sur l'Amiga, qui pourrait aussi dire n'avait pas de système d'exploitation du sang où on l'entend aujourd'hui. L'Amiga avait un système d'exploitation qui était très, très riche. Le DOS aussi. Mais ce qu'il faut savoir c'est que pour les jeux vidéo d'époque, le tout c'était de taper directement dans le hardware.

Interlocuteur 1 (10:27) Donc tout ça va s'appuyer sur la couche d'abstraction hardware qui va permettre de dire je vais aller dessiner une image soit sur ma carte vidéo, soit sur la carte vidéo du Amiga ou de l'Atari ST. Certains ou toute autre machine. Pour en fait il a toute une petite couche d'abstraction du hardware. Que le moteur en tant que tel est ce qu'écrire directement dans le hardware qui est très conflictuel avec les systèmes d'exploitation de nos jours. Où si vous essayez d'aller taper directement dans du hardware, vous allez vous faire insulter par votre OS.

Interlocuteur 1 (10:59) Alors je passe tous ces slides. Je vais vous parler des ressources très rapidement avant de vous parler d'alien. Pourquoi ? Parce que les ressources est un petit peu, j'irai la pierre, une des pierres angulaires du moteur. Voilà. Ça c'est le bon point. C'est que sans ressources vous n'avez pas de jeu.

Interlocuteur 1 (11:17) Les ressources elles sont constituées de sept types différents. J'en parlais tout à l'heure. Vous avez les sons. Vous avez les musiques. Vous avez les images. Vous avez les palettes de couleur. Ce qu'il faut se rappeler c'est qu'à l'époque on n'avait pas des machines qui étaient capables d'afficher des millions de couleur à l'écran, 16 millions de couleurs ou 256 couleurs et cetera. Donc on gérait avec des palettes. L'écrit. Donc ils sont le bytecode qu'on va chercher dans la VM. Les polygones. Les différents niveaux. Et une section qu'on appelle un polymorphe. Romain. C'est-à-dire des polygones qu'on va utiliser.

Interlocuteur 1 (11:46) Bonjour pour factoriser un petit peu certains objets. Typiquement avoir les cheveux d'un personnage ou un objet particulier qu'on va retrouver dans plusieurs nuits. Les ressources en fait ne sont pas accessibles directement par l'engine. Si c'est le truc.

Interlocuteur 1 (12:04) Prends des documents. Les ressources ne sont pas accessibles directement. En tant qu'être des fichiers sur le disque. Qu'il faut savoir c'est que ces ressources en fait elles sont compilées dans un, dans plusieurs fichiers. Dans 13 banques de données. Et ces 13 banques de données, y a un 14ème fichier qui est un fichier index qui va permettre de référencer toutes les ressources du jeu.

Interlocuteur 1 (12:23) Donc avec leur position, avec le numéro de banque dans laquelle elles sont, leurs positions dans la banque en termes de sept. Est-ce qu'elles sont ? Quelle taille elles font et cetera. Toutes ses ressources ont été complétées avec la suite logicielle que [translate:Éric Chahi]] a créée, assemblée, compilée et mises dans différents fichiers. Alors pourquoi dans 13 banques différentes ? Parce qu'à quelle contrainte de l'époque, notamment des machines qui n'étaient pas dotées de machines à faire de capacités. On peut pas forcément créer des fichiers qui étaient énormes. Donc le fait de les répartir dans des 13 banques différentes c'était plutôt une solution technique pour un problème technique.

Interlocuteur 1 (12:56) Et donc ce fichier d'index globalement il va être chargé. Il va charger au démarrage du jeu. Et dès qu'un niveau vous êtes lancé, on va dire j'ai besoin de telle ressource. La ressource mémoire. Il va les regarder dans le fichier d'index. Cette ressource noir. Il va te regarder à une position. Et il va la charger. Et là de revoir du code avec l'énumération d'une ressource mais vous ne le voyez pas. En gros les ressources ce qui est important c'est que ça avancer c'est que dans le fichier d'index vous allez avoir un état d'une ressource. Est-ce que cette ressource elle est donc chargée en mémoire ?

Interlocuteur 1 (13:27) Est-ce qu'elle est déchargée ? Est-ce qu'elle est requise et cetera ? Cet état va permettre donc de manipuler les ressources et de les charger à la demande lorsque c'est nécessaire. Vous avez un type de ressource parmi les sept types dont je vous ai parlé.

Interlocuteur 1 (13:39) Vous avez donc le numéro de banque auquel elle était référencée et l'offset dans la banque. Et vous avez une taille. Et notamment on a deux informations sur la taille. On a une taille qui s'appelle packsize et une taille qui s'appelle pnp packsizes.

Interlocuteur 1 (13:52) Ça te vraiment eu l'agence. C'est une certaine recherche. Sont comprimées pour gagner encore plus de place. Et elles sont comprimées avec un algorithme qui s'appelle Pak Killer.

Interlocuteur 1 (14:06) Pak Killer qu'est-ce que c'est ? J'ouvre une petite parenthèse.

Interlocuteur 1 (14:06) Pak Killer c'est un algorithme qui est assez répandu sur la scène Amiga dans les jeux Amiga ou les démos. Super. Les couleurs sont archéologie mais on va s'en contenter.

Interlocuteur 1 (14:24) Voilà. Donc euh c'est mieux que de rien voir. Donc assez répondu sur la zone des médias c'est un algorithme qui est relativement efficace plutôt économe en mémoire. On voyait les mêmes des parents c'est super.

Interlocuteur 1 (14:36) C'est fasciné à implémenter, ça c'est peu le dire. C'est un peu d'âge en termes d'implémentation. C'est un codage antérieurement fixe et non adaptatif. On utilise une fenêtre glissante. Ça peut vous expliquer tout de suite après ça va vous paraître plus clair. Et il fonctionne à l'envers. Globalement son fonctionnement c'est vous prenez un buffer.

Interlocuteur 1 (14:56) À la fin. À la vous avez les données compressées que vous mettez au début de votre buffer. Voilà voyez c'est juste le rectangle de plus ou moins grande sans forcer de couleur. Et à la fin lorsque l'algorithme va travailler il va décomprimer les données de la fin.

Interlocuteur 1 (15:10) Vers le début ce qui a pour avantage d'être très économique. Pourquoi ? Parce que vous n'avez pas besoin de de buffer. On n'a pas besoin de buffer pour les données compressées et d'un buffer pour les données compressées.

Interlocuteur 1 (15:23) On va utiliser un seul buffer. Par contre on va travailler à l'envers. Et ça c'est extrêmement malin comme algorithme.

Interlocuteur 1 (15:29) Et à la fin donc vous retrouvez votre buffer. Par exemple que vous l'image.

Interlocuteur 1 (15:37) En termes d'implémentation voici mon implémentation. C'est plus de la section décodage. Donc voyez ça tient en peut-être hein sur la hauteur d'une base donc on retrouve sa fonction avec un système de code en haut et en fonction du code qu'on le récupère on va s'on sait combien de bits on va lire derrière et on va pouvoir avoir le fait de chercher pour recopier des données qu'on a déjà décompressées. Donc ça c'est plutôt malin.

Interlocuteur 1 (15:58) Et sur quelques quelques fonctionnalités de base on a des des fonctions qui vont lire un certain nombre de bits dans le flux de bits qu'on a dans la partie compressée. Et donc récupérer ces bits suivants. Donc là globalement l'algorithme de décompression en peut-être 200 lignes de code vous avez l'algorithme de décompression qui a écrit la destination. C'est beaucoup plus mais ça peut n'importe quel langage.

Interlocuteur 1 (16:20) Je ferme cette petite parenthèse et en termes de ressources voici quelques statistiques. Donc on voit que les sons c'est là où il y a plus d'à 7 et ça occupe globalement 40% du total des athlètes parce que le son c'est très consommateur en ressource. Donc c'est celà on a dû plus de compressions à un gros avantage parce qu'elle permet d'avoir un gain de 16%.

Interlocuteur 1 (16:40) Les musiques elles sont comprimées et on a un bien de compression de 89%. Ça se plaît pas mal et cetera et cetera.

Interlocuteur 1 (16:46) Et on voit que sur l'ensemble globalement on a un total utilisable donc de date de un mégaoctet un un mégaoctet ou un paquet en non paquet 1,7 Mo c'est plus que le 1,7. Et on a un gain total de compression de 33%. Ce qui est plutôt assez intéressant pour un jeu de cet ampleur.

Interlocuteur 1 (17:04) Maman je vais vous parler de la machine virtuelle puisque c'est que le réacteur de cette architecture. Donc la machine virtuelle en bref.

Interlocuteur 1 (17:14) Donc c'est une architecture de type Harvard. Alors architecture de type Harvard ça signifie que la mémoire de code est différente et n'est pas au même moment que la mémoire de données. C'est-à-dire que vous le code ne peut pas se réécrire en lui-même. En termes de code, la mémoire de données s'est pareille. C'est des stockages de données en big-endian.

Interlocuteur 1 (17:32) Ça signifie que les octets de poids fort sont stockés avant les octets de poids faible. Quand vous utilisez un PC c'est plutôt l'inverse. Ça les octets de poids fort sont stockés avant les opérateurs. Alors l'approche big-endian elle s'explique par le fait que [translate:Éric Chahi]] a développé son logiciel sur un Amiga qui est beaucoup doté donc d'un microprocesseur Motorola 68000 qui lui travaille en big-endian. Donc ça c'est un choix.

Interlocuteur 1 (17:55) C'est une machine virtuelle qui contient, qui est capable de gérer 64 threads en parallèle avec 256 registres et une pile. Alors c'est 64 threads mais attention c'est en parallèle pas réellement. C'est une multi-threading coopérative. C'est-à-dire que chaque thread lorsqu'il travaille il bloque tous les autres.

Interlocuteur 1 (18:11) Il fait son travail et une fois qu'il a fini son travail il va rendre la main pour donner la main à un autre thread. Mais on a 64 traitements parallèles qui peuvent cohabiter et donc gérer l'intégralité de la logique du jeu. On a cinq groupes d'instructions.

Interlocuteur 1 (18:24) 29 instructions de base et 219 au code au total. Donc en gros si je vous montre à quoi ça ressemble la machine virtuelle ça ressemble à ça. Nous avons 64 threads, 256 registres. Alors les registres voyaient ça comme 256 variables de 16 bits utilisables pour gérer l'intégralité du jeu.

Interlocuteur 1 (18:42) Pas un octet de plus. Donc vous avez globalement 512 octets de mémoire vive disponible pour cette machine virtuelle pour gérer l'intégralité du jeu et la logique du jeu. Et c'est là où il faut être malin dans la programmation des différents scripts pour pouvoir exploiter cette mémoire comme bien.

Interlocuteur 1 (18:58) Une pile, alors chaque fois que vous faites un appel à une fonction, ça elle va permettre d'empiler les adresses d'appel et les adresses de retour. Et en dessous on voyait que la machine virtuelle communique avec le système de ressources et le bytecode est chargé directement dans la partie RAM. Alors il serait pour aller vous en parler ?

Interlocuteur 1 (19:16) Plus précisément les threads. Voici comment ça fonctionne. Le moteur du jeu donc initialise la machine virtuelle. Il va charger du bytecode en mémoire dans une zone de mémoire particulière. Et ensuite il va donner la main au premier thread.

Interlocuteur 1 (19:29) Et le thread 0 donc à gauche donc le thread 0 il va initialiser un certain nombre de ressources. Il va dire chargeons la ressource du niveau 2, chargeons la ressource du 0, et cetera. C'est accepter rapide. Va avoir une certaine logique guerrière qui peut exécuter jusqu'à il est arrivé à une certaine instruction qui s'appelle les guildes. À ce moment-là le thread a décidé qu'il avait fini son travail en tout cas pour ce moment-là. Et il va donner la main au thread actif suivant. Typiquement en fait là au début on a initialisé le thread 2, on a initialisé le thread 9.

Interlocuteur 1 (19:59) On va donner la main au thread 9. Au thread de parents. Le thread 2 va exécuter son code. Il va faire ses initialisations. Il va faire son travail et cetera jusqu'à arriver à une fonction qui s'appelle guide aussi. Guide il va donner la main aux threads actifs sur qui restreint le 9. Et cetera et cetera jusqu'à arriver au thread 63.

Interlocuteur 1 (20:17) Une fois qu'il est arrivé au thread 63 et le thread 63 a terminé, alors la machine virtuelle rend la main au moteur du jeu. Le moteur du jeu va faire quelques petites actions notamment afficher des images à l'écran, lire les entrées sur les périphériques d'entrée. C'est faire et cetera. Et ensuite il va recommencer une boucle. Il va redonner la main au thread 0 et cetera.

Interlocuteur 1 (20:37) Va gagner le thread 0 en tout cas le premier thread actif. Ici ce 0. Et ça pourrait te servir de 0, 1 ou le thread de numéro 10. Donc ça c'est un fonctionnement qui est plutôt astucieux pour pouvoir simuler, entre guillemets, la parallélisation de tâche dans un jeu vidéo à l'époque où les processeurs étaient peu puissants, pas multitâches, pas noëls multitâches et cetera. On n'a pas les caractéristiques que l'on encourage.

Interlocuteur 1 (21:02) Sur les derniers registres donc je vous disais on a à nos dispositions 256 registres, 78... Donc 512 octets de mémoire. La plupart de ces registres sont à usage libre par la machine virtuelle et par le code du jeu vidéo.

Interlocuteur 1 (21:15) Mais certains d'entre eux ont une signification particulière. On a par exemple un petit peu... Pardon on a par exemple sur la partie droite ce qu'on voit qu'on a certains registres. Quoique... Là et cetera.

Interlocuteur 1 (21:32) En fait c'est là. Chaque fois que le moteur du jeu va lire les entrées il va prendre la valeur de les entrées et dire Ben par exemple le joueur la parfois appuyé sur le bouton haut de son clavier ou sur la flèche bas ou sur le bouton d'action. Et donc il va venir populer une certaine valeur dans ces registres qui sont des registres de communication entre le monde du hardware, le non du moteur.

Interlocuteur 1 (21:52) Et le monde du jeu lui-même. Je crois que à chaque tour de boucle chaque fois qu'on va donner à la main à la machine virtuelle la machine virtuelle ou ça que le moteur lui-même quand il avait récupéré la main aura peut-être populé certaines valeurs qu'il ira lire ?

Interlocuteur 1 (22:07) Et ensuite exploitée donc on a certaines valeurs qui sont intéressées comme le randbottom, le rand seed qui permet de m'initialiser le générateur de nombres aléatoires. Donc on a la lecture des actions et on a quelques si on regarde sur la partie on a le type de plateforme sur lequel on est ? Est-ce qu'on est sur DOS sur Amiga sur Atari ST et cetera ?

Interlocuteur 1 (22:28) Et quelques quelques variantes qui servent à la protection du jeu qu'il est et à cette aisée de faire sauter. Le bytecode.

Interlocuteur 1 (22:37) Le bytecode donc il se va représenter des instructions. Chaque instruction doit avoir un ou plusieurs représentants. Pour une instruction par exemple l'équivalent d'un lift il peut avoir plusieurs op code représentant son exadécimal différents.

Interlocuteur 1 (22:52) Chaque code est au décodable globalement sur un byte. Chaque instruction chaque occasion peut avoir des paramètres éventuels. Et ce qu'il faut savoir c'est que d'un point de vue théorique des jeux d'instruction ce n'est pas un jeune instrument.

Interlocuteur 1 (23:05) Dans le sens où on n'a pas un système de décodage qui nous permette de dire si je suis sur tel op code alors je sais déduire d'avance que j'adresse la mémoire comme signé ou comme ça voilà donc c'est un op code qui a été vraiment écrit apparemment pour des humains et non pas pour des machines. Et il est composé de cinq groupes d'instructions. Je me disais tout à l'heure les instructions de store, qui permettent donc de manipuler les variables. Les instructions de arithmétique et de logique globalement bah c'est faire des additions des soustractions et cetera.

Interlocuteur 1 (23:36) Les branches et les appels. La gestion des threads et la gestion des ressources. Les opcodes ont termin de représentation dans l'espace des opcodes dont vous allez. Vous avez la possibilité d'avoir 256 op code en tout. Je vous ai dit tout d'abord on a 219 à nos dispositions. Pourquoi ça fait bon. Raison c'est que les op codes généraux on va dire vont être représentés tout en haut. Là vous les voyait sa vie cet aire à dradri à drogue et cetera.

Interlocuteur 1 (24:02) Donc en fait tous les autres codes ont été mis comme ça dans un ordre qui semble être un petit peu bizarre. Pas forcément très logique. Mais on a on va retrouver donc nos 29 op code disponibles en haut qui sont les op codes. Vous validèrent plutôt géniaux ceux qui vont nous permettre de manipuler variables et ressources les threads et cetera.

Interlocuteur 1 (24:18) Alors ce qu'il faut savoir c'est que pourquoi ce qu'ils ont été organisés comme ça de façon pas très logique parce qu'on voit d'avoir satisfi cette aire ensuite on a ad rad i. Pourquoi il y a ce qu'il n'a pas donné dans le même sens les opcodes pour ça t'es bonne raison c'est qu'il le moteur de décodage de code des richesses à l'époque fonctionner avec des fichiers... Et il a calculé dans les le bit-pop qui générer statistiquement qu'elles étaient les opcodes les plus fréquents.

Interlocuteur 1 (24:40) Et donc les occasions les plus fréquents sont plutôt en début et il est moins fréquent en fin de. Et on a des autres codes un peu particuliers on voit ainsi poli un et poli 2.

Interlocuteur 1 (24:50) C'est-à-dire que pour afficher des polygones. Eh bien ce sont des opcodes spécifiques qui occupent un espace particulier donc on pourra dire à la seringue espace qui est gâché par chien polygone pourquoi j'ai pas un heureux mode et pourquoi l'argent j'en ai ? Jani 6 0 4 ou 32. Eh bien pour la santé de mon raison c'est que ça va lui permettre donc je vais m'expliquer juste après de pouvoir afficher des polygones en lui donnant des paramètres en fonction de l'opcode que l'on va appeler dans la grille de code.

Interlocuteur 1 (25:17) Ça va vous paraître un peu plus clair tout à l'heure. Nous clés au code de l'hôtel store. Globalement on a on a possibilité de mettre une valeur dans une variable. Entre un registre et un autre registre ou de mettre une valeur immédiate vers dans un registre. Sur l'arithmétique écologique. Ça vous permet de calculer et manipuler les limites globalement faire des additions entre des registres faire une soustraction entre un registre et une valeur immédiate faire une soustraction faire une logique OU logique ET un décalage vers la gauche et un décalage vers la droite.

Interlocuteur 1 (25:49) Rien qu'avec juste ces instructions-là vous êtes capable de faire n'importe quel programme globalement. Vous avez accès à tout donc rien qu'avec tout ça vous pouvez faire des multiplications vous pouvez faire des divisions et cetera. Bien sûr c'est plus c'est plus compliqué ça nécessite pas mal de codes.

Interlocuteur 1 (26:03) Mais vous pouvez globalement tout faire. Vous avez la gestion des branches et des appels. Donc vous pouvez dans votre code machine des branches de code machine.

Interlocuteur 1 (26:12) Appeler une adresse particulière avec Jennifer une adresse particulière je paye une adresse particulière en fonction d'une condition particulière. Voilà on me propose en a plusieurs types de conditions. Et vous avez une instruction si qui permet qui s'appelle des branches donc qui vient de de la scène de 68000 Amiga notamment qui permettent de dire des crémants and branch. Donc en fait il va décrémenter une valeur et si la valeur atteint 0 il va jumper à une vraie particulière du code.

Interlocuteur 1 (26:41) On a le coût d'une adresse globalement l'appel d'une sous-fonction et on a le retour de la souffrance. Je vais juste faire un tissu sur l'instruction de jump. L'instruction de jump c'est l'une des instructions les plus complexes de la machine virtuelle.

Interlocuteur 1 (26:54) C'est instruction de jump donc on voit qu'au code qui permet d'appeler ces 0x60 donc en exadécimal et derrière on va lui passer un paramètre et ce paramètre en fonction des bits qui sont non à nous dire quoi exécuter comme le saut conditionnel. Ce saut conditionnel on va dire on va en fait si on prend les Beatles si c'est 7 on va on va inquiéter 2 valeurs et ça va nous donner quelle est l'opération à effectuer ?

Interlocuteur 1 (27:20) Est-ce qu'on va comparer un registre avec une valeur immédiate 8 bits qui vient juste derrière ? Est-ce qu'on va comparer un registre avec une valeur immédiate 16 bits derrière ? Est-ce qu'on va comparer un registre avec un autre registre ?

Interlocuteur 1 (27:30) Et cetera. Et les trois derniers bits de du variant donc des bits 0 1 eux vont nous donner quelle opération de comparaison vous effectuez. Est-ce que ça va être on va faire une opération de comparaison dans le sens à ce que c'est égal pas égal ? Est-ce qu'on va vérifier si deux valeurs ou si une valeur est.

Interlocuteur 1 (27:46) C'est supérieur à un autre supérieur égal inférieur ou égal et cetera. Donc ça c'est une instruction qui qui a un peu la peau complexe presque à implémenter. Et donc c'est cette opération derrière le variant va retrouver les paramètres qui voyent déduits donc des bits qui sont d'un partage. Parvin.

Interlocuteur 1 (28:04) Est-ce que derrière la rivière tu au 16 bits ? Ou des numéros d'aujourd'hui sur lesquels on effectue les comparaisons ? La gestion des threads donc on a de quoi démarrer un thread en lui disant démarre le thread du numéro 42 à telle adresse.

Interlocuteur 1 (28:19) Dans la mémoire. On peut réinitialiser un thread pour le mettre dans un état particulier. On peut passer un thread on le guide. Dont je vais parler tout à l'heure où on peut dire que ce thread sera déterminé. Je fais un rider et je le serai. De ce suicide plutôt. La gestion des ressources je vais aller assez vite là dessus il y a de quoi charger les ressources de passer d'une palette à une autre. De changer de page dans laquelle on va dessiner. De remplir une page avec une valeur. Et une page vidéo. Le jean dan de copier une page vidéo vers une autre page vidéo d'afficher une page d'imprimer des caractères à l'écran.

Interlocuteur 1 (28:55) De jouer un son de jouer une musique de dessiner un polygone avec certains certains 2 paramètres ou de dessiner un polygone avec moins de paramètres. Ça encore une fois significat d'optimisation des ressources qui nous permet d'avoir deux variantes pour les ciné des polygones en fonction des paramètres dont on a besoin.

Interlocuteur 1 (29:14) Et l'instruction poli voilà je vous montrerai tout à l'heure. En fonction de weska se place dans l'espace de représentation des zones codes eh bien vous voulez si on prend le code 0x68 par exemple donc ça 28. Eh bien on va aller lire les 8 bits, ce qui s'en haut donc forcément il y a des bits. En fonction de l'opcode le premier bit va valoir le 0 au premier ministre un en fonction 2 et on va avoir la position du polygone à laquelle on veut le dessiner.

Interlocuteur 1 (29:44) Donc les bits synthécaires vont nous donner qui est le contrôle sur la position X. Les bits 32, ce contrôle sur la position Y, est le bit 10 sur le zoom qu'on va effectuer à celui-là. Bon.

Interlocuteur 1 (29:52) Et derrière on va retrouver l'opcode de la mémoire dans les ressources où est stocké le polygone ou la hiérarchie polygone ? Tout à l'heure. Et sa position dont l'espace de représentation de l'écran.

Interlocuteur 1 (30:04) Où est-ce qu'on va déciner ce polygone et à quel niveau de zoom ? Donc ça c'est assez puissant comme une instruction. Et donc en fait toutes les toutes les parties un diamètre qui sont positionnés derrière mon poly polygone polyzoom leur variante va être déterminée par le premier octet qui va nous donner en fonction des bits bah comment m'interpréter les paramètres qui sont donnés.

Interlocuteur 1 (30:24) Donc c'est assez complexe un paiementé mais ça permet une énorme souplesse d'une très grande souplesse dans l'affichage des polygones à l'écran. L'instruction poly 2 donc c'est une instruction qui est plus simple qui permet juste de dire bah voilà. Le premier miniature un. On va avoir un opcode dans la mémoire.

Interlocuteur 1 (30:40) Où trouver le polymoun de hiérarchie polygone et ensuite 2 paramètres ? Si vous ne permettez de dire à quelle coordonnées j'affiche ce polygone ? Donc ça ce sont des instructions qui sont un peu spécifiques.

Interlocuteur 1 (30:53) Maintenant je vais vous parler du sous-système vidéo. Alors le sous-système vidéo c'est le deuxième système le plus important du moteur. Le système vidéo va travailler avec quatre pages graphiques dans lequel il va pouvoir dessiner. Alors il y a une page. La page de la traçage qui est affichée à l'écran c'est ce que vous voyez. Et vous avez trois pages qui sont cachées qui vous permettent de d'imprimer des choses dedans d'effectuer des opérations non et ensuite de pouvoir les afficher les côtés. Donc globalement vous allez nous retrouver comme ça donc la page 0 par exemple c'est ça qui est affichée à l'écran.

Interlocuteur 1 (31:23) Et les pages 1 et 2 c'est celles qui en arrière-plan en train de préparer pour l'affichage supérieur. Et je vous parlais des polygones tout à l'heure et en fait quand on affiche des polygons on le voit juster un polygone.

Interlocuteur 1 (31:34) On peut afficher un polygone et maintenant une hiérarchie polygone où là j'ai bougé cette hiérarchie polygone.

Interlocuteur 1 (31:41) En fait quand vous êtes dessiner un polygone ce polygone peut avoir des propriétés qui sont par exemple de nos couleurs. Et il a potentiellement des enfants. Et donc il a créé tout un système d'arborescence de plus polygos qui permettent donc de dessiner des des objets complètement. Typiquement un personnage vous allez avoir le polygone qui représente entre guillemets une sorte de polygone qui présente le personnage qui va être composé de pleins sous-polygones qui vont être les bras la tête les jambes et cetera.

Interlocuteur 1 (32:09) Donc en fait pour afficher un polygone on va afficher le parent puis les enfants et on va les parcourir l'arborescence de polygones jusqu'au bout. Mais afficher ça à l'écran et les coordonnées sont pilotées par les instructions que j'ai présentées juste avant qui ont permis de dire affiche-moi ce polygone de cette fierté polygone à telle coordonnées avec tel niveau zoom. Donc ça ça permet d'avoir quelque chose qui est assez puissant.

Interlocuteur 1 (32:30) Et contrôle-t-elle les polygones pour.

Interlocuteur 3 (32:45) Maintenant.

Interlocuteur 1 (32:53) Ce serait vraiment des politiques de la triangle. Des polygones. Et selon euh. Avant de faire de quoi vous vous permettre de dessiner des polygones.

Interlocuteur 1 (33:16) Avec la seule contrainte c'est que ces polygones vont avoir un nombre égal de points. Pourquoi ? Parce que [translate:Éric Chahi]] a trouvé une façon d'afficher des polygones et de les dessiner à l'écran qui permettent de lui voir une argumentation qui est très simple. Puisque dessiner les polygones complexes d'un point de vue la population c'est toujours compliqué. Donc il a procédé à certaines simplifications.

Interlocuteur 1 (33:36) Donc ces polygones lorsqu'ils sont définis dans la mémoire ils ont chacun un nombre paire de points. Et donc ils sont aussi dans les paramètres de ce qu'on appelle une bounding box qui nous permet de savoir le polygone inscrit dans une boîte.

Interlocuteur 1 (33:49) Et cette boîte va nous permettre de tester si le polygone il est dans l'écran ou hors de l'écran. Donc si on va faire un rendu où il est le rendu de ce qu'on ignore à l'écran. Et ensuite comme je disais chaque point va avoir un point en face de lui par exemple je prends le point là.

Interlocuteur 1 (34:07) Imprime donc ça va être quoi ce que ces points le sommeil. Si on prend le point F on va projeter sur le segment face au point F. On va créer un point intermédiaire le point B le point Bprim le point E, le point Eprim et cetera.

Interlocuteur 1 (34:19) Ce qui fait que les polygones ça va nous permettre de pouvoir dessiner à chaque fois avec la partie basse du pouvoir quelque chose qui est une droite systématique. C'est une la modification est intéressante d'un point de vue algorithmique. Ça permet de dessiner de Mulhouse très vite d'avoir un algorithme de rendu extrêmement.

Interlocuteur 1 (34:34) Ça risque vraiment extrêmement rapide. Et donc on va dessiner les polygones comme ceux-ci. Ligne par ligne. Jusqu'au bout. Voici à peu près comment on fonctionne le rendu des polygones.

Interlocuteur 1 (34:46) Donc c'est quelque chose qui n'est pas standard dans le rendu d'un polygone habituel mais qui permet de gagner énormément d'avoir un cocktail extrêmement compact. Et le packlaw est entendu. En fait ce qu'il faut savoir c'est que les scènes sont rendues de l'arrière vers l'avant. Quand je disais tout est polygone rendu il doit aussi dessiner les décors avec ces polygones. Donc il me tisais pour cela l'algorithme du peintre pour dessiner de l'arrière vers là.

Interlocuteur 1 (35:09) Donc les scènes une fois que les scènes et les décors sont rendus, ils veulent mettre en cache dans une page. Donc plutôt que de rendre les scènes systématiquement et de les dessiner systématiquement puisque certaines scènes peuvent avoir plusieurs centaines de polygones ce qui coûte du temps machine il va aller dessiner une fois dans une page. Et ensuite il valait mettre en cache et.

Interlocuteur 1 (35:25) Arrivé utiliser cette page comme euh comme accélérateur en matière de rendu pour la fois suivante et de remboursement sur cette tâche après uniquement des personnages. Voilà. Et juste pour vous montrer un petit peu le rendu dans ses levés du peintre alors moi j'ai réécrit le moteur du jeu. Ce qu'il faut savoir j'ai réécrit intégralement le moteur de la machine virtuelle et ça c'est issu du moteur de jeu j'ai le ralenti le rendu pour vous montrer un petit peu ce que ça donne.

Interlocuteur 1 (35:52) On voyait que là il va dessiner tous les polygones pour enseigner le décor du premier niveau. Et ensuite c'est ce décor-là qui va être utilisé. On inscrit 5 minutes.

Interlocuteur 1 (36:01) Donc ça c'est fou. Donc je le disais se rendu donc il est effectué en arrière-plan. Et une fois qu'il a été effectué il est mis en cache dans un autre page. Et sur les sujets sûrs ces pages-là on va aller dessiner les objets qui sont en mouvement.

Interlocuteur 1 (36:16) On va utiliser des palettes pour la partie couleur. Chaque niveau dispose d'un groupe de palettes. Et chaque groupe contient 2 secondes de palettes très rapidement. Ces palettes avaient 32 palettes hergées de 16 couleurs qui vont vous permettre d'avoir de colorer le monde en fonction du niveau dans lequel vous êtes. Mais avec les contraintes de l'époque. Parce qu'il y avait des machines qui avaient accès à des palettes pour les PC avec des palettes RVB plus évoluées que certaines autres machines. Il a aussi créé un 2ème système de palette de 16 couleurs fixes qui permettent de pouvoir rendre compte.

Interlocuteur 1 (36:45) Le jeu doit à peu près sur n'importe quelle architecture. N'importe quel environnement avec un nombre limité de couleurs. Globalement voici comment s'effectuent les palettes en mémoire. Elles sont rendues comme ça. Donc vous avez sur le premier sous-groupe trois valeurs RVB qui vous permettent de déterminer les les pour chaque palette et 16 couleurs nécessaires. Et sur le sous-groupe 2 vous avez des valeurs hergées avec l'index de couleur via se réfère pour une palette fixe.

Interlocuteur 1 (37:11) En gros voilà quoi ça ressemble quand vous êtes en mode RVB vous avez cette palette. Vous avez la palette alternative du 2d groupe on voyait c'est légèrement plus sombre. Vous avez le mode VGA 16 couleurs avec une palette fresque et son art. Le mode VGA. Et pour mon ami Sébastien qui adore le mode CGA je vais créer une palette spécifique pour le mode CGA 8 couleurs.

Interlocuteur 1 (37:33) Et donc le jeu est capable d'être rendu finalement sur globalement n'importe quel hardware. La transparence vous avez un truc qui est très très simple. C'est que si une couleur d'un polygone c'est 16 alors il va prendre la couleur du pixel là où il cherche à le rendre et évaluer appliquer un OU l'inclusif de 8 ce qui va permettre de pouvoir décaler la couleur de 8 valeurs envers le bas. En gros prenez cette scène sur laquelle on dessine un éclair.

Interlocuteur 1 (38:02) Donc ça c'est la scène d'introduction du jeu. Et on va dire que la partie verte elle a la valeur 16. Donc il va prendre tous les pixels qui sont sous la valeur verte il va pique un OU l'inclusif 8 ce qui va avoir pour effet de décaler la palette de 8 vers le bas.

Interlocuteur 1 (38:17) Et donc de pouvoir simuler une transparence avec une palette qui est habilement calculée. Donc ça c'est un truc qui est assez simple mais plutôt il y a eu plutôt efficace. Une autre technique est une visée pour le rendu c'est le masquage.

Interlocuteur 1 (38:29) C'est de pouvoir si la couleur du polygone est supérieur à 16 alors il va prendre une nouvelle couleur du pixel et il va les chercher la valeur du pixel dans une autre page. En gros pour cette semaine-là on voit euh le héros se déplacer en roulant par terre. En fait on a prendre ce... 7 bounding box ça.

Interlocuteur 1 (38:48) Et en fait on va les chercher sur la couleur est supérieure à ça on va les chercher dans une autre page du décor et les couleurs correspondantes faire la composition et ensuite afficher le personnage par-dessus. On se permet de faire un système de masquage avec des polygones même complètement irréguliers. Tu m'as trouvé tout ça.

Interlocuteur 1 (39:07) Deux minutes je veux bien que ça y est républicain. Le sous-système audio très rapidement c'est pour ambiance du jeu. Donc c'est un système qui est relativement sein qui fonctionne avec quatre canaux stéréo qui est réalité du monde de la migration. Donc on va utiliser des 100 peuples qui vont permettre de jouer et des effets spéciaux selon et de la musique.

Interlocuteur 1 (39:23) Et la musique les effets spéciaux ils vont être et la musique vont les 100 peu vont envoyer sur quel canaux différents et mixés en temps réel. Ou là comme ceux-ci on en voit. Et donc avec les instructions du bytecode on va envoyer ces effets ou cette musique sur les différents canaux.

Interlocuteur 1 (39:40) Et pour la partie sonore on va utiliser ce qu'on appelle à l'époque des trackers. Donc une façon un peu textuelle de décrire la musique en disant joue un dos sur joue un dos sur le channel un joue un rail sur le channel et cetera. Donc ça c'est qu'une chose qui est une représentation qui est très compacte. Qui était très très enveloppe dans le dans les années quatre-vingt-quatre-vingt-dix parce que ça permet de te créer de la musique à l'aide de son code et d'avoir une musique qui prend très très peu de place. Sensiblement.

Interlocuteur 1 (40:08) Y compris très très bien. Et donc ça c'est quelque chose qui a été utilisé dans le jeu. Il n'utilise pas un tracker pour Jean-François Freitas qui a composé la musique utilise un tracker. Et ça permet d'obtenir la musique à l'aide de symboles qui est aujourd'hui encore face très très bien. Et le sous-système d'entrée qui est le plus simple de tous. Donc ça permet d'interagir avec les réelles comme je le disais tout à l'heure ce système d'entrée on va lire les périphériques d'entrée dont joystick clavier et cetera.

Interlocuteur 1 (40:34) Et on va aller populer certaines valeurs des variables de la machine virtuelle que après le programme va pouvoir exploiter pour pouvoir jouer avec le jeu tout simplement. Pour conclure je prends une minute.

Interlocuteur 1 (40:48) Pour conclure à l'époque [translate:Éric Chahi]] est une idée audacieuse. Et est réellement. Pour l'époque c'est cette architecture à cette façon de développer un jeu vidéo était très très audacieuse. Je vous rappelle qu'il a commencé le développement mineur. Il est 23 ans. Donc il a développé le jeu tout seul. Et c'est une architecture vraiment extrêmement avancée pour l'époque. Et qui aujourd'hui peut faire sens dans les logiciels que l'on développe quotidiennement.

Interlocuteur 1 (41:11) On peut prendre beaucoup d'idées. D'ailleurs aujourd'hui toutes les machines virtuelles qu'elles soient gérées à une autre sont inspirées un petit peu de ces techniques. C'est bizarre bien évidemment aujourd'hui ça va beaucoup plus loin. C'est beaucoup plus performant. Mais ça a permis de pouvoir faire un jeu qui était à la fois élégant peu consommateur en ressource qui était piloté par les données. Et qui est l'avantage ce qui était portable sur un traitement nombre d'architectures.

Interlocuteur 1 (41:32) Puisqu'il suffisait de porter la machine virtuelle sur l'architecture pour récupérer les athlètes et terminer le jeu fonctionnel. Donc ça a permis d'accélérer énormément les portages. Moi j'ai réécrit le moteur du jeu vidéo intégralement. Et donc j'ai pris les athlètes originaux j'ai mis dans le moteur et ça fonctionne. Donc et puis il faut apprendre du passé. Et pourquoi on parle de ça de ses bujeux parce que le passé est toujours très source de grandes sources d'enseignement. Puis j'aime mieux le gros bisage tout à l'heure à qui bientôt il me rappelle des gros bisens.

Interlocuteur 1 (41:59) Donc évidemment c'est toujours intéressant de garder un petit peu ce côté historique vidéo. Le jour en vrai j'ai pas tant de joueux les je veux vous montrer j'ai une implémentation donc en C et elles viennent les voisins et qui fonctionnent entre dans le navigateur web pour verrez retrouver sur mon site. J'ai quelques références vous partagera l'escrime.

Interlocuteur 1 (42:16) Évidemment le site d'[translate:Éric Chahi]] le site de Fabrice Bellard qui a été le premier à avoir fait le reverse-engineer du moteur et du moteur du jeu original. Familial Sanglar qui aussi a pris une partie de la version humaine qui a écrit une série d'articles extrêmement intéressants sur le sujet. Et j'ai laissé saluer tous au passage. Et qu'ils ont fait un travail formidable. Voilà il existe aussi l'implémentation en Rust de cette VM.

Interlocuteur 1 (42:41) Il y a mon implémentation que vous pouvoir trouver sur GitHub et GitLab entre autres sur mes valeurs publics Git donc j'ai réimplémenté complètement et mon implémentation vous pouvez vous retrouver sur mon site. Et même si ton être l'enquête vous préjuge directement dans le navigateur. Je termine au personnage Gronit pour me retrouver sur YouTube dans les internets partout je suis disponible à l'extérieur. Désolé pour les 1res techniques. Merci beaucoup de votre attention.

Interlocuteur 1 (43:19) On dit dans l'origine tu peux juste euh je peux vous faire une petite démo très rapide ou une jeux voilà pour demain ?