Il existe une manière intéressante d'étudier l'architecture des ordinateurs du passé. Trouvez un programme que vous connaissez et essayez de comprendre comment il a été porté.
Un bon choix pour cela serait DOOM . Le mégahit de 1994 d'id Software a été porté sur tout ce qui était possible. Le jeu est conçu autour du noyau, clairement divisé en couches. Il est généralement facile de trouver et de lire l'implémentation de six sous-systèmes d'E / S.
Un autre choix serait Another World 1991 d'Eric Chailly, mieux connu en Amérique du Nord comme Out Of This World . Je dirais qu'il est en fait plus intéressant à étudier que DOOM, en raison des graphiques polygonaux adaptés aux optimisations sauvages . Dans certains cas, des cascades délicates ont permis au jeu de fonctionner sur un équipement créé cinq ans avant la sortie du jeu.
- Polygones Another World.
- Polygones Another World: Amiga 500 .
- Polygones Another World: Atari ST .
Cette série d'articles est un voyage à travers l'équipement de jeux vidéo du début des années 90. D'Amiga 500, Atari ST, IBM PC, Super Nintendo, à Sega Genesis. Pour chaque machine, j'ai essayé de savoir comment un autre monde a été implémenté.
Dans le meilleur des cas, j'ai réussi à contacter le développeur d'origine. Dans le pire des cas, j'ai dû trouver moi-même le code démonté. Ce fut une aventure amusante.
Another World 101
Another World a pas mal de code. La version initiale d'Amiga ne compterait que 6 000 lignes. Le fichier exécutable pour DOS sous PC ne fait que 20 Ko. Étonnamment pour un jeu aussi énorme, qui est venu sur une disquette de 1,44 Mio. En effet, la majeure partie de la logique métier est implémentée à l'aide du bytecode. L'exécutable Another World est en fait l'hôte de la machine virtuelle qui lit et exécute les opcodes uint8_t .
La machine virtuelle dans Another World définit 256 variables, 64 threads, 29 opcodes et trois framebuffers ( traduction de PatientZero ). C’est tout. Si vous créez un hôte pour la machine virtuelle qui peut gérer cela, vous pouvez démarrer le jeu. Si vous pouvez rendre la machine virtuelle assez rapide pour fonctionner à 20 images par seconde, vous pouvez réellement jouer au jeu.
Le système graphique de la machine virtuelle utilise un système de coordonnées 320x200 avec une palette de 16 couleurs. La limite de palette peut surprendre, étant donné que l'Amiga 500 prend en charge jusqu'à 32 couleurs. Cela a été fait à dessein, ce qui a permis de combiner des graphiques avec une autre grande plate-forme de l'époque - Atari ST, qui ne prend en charge que 16 couleurs.
Mais il n'y a pas de doublure argentée. Cette limitation a conduit à un style unique qui, au fil des ans, plaît toujours à l'œil.
Même lorsqu'il était possible d'utiliser une palette spécifique pour la scène, Eric Shayi a décidé de ne pas le faire. Lors d'une collision avec la Bête, seules trois couleurs sont utilisées: le noir pour le corps, le rouge pour les yeux et le beige pour les dents. L'imagination a fait le reste.
Un système similaire pour la palette a été pleinement révélé dans la scène initiale. Un changement de palette très bon marché a permis de représenter facilement un éclair.
Les rayons des phares Ferrari sont translucides. Ils sont peints avec une couleur spéciale 0x10 qui n'existe pas, car seules 16 couleurs sont disponibles. La valeur spéciale est interprétée comme «lire l'index du tampon de trame, ajouter 0x8 et retourner». La dernière partie de l'astuce consiste à sélectionner intelligemment les 8 couleurs suivantes dans la palette.
Trois framebuffers
Des trois tampons d'image, deux sont utilisés pour la double mise en mémoire tampon, tandis que le dernier est utilisé pour préserver la composition de l'arrière-plan (BKGD). Cette optimisation évite de redessiner tous les polygones d'arrière-plans statiques au profit d'une simple opération de copie.
Dans la vidéo suivante, voyez comment une nouvelle scène est dessinée en premier dans le tampon BKGD. Chaque nouvelle trame BKGD est entièrement copiée dans le double tampon. Là, des éléments en mouvement, comme Leicester, sont dessinés. Veuillez noter qu'une fois que la voiture est «garée», elle est également dessinée dans le tampon BKGD pour minimiser le nombre de polygones qui seront dessinés dans les images suivantes.
Notez également comment la composition utilise un algorithme simple de l'artiste , qui, malgré sa simplicité, conduit à un redessin inutile. Ce n'est pas un problème car il est largement amorti par une copie de BKGD.
Opcodes de machine virtuelle
Le tableau suivant montre 29 opcodes. Ici vous pouvez trouver des opcodes pour le contrôle de flux (THRD), la gestion de framebuffer (FB) et toutes les opérations de gestion de registre. La plupart des opérations sont «simples» à implémenter, à l'exception de COPY FB, FILL et DRAW_POLY *, qui sont complexes en termes de performances.
Les deux opcodes DRAW_POLY_ * s'étendent sur plusieurs cellules. DRAW_POLY_BACKGROUND occupe la moitié de l'espace opcode - de 0x80 à 0xFF . Très gaspillage, mais c'est une astuce pour économiser de l'espace. L'utilisation de toutes les opérations commençant par le bit «1» permet de transférer 7 autres bits vers l'espace opcode en tant que paramètres de rendu. Étant donné que cet opcode est utilisé pour le fond et les synomatiques, économiser de l'espace est très important.
La version SPRITE utilise tous les opcodes commençant par les bits "01", tandis que les 6 bits restants sont utilisés pour coder les coordonnées [x, y] et zoomer pour le rendu des "sprites" de Leicester, ami et ennemis.
Et ensuite?
Comme mentionné précédemment, 26 opcodes sur 29 sont faciles à implémenter. Le vrai problème lors du portage de ce jeu était de manipuler les pixels dans les limites de la bande passante du bus et du processeur. Cette série discutera de la façon dont les framebuffers ont été manipulés au port et comment les problèmes des opcodes DRAW, FILL et COPY ont été résolus.