- Il s'agit d'un projet hommage personnel qui implémente en matériel FPGA, sans CPU standard, la VM, le blitter et le rasterizer de Another World / Out of This World
- La conception centrale consiste à transformer la VM en véritable processeur personnalisé, puis à l’intégrer dans un SoC avec un blitter chargé des copies/remplissages entre framebuffers, un rasterizer qui dessine les polygones et la logique de rafraîchissement de l’affichage
- Les 128 KB de SPRAM du Lattice UP5K correspondent à quatre framebuffers 320x200 en 4 bits, chaque bloc SPRAM de 32 KB correspondant à un agencement mémoire dédié à un framebuffer
- Les données du jeu ne sont pas incluses dans le dépôt ; il faut copier
BANK01àBANK0Dainsi queMEMLIST.BINdans le dossierGAMEDATApour pouvoir utiliser le paquet de données et le bitstream - Le mode d’exécution prend en charge à la fois la simulation et le matériel réel
- Pour la simulation, après installation de Silice, il est possible de lancer l’intro avec
make simul1 - Côté matériel, sont pris en charge icebreaker + VGA PMOD, le badge mch2022 et ULX3S HDMI
- Des bitstreams précompilés sont fournis, mais les données du jeu restent nécessaires séparément
- Pour la simulation, après installation de Silice, il est possible de lancer l’intro avec
- L’exécution de la VM récupère instructions et opérandes depuis la mémoire SPI, avec prélecture de 64 octets dans un petit cache BRAM pour réduire la latence
- Le pipeline graphique utilise quatre framebuffers, le double buffering, une restriction d’accès pendant la période
vblank, ainsi qu’un arbitrage des accès framebuffer entre le blitter et le rasterizer - Le rasterizer dessine les polygones convexes d’Another World sous forme de spans horizontaux, et peut lire puis modifier la valeur de pixels existants pour les effets de transparence, ou copier des pixels depuis un autre framebuffer source
- Le rendu de texte et certains arrière-plans de la part 6 sont gérés en stockant dans la ROM des buffers de pixels pré-rendus, puis en les copiant via le chemin
op_drawString, en raison du budget LUT restant - Les limitations explicites et le travail restant incluent l’absence de son et de musique, la nécessité de bitstreams et packs de données séparés selon les parties, une validation incomplète du jeu complet, un ajustement temporel plus rapide que l’original et l’exploration de la manière d’enchaîner les parties
- La licence indiquée est : conception Silice sous licence MIT, documentation sous CC BY-NC-SA 4.0, port C++ modifié conservant la GPL d’origine, et données du jeu soumises au droit d’auteur
1 commentaires
Commentaires sur Hacker News
C’était la première fois que je voyais ce genre de cinématiques entièrement animées sur Sega, et c’était vraiment impressionnant. Bien sûr, les graphismes ont continué à progresser, mais Another World tient encore très bien artistiquement aujourd’hui. Son style est très affirmé, et quand j’y ai rejoué il y a environ un an, j’ai encore été marqué
Beaucoup d’énigmes relèvent pas mal de l’essai-erreur et le jeu est extrêmement court, mais je ne voudrais quand même rien y changer. Si vous aimez Another World, je recommande aussi Flashback: The Quest for Identity. On y retrouve une ambiance cinématographique similaire, et même si je n’avais pas accroché au début, je l’apprécie de plus en plus depuis une dizaine d’années
Cela dit, Another World est une œuvre d’art. L’affiche du jeu ressemble à une peinture à l’huile, elle est vraiment superbe [1]
[1] http://www.anotherworld.fr/download/AnotherWorld_Poster.jpg
rétro-ingénierie et port JavaScript de Infernal Runner par cyxx pour l’Amstrad CPC. C’est une œuvre du créateur d’Another World, et les deux utilisent une architecture de machine virtuelle : https://github.com/cyxx/infernal_js
présentation de Norbert Kehrer, The Virtual Machine Architecture of Infernal Runner. Conférence en allemand avec diapositives en anglais : https://media.ccc.de/v/vcfb20_-146-en-202010111400-_th...
The Story of Another World on the Amiga | MVG: https://www.youtube.com/watch?v=0iz9PJbs5rE
port Nintendo 64 de Another World : https://github.com/jnmartin84/aw64
port PlayStation 1 de Another World : https://github.com/fgsfdsfgs/rawpsx
Il fournit un compilateur qui compile en Verilog, et le résultat peut ensuite être intégré dans un flux de conception existant
Le fait de devoir nager pour fuir dès la toute première action, puis d’échapper à une créature ressemblant à un lion, en fait l’une des expériences de jeu les plus brutales de tous les temps. Il suffit d’y jouer une minute pour s’en souvenir toute sa vie
Pour l’époque, les effets de caméra dramatiques donnaient vraiment l’impression d’un autre monde, au sens littéral du titre
L’illustration de la couverture est également superbe
konanaka beetzai! motsuubo! /wave
https://www.youtube.com/watch?v=JFaOYYSxSEA
Si je me souviens bien, il y montre aussi une partie des outils de développement, notamment la modification directe, ligne par ligne, des animations en bytecode de machine virtuelle et leur exécution pas à pas
Aujourd’hui, il y a moins de plateformes qu’à l’époque de la croissance explosive des années 80. Même aujourd’hui, la majorité des « logiciels » peut être vue comme du JavaScript interprété par le navigateur web. Les problèmes de portabilité existaient déjà dans les années 80, et c’était même plus difficile à l’époque parce qu’il fallait écrire soi-même l’interpréteur
Beaucoup, peut-être même la plupart, des jeux vidéo semblent avoir été écrits comme des machines virtuelles avant Doom et l’arrivée des graphismes 3D haute performance. Les jeux sur console étaient probablement en C ou en assembleur pour des raisons de performances
À l’époque, les jeux « sur ordinateur » datent d’avant qu’IBM PC ne devienne le standard, ou du moins d’avant que le PC ne l’emporte et que Microsoft ne domine. Dans un contexte où personne ne savait si l’Amiga, le PC-98, l’IBM PC, le Mac, etc. allait gagner, créer une machine virtuelle était rationnel, et SCUMM vient immédiatement à l’esprit.
La portabilité comptait, bien sûr, mais à une époque où la loi de Moore avançait à pleine vitesse et où la durée de vie des plateformes était éphémère, la machine virtuelle apportait aussi un effet de compression. Un binaire entièrement compilé pouvait prendre beaucoup trop de place sur disque ou sur bande, ainsi qu’en RAM.
À l’inverse, une très petite machine virtuelle permettait de créer un langage sur mesure interprété à la volée, ce qui réduisait fortement l’encombrement quand il fallait économiser chaque kilo-octet. Il suffit de penser à la différence de taille entre
print "Hello world!"et le binaire compilé de base. Peu importait qu’un jeu d’aventure textuel soit rapide s’il ne tenait pas dans X Ko.Ils contenaient beaucoup de texte et de ressources graphiques, avec des calculs relativement simples. Les contraintes de création n’étaient liées au matériel que sous l’angle des entrées-sorties et de la compression des données, et le code exécuté par l’interpréteur servait généralement à une « initialisation de scène » exécutée une seule fois, avec quelques minuteries d’animation.
L’idée opposée apparaît davantage dans les jeux d’arcade, puis plus tard dans Doom et Quake. Ce que le jeu simule est bien plus étroitement lié au matériel, et la définition d’une scène se rapproche davantage de données de carte — « placer un monstre ici et un bonus de vie là » — que d’une logique scriptée.
Bien sûr, ces deux derniers utilisaient aussi certaines primitives graphiques natives.
Avec des bitplanes, il n’est pas nécessaire de relire la mémoire vidéo. Il suffit de supposer que le bit de poids fort est réservé à l’effet de transparence et de dessiner directement le span.
Les deux autres avantages sont la possibilité de déplacer les plans les uns par rapport aux autres pour produire de jolis effets de moiré, ainsi qu’une bonne efficacité en mémoire et en bande passante du bus pour des profondeurs de couleur un peu atypiques, qui ne tombent pas juste sur un octet ou un nibble, comme 8 couleurs (3 bits par pixel) ou 32 couleurs (5 bits par pixel).