'Bank Switching' Sprites auf alten NES-Anwendungen

Question

Ich schreibe gerade in C#, was im Grunde meine eigene Interpretation der NES-Hardware für ein Old-School-Spiel, das ich entwickeln könnte, genannt werden könnte. Ich habe FCE angezündet und habe beobachtet, wie die NES Grafiken angezeigt und gerendert hat.

Kurz gesagt, das NES konnte zwei Bitmaps im Wert von 128x128 speichern. 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. Wenn nun ein Spiel mehr grafische Daten als diese beiden Bänke hätte, könnte es Teile dieser neuen Information in diese Banken schreiben - was es dort gab - am Ende jedes Rahmens schreiben und es ab dem nächsten Rahmen verwenden.

Also, in alten Spielen, wie haben die Programmierer 'Bank wechseln'? 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 speicherten sie diese Informationen in der Ebene - welche Sprites sollten in die PPU-Tabellen kopiert werden und wo sollten 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 erinnert, welche Kacheln sie ersetzt haben und wie sie wiederhergestellt wurden?

Wenn ich faul wäre, könnte ich nur ein riesiges statisches Bitmap machen und einfach Werte auf diese Weise greifen. 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. Ich merke immer noch, wie diese Programmierer vorgehen, was sie mit dem gemacht haben, was sie hatten.

EDIT: Die einzige Lösung, die ich denken könnte, wäre, separate Tabellen zu halten, die angeben, welche Kacheln in der PPU zu welcher Zeit sein sollten, aber ich denke, das wäre eine riesige Speicherressource, die das NES nicht könnte zu handhaben.

Answer 1

wSo nach einer Nacht des Nachdenkens und des Nachlesens von Dokumenten, denke ich, dass ich eine perfekte Lösung gefunden habe. Eine Matrix!

folgende Daten Gegeben:

3, -1, -1, -1, -1 
-1, 0, 1, 2, -1 
-1, -1, -1, 3, -1 
-1, -1, 5, 4, -1 
-1, -1, -1, -1, -1 

ich diese Informationen Informationen in Lookup-Tabellen zugreifen können, um zu bestimmen, welche Informationen die ich brauche. Der erste Eintrag (0,0) definiert die gesamte Karte, wobei die anderen Werte definieren, was in diesem bestimmten Bildschirm benötigt wird.

Also wenn ich die Karte lade, sehe ich Artikel (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.

SCREEN  PALETTE TILESET MUSIC TILEDATA SCROLLL SCROLLR SCROLLU SCROLLD 
     0   0   1  2   4  true  true true true 
     1     etc 
     2   2   1  2   3  false false  false true 

Jetzt 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.