Es gibt eine interessante Möglichkeit, die Architektur von Computern der Vergangenheit zu untersuchen. Suchen Sie ein Programm, das Sie kennen, und versuchen Sie herauszufinden, wie es portiert wurde.
Eine gute Wahl dafür wäre DOOM . Der Megahit von 1994 von id Software wurde auf alles Mögliche portiert. Das Spiel ist rund um den Kern angelegt und klar in Ebenen unterteilt. Die Implementierung der sechs E / A-Subsysteme ist normalerweise leicht zu finden und zu lesen.
Eine andere Wahl wäre Another World 1991 von Eric Chailly, besser bekannt in Nordamerika als Out Of This World . Ich würde sagen, dass es aufgrund der polygonalen Grafiken, die für wilde Optimierungen geeignet sind, interessanter ist zu studieren als DOOM. In einigen Fällen ermöglichten knifflige Stunts dem Spiel, an Geräten zu arbeiten, die fünf Jahre vor der Veröffentlichung des Spiels erstellt wurden.
- Polygone eine andere Welt.
- Polygone eine andere Welt: Amiga 500 .
- Polygone Eine andere Welt: Atari ST .
Diese Artikelserie ist eine Reise durch Videospielgeräte aus den frühen 90er Jahren. Von Amiga 500 über Atari ST, IBM PC, Super Nintendo bis hin zu Sega Genesis. Ich habe versucht, für jede Maschine herauszufinden, wie Another World implementiert wurde.
Im besten Fall gelang es mir, den ursprünglichen Entwickler zu kontaktieren. Im schlimmsten Fall musste ich den zerlegten Code selbst herausfinden. Es war ein lustiges Abenteuer.
Eine andere Welt 101
Another World hat ziemlich viel Code. Die ursprüngliche Version für Amiga war angeblich nur 6.000 Zeilen lang. Die ausführbare Datei für DOS unter PC ist nur 20 kB groß. Überraschenderweise für ein so riesiges Spiel, das auf einer 1,44 MiB Diskette lief. Das liegt daran, dass der Großteil der Geschäftslogik mit Bytecode implementiert wird. Die ausführbare Datei von Another World ist eigentlich der Host der virtuellen Maschine, der die uint8_t Opcodes liest und uint8_t .
Die virtuelle Maschine in Another World definiert 256 Variablen, 64 Threads, 29 Opcodes und drei Framebuffer ( Übersetzung von PatientZero ). Das ist alles. Wenn Sie einen Host für die virtuelle Maschine erstellen, der dies unterstützt, können Sie das Spiel starten. Wenn Sie die virtuelle Maschine so schnell machen können, dass sie mit 20 Bildern pro Sekunde ausgeführt werden kann, können Sie das Spiel tatsächlich spielen.
Das Grafiksystem der virtuellen Maschine verwendet ein 320 x 200-Koordinatensystem mit einer 16-Farben-Palette. Das Palettenlimit kann überraschen, wenn man bedenkt, dass der Amiga 500 bis zu 32 Farben unterstützt. Dies geschah mit Absicht, was es ermöglichte, Grafiken mit einer anderen großen Plattform der Zeit zu kombinieren - Atari ST, die nur 16 Farben unterstützt.
Aber es gibt keinen Silberstreifen. Diese Einschränkung hat zu einem einzigartigen Stil geführt, der im Laufe der Jahre immer noch das Auge erfreut.
Auch wenn es möglich war, eine bestimmte Palette für die Szene zu verwenden, entschied sich Eric Shayi dagegen. Bei einer Kollision mit dem Biest werden nur drei Farben verwendet: Schwarz für den Körper, Rot für die Augen und Beige für die Zähne. Fantasie erledigte den Rest.
Ein ähnliches System für die Palette wurde in der ersten Szene vollständig enthüllt. Ein sehr billiger Palettenwechsel machte es einfach, einen Blitz darzustellen.
Die Strahlen der Ferrari-Scheinwerfer sind durchscheinend. Sie werden mit einer speziellen 0x10 Farbe gemalt, die es nicht gibt, da nur 16 Farben verfügbar sind. Der spezielle Wert wird interpretiert als "Lese den Frame Buffer Index, füge 0x8 und 0x8 zurück". Der letzte Teil des Tricks besteht darin, die nächsten 8 Farben in der Palette intelligent auszuwählen.
Drei Framebuffer
Von den drei Bildpuffern werden zwei für die Doppelpufferung verwendet, während letzterer zur Erhaltung der Hintergrundzusammensetzung (BKGD) verwendet wird. Durch diese Optimierung wird vermieden, dass alle Polygone mit statischem Hintergrund zugunsten eines einfachen Kopiervorgangs neu gezeichnet werden.
Im nächsten Video sehen Sie, wie eine neue Szene zuerst im BKGD-Puffer gezeichnet wird. Jeder neue BKGD-Frame wird vollständig in den Doppelpuffer kopiert. Dort werden bewegliche Elemente wie Leicester gezeichnet. Bitte beachten Sie, dass das Auto nach dem „Parken“ auch in den BKGD-Puffer gezeichnet wird, um die Anzahl der Polygone zu minimieren, die in nachfolgenden Bildern gezeichnet werden.
Beachten Sie auch, wie die Komposition einen einfachen Algorithmus des Künstlers verwendet , der trotz seiner Einfachheit zu unnötigem Neuzeichnen führt. Dies ist kein Problem, da es durch eine Kopie der BKGD weitgehend abgeschrieben wird.
Betriebscodes der virtuellen Maschine
Die folgende Tabelle zeigt 29 Opcodes. Hier finden Sie Opcodes für Flow Control (THRD), Framebuffer Management (FB) und alle Operationen zur Registerverwaltung. Die meisten Operationen sind „einfach“ zu implementieren, mit Ausnahme von COPY FB, FILL und DRAW_POLY *, die hinsichtlich der Leistung komplex sind.
Beide DRAW_POLY_ * -Opcodes umfassen mehr als eine Zelle. DRAW_POLY_BACKGROUND belegt die Hälfte des Opcode-Platzes - von 0x80 bis 0xFF . Sehr verschwenderisch, aber das ist ein Trick, um Platz zu sparen. Bei Verwendung aller Operationen, die mit Bit "1" beginnen, können 7 weitere Bits als Renderparameter in den Opcode-Raum übertragen werden. Da dieser Opcode für den Hintergrund und für die Synchronisierung verwendet wird, ist es sehr wichtig, Platz zu sparen.
Die SPRITE-Version verwendet alle Opcodes, die mit den Bits „01“ beginnen, während die verbleibenden 6 Bits zum Codieren von [x, y] -Koordinaten und Zoomen zum Rendern von „Sprites“ von Leicester, Freunden und Feinden verwendet werden.
Was weiter?
Wie bereits erwähnt, sind 26 von 29 Opcodes einfach zu implementieren. Das eigentliche Problem bei der Portierung dieses Spiels bestand darin, Pixel innerhalb der Grenzen der Bus- und Prozessorbandbreite zu manipulieren. In dieser Serie wird diskutiert, wie Framebuffer am Port manipuliert wurden und wie die Probleme der DRAW-, FILL- und COPY-Opcodes gelöst wurden.