Warum war es so schwer, für die N64 zu entwickeln?

Die Nintendo 64 ist ein Meilenstein in der Welt der Videospielgeschichte. Die Konsole stellte die Entwickler allerdings vor einer mächtigen Herausforderung. Wir erklären, warum es so schwierig war, Spiele für die N64 zu entwickeln.

Die erste 3D-Konsole Nintendos erschien 1996 in Japan und schaffte es 1997 schließlich zu uns. Ihre Entwicklung begann allerdings schon 1993. 3D-Grafiken in Videospielen steckten zu diesem Zeitpunkt noch in den Kinderschuhen. Die Entscheidung, einen 64-Bit-Prozessor und eine 3D-Grafikkarte zu verwenden, machte das System technologisch zwar fortschrittlich, aber auch äußerst komplex. Videospiele dafür zu entwickeln, war eine anspruchsvolle Aufgabe. Selbst der ehemalige Präsident von Nintendo, Satoru Iwata, sagte einmal: „Wir hatten Schwierigkeiten, die 3D-Grafik optimal zu nutzen, und das Team hatte eine ziemlich harte Zeit.“

Was steckt in der N64?

Was hat die Nintendo 64 eigentlich auf dem Kasten? Zunächst einmal ist in ihr eine abgespeckte Version des MIPS 4400 verbaut, der MIPS R4300i. Dieser unterstützt sowohl 32- als auch 64-Bit-Befehle. Der Chip war damals schneller als jede andere Konsole zu der Zeit: Er ist mit 92 MHz getaktet und kann fünf Befehle gleichzeitig ausführen. Zudem hat er einen 16-Bit-Befehls- und einen 8-Bit-Datencache an Bord. Neben dem Prozessor-Chip befindet sich im N64 noch der Reality Co-Processor, der den Reality Signal Processor enthält. Dieser verarbeitet alle grafischen 3D-Daten, wie 3D-Modelle oder Vektoroperationen. Sobald also der Reality Signal Processor mit der Bearbeitung fertig ist, werden die Daten an den Reality Display Processor weitergeleitet. Die Nintendo 64 besitzt also eine für damalige Verhältnisse fortschrittliche 3D-Hardware: inklusive Hardware-Texturzuordnung, Anti-Aliasing, Z-Buffering, trilineare Filterung, Perspektivenkorrektur und 32-Bit-Frame-Buffer. Was besonders speziell war: Die N64 nutzte die RAM-Bus-Technologie und war eine der ersten Konsolen, die eine einheitliche Speicherarchitektur verwendete. Programmierer konnten selbst entscheiden, wie viel Speicher für Code, Grafik und Audiodaten benötigt werden.

Vier Kilobyte sind zu wenig

Das klingt doch erst einmal alles positiv. Die Nintendo 64 war eine der fortschrittlichsten Konsolen in den 90ern. Doch genau das brachte auch Schwierigkeiten mit sich. Folgendes gilt es beim Rendern und Ausgeben von Grafiken auf der Nintendo 64 zu beachten: Anzeigelisten sind eine Reihe von grafischen Befehlen, die im RAM gespeichert sind. Jetzt führt der Reality Signal Processor diese Liste aus und wendet alle Geometrieoperationen darauf an. Das ist jetzt erst einmal nichts Neues, doch auf der N64 sind Grafik und Audio nicht festgelegt, sondern programmierbar. Der Reality Signal Processor erhält eine Anzeigeliste und teilt dem Reality Display Processor mit, was er rendern soll. Der programmierbare Mikrocode teilt wiederum dem Reality Signal Processor mit, wie er die Anzeigenlisten zu interpretieren hat.

Das Problem: der Textur-Cache. Der Reality Display Processor enthält einen Textur-Cache, der vier Kilobyte groß ist. Ohne musste die Hardware ständig auf den Hauptspeicher zugreifen, was zu einem Stillstand führte, da es länger dauert über den Bus auf den Hauptspeicher zuzugreifen, während sich der Cache direkt im Reality Display Processor befindet. Also sollte auf Letzteres zugegriffen werden. Allerdings sind vier Kilobyte nicht wirklich viel. Die Entwickler verzweifelten also an der winzigen Größe. Ihnen blieb nichts anderes übrig, als die Größe der Texturen so zu reduzieren, dass sie in den Cache passten, was die Auflösung verschlechterte. Oder sie luden unkomprimierte Texturen direkt von der Cartridge und ignorierten den Textur-Cache. Hierfür mussten die Cartridges allerdings größer sein, was natürlich mit Kosten verbunden war.

Das Problem Mikrocode

Die Nintendo 64 hatte ein großes Problem zu Beginn: Zwar konnte die Konsole hunderttausende Polygone pro Sekunde darstellen, aber die Anzahl der Pixel, die in einer 3D-Szene in einer gewissen Zeit gerendert werden können, war begrenzt. Glücklicherweise konnte das mit den erwähnten Mikrocodes verbessert werden, doch rückte Nintendo mit den nötigen Codes nicht raus – sie waren Eigentum von Nintendo. Erst später, mit der Veröffentlichung weiterer STK-Versionen, bot Nintendo Mikrocode-Updates an, was den Programmierern ermöglichte, bereits Bestehende anzupassen. Besonders zur Anfangszeit der Nintendo 64 war das ein Problem für die Entwickler. Erfahrene Firmen wie Factor 5 konnten immerhin den vorhandenen Mikrocode mit Erfolg anpassen.

Ihr seht also, die Nintendo 64 war zwar eine fortschrittliche Konsole, aber auch eine komplizierte. Nintendo selbst hat dies eingesehen und mit der Nintendo GameCube einiges anders gemacht. Hättet ihr gedacht, dass die N64 vielen Entwicklern solche Probleme bereitet hat?

Bilder: Emmanuellstace, Nintendo64.fandom, Factor 5, LucasArts, Nintendo