Ich schreibe gerade in C #, was man im Grunde meine eigene Interpretation der NES-Hardware für ein Oldschool-Spiel nennen könnte, das ich gerade entwickle. Ich habe FCE angezündet und habe beobachtet, wie die NES Grafiken angezeigt und gerendert hat.
Kurz gesagt, das NES konnte zwei Bitmaps mit grafischen Informationen speichern, jede mit den Abmessungen 128x128. Diese werden PPU-Tabellen genannt. Einer war für BG-Fliesen und der andere war für Sprites. Die Daten mussten in diesem Speicher vorhanden sein, damit sie auf dem Bildschirm gezeichnet werden konnten. Nun, wenn ein Spiel mehr grafische Daten als diese zwei Bänke hätte, könnte es Teile dieser neuen Information in diese Banken schreiben - überschreiben, was da war - am Ende jedes Rahmens und es ab dem nächsten Rahmen verwenden.
>Also, in alten Spielen, wie hat die Bank der Programmierer gewechselt? Ich meine, wussten sie im Leveldesign, welches Grafikset geladen wurde? Ich habe bemerkt, dass Mega Man 2 Bankschalter hat, wenn der Bildschirm von einem Abschnitt der Bühne zum nächsten scrollt. Aber wie haben sie diese Informationen in der Ebene gespeichert - welche Sprites sollen in die PPU-Tabellen kopiert werden und wo sollen sie geschrieben werden?
Ein anderes Beispiel wäre eine Pause in MM2. BG-Kacheln werden während der Pause überschrieben und dann wiederhergestellt, wenn der Player die Pausepause einlegt. Wie haben sie sich daran erinnert, welche Kacheln sie ersetzt haben und wie sie wiederhergestellt wurden?
Wenn ich faul wäre, könnte ich einfach eine riesige statische Bitmap machen und einfach Werte auf diese Weise packen. Aber ich zwinge mich, diese Werte zu begrenzen, um ein authentischeres Erlebnis zu schaffen. Ich habe den erstaunlichen Führer gelesen, wie M.C. Kids wurde gemacht, und ich versuche Barebones zu sein, wie ich dieses Spiel programmiere. Es ist mir immer noch schleierhaft, wie diese Programmierer das gemacht haben, was sie mit dem gemacht haben, was sie hatten.
EDIT: Die einzige Lösung, die ich mir vorstellen kann, wäre getrennte Tabellen zu halten, die angeben, welche Kacheln zu welchem Zeitpunkt in der PPU sein sollten, aber ich denke, das wäre eine riesige Speicherressource, die der NES nicht könnte handle.
Nach einer Nacht des Nachdenkens und Nachlesens von Dokumenten habe ich eine perfekte Lösung gefunden. Eine Matrix!
Gegeben die folgenden Daten:
%Vor%Ich kann diese Informationen verwenden, um auf Informationen in Nachschlagetabellen zuzugreifen, um zu bestimmen, welche Informationen ich benötige. Der erste Eintrag (0,0) definiert die gesamte Karte, wobei die anderen Werte definieren, was in diesem bestimmten Bildschirm benötigt wird.
%Vor%Wenn ich also die Karte lade, schaue ich auf den Punkt (0,0). Es wird sagen, dass ich X-Kacheln in die PPU laden muss, verwende Y-Farbpaletten, Z-Tileset und A-Musik. Es wird auch gesagt, dass Bildschirm 0 der Startbildschirm ist und dass der Level dort beginnt - positioniere das Zeichen entsprechend.
%Vor%Nun sagen wir, ich muss Bildschirme wechseln. Ich kann den aktuellen Bildschirm gegenüber dem Zielbildschirm betrachten. Wenn der neue Bildschirm Informationen benötigt, die nicht in der PPU enthalten sind, kann ich einen Übergang initiieren, bei dem die Daten geladen werden. Ich kann auch sehen, ob ich in diese Richtung scrollen kann; Wenn der Zielbildschirm beispielsweise -1 ist, kann ich nicht in diese Richtung blättern. Ich kann auch irgendwo eine Flagge speichern, um festzustellen, dass ich nicht zurückrollen kann, wenn ich auf diesen Bildschirm gescrollt habe. ZB kann ich direkt auf Bildschirm 2 gehen, aber kann nicht nach links in Bildschirm 1 scrollen.