Von einem der auszog um Sprites zu rippen…

Nachdem ich heute @wrk ein bisschen Luft habe, versuche ich einen Teil meines seit Beginn des Projektes SR:SNES:DRMM gesammelten Wissens zu tei… niederzuschreiben damit ich [Schwarzsehermodus:ON] wenn ich nachdem ich das Projekt demnächst auf Eis gelegt habe und Jahre später wieder ausgrabe mir nicht wieder alles aus den Fingern saugen muss.[Schwarzsehermodus:OFF]

And the big black dog bit me again, wohoo…

Egal. So ziemliche alle Beiträge zum Thema „SNES Sprites rippen“ berufen sich auf die mit den Emulatoren einzeln einblendbaren Layer:

Hier die Version in der die verschiedenen Layer einzeln ausgeblendet werden:



Und hier die etwas sinnvollere in der alle anderen Layer ausgeblendet sind:



Laut zSNES gibt es also vier Backround- und einen Sprite-Layer. Das stimmt mit der auf Wikipedia befindelichen Info überein:

Auflösung:	224 (NTSC) bzw. 239 (PAL) Bildzeilen im Progressive-Modus, 448 bzw. 478 Zeilen im Interlaced-Modus. 256 Pixel pro Zeile im Standardmodus, 512 im „High-Res“ Modus.
Farbtiefe:	15-Bit-Farbpalette, davon theoretisch alle Farben gleichzeitig darstellbar (unter Ausnutzung des Color Add/Subtract-Modus). Ansonsten bis zu 256 Farben aus 4096 (Mode 7).
Hintergründe:	Bis zu 4 unabhängig scrollbare Tilemap-Grafikebenen (Playfields), Colour Add/Subtract Mode (zum Kombinieren der Grafikebenen für Transparenzeffekte zwischen den einzelnen Ebenen und Sprites), 8 Grafikmodi mit unterschiedlichen Farbtiefen und Anzahl der Ebenen, Mode 7 erlaubt das dreidimensionale Zoomen, Drehen und Verzerren einer Grafikebene. Das Kippen der Grafik war von Hause aus nicht möglich, wurde aber durch helfende DSP-Chips in manchen Modulen gewährt.
Sprites:	128 Hardware-Sprites, 16 Farben pro Sprite (eine davon transparent), Spritegrößen von 8 × 8 bis 64 × 64 Pixel, max. 32 Sprites pro Zeile, max. 34 Sprite-Tiles (8 × 8 Pixel) pro Zeile.

Die meisten Beiträge schlagen vor das Spiel zu pausieren, alles bis auf die zu extrahierenden Layer auszublenden, einen Screenshot zu erstellen und dann im Bildbearbeitungsprogramm der Wahl loszulegen. Zielt man die einzelnen Phasen einer Animation ab, wünscht einem die Mehrheit ironisch viel Spaß während die Handvoll ernstzunehmender Autoren vorschlägt die gewünschte Animation mit ausgeblendeten Layern als Video aufzuzeichnen, die Frames zu extrahieren, jene mit den einzelnen Phasen auszusortieren und diese dann wie gewohnt im Bildbearbeitungsprogramm der Wahl zu verarbeiten.

Das geht einen Millimeter einfacher. zSNES verfügt nämlich über die Fähigkeit pro Tastendruck nur ein Frame weiterzurechnen. Die Betonung liegt auf weiterrechnen, denn es geht um die auf den SNES-Takt bezogen erstellten Frames, nicht jene in denen sich etwas am Bildschirm verändert. Man muß also immer noch x mal weiter drücken bis man das nächste Sprite angezeigt bekommt, aber das geht immer noch um Jahrhunderte schneller als die Version mit dem Video.

Die Vorarbeit hierzu liegt in den „SPEED OPTIONS“ („CONFIG„->“SPEED„). Hier befindet sich unter „PAUSE GAME“ der standardmäßig inaktive Punkt „INCR FRAME„. Hier einmal reinklicken und die Wunschtaste (Bei mir hat sich ohne triftigen Grund „Ü“ eingebürgert…) eintragen.



Nicht vergessen unter „MISC„->“MISC KEYS“ auch eine Taste für die zSNES-eigenen „SNAPSHOTS“ (alias Screenshots) anzugeben. 😉



Dann geht’s auch schon los. Vor dem Animationsbeginn „PAUSE GAME“ (im Normalfall „P“) betätigen, dann solange die bei „INCR FRAME“ eingetragene Taste drücken bis das erste Wunschsprite angezeigt wird und mit der „SNAPSHOT„-Taste aufnehmen. Dann mit „INCR FRAME“ solange weiter bis das nächste angezeigt wird, „SNAPSHOT„, und so weiter und so weiter.

Man kann btw. während dem Drücken von „INCR FRAME“ auch weitere Befehle eingeben. Wenn man zB. eine Richtungstaste drückt um die Spielfigur zu bewegen so wird diese Aktion von zSNES registriert und angewandt. Man könnte also, genug Geduld vorausgesetzt, während dem „INCR FRAME„-„SNAPSHOT„-Prozedere das Spiel auch tatsächlich spielen.

Soviel zum Thema Screenshots.

An die Grenzen von Screenshots im Allgemeinen stößt der geneigte Ripper sobald sich Sprites überlappen (Da es nur einen Sprite-Layer gibt ist die Chance das es dazu kommt extrem hoch.) oder Tilesets in Angriff genommen werden. Je besser der urprüngliche Künstler sein Handwerk verstanden hat desto aufwendiger wird es die Pixel korrekt zuzuordnen.

In der Regel wird einem erklärt das SNES-Sprites und Tiles zwischen 16×16 und 32×32 Pixel groß sind. Weil das bei den meisten klassischen JRPGs hervorragend passt, kann man (in diesem Fall ich) auch davon ausgehen das es sich bei isometrischen Spielen wie Shadowrun genauso verhält.



Tut es aber nicht. Vor allem der fixe Trugschluss das Tiles auf 16×16 Pixel dimensioniert sind zeigt sich anhand der links übrig bleibenden einzelnen Zeile. Dank vSNES weiß ich mittlerweile das die Wahrheit bei ganz normalen rechtwinkeligen 8×8 Pixel-Quadraten liegt.



Der ganze Bildschirm ist (zumindest bei Shadowrun) in 8×8 Pixel-Quadrate aufgeteilt. Jedes Sprite, jedes Tile, jede Font, etc. ist in 8×8 Pixel Quadrate im Speicher hinterlegt. vSNES arbeitet mit den .zst-Dateien, den Savestates von zSNES. Savestates beinhalten alles was sich in dem Moment als es erstellt wurde im Speicher befand.



Das einige Farben nicht passen liegt daran das jedem Sprite eine Palette aus 16 Farben (eine davon transparent, siehe Wikipediaausschnitt) zugeordnet ist und der MemViewer immer nur eine davon anzeigt. Warum? Keine Ahnung, ist aber für meine Zwecke auch egal. Um ehrlich zu sein habe ich den MemViewer mittlerweile gar nicht mehr aktiviert, denn der SceneViewer kann in der „layers“-Anzeige nämlich diese 8×8-Pixel Quadrate einzeln anzeigen.



In dem Screenshot sieht man leider nicht das der Mauscursor sich gerade über Jakes Oberkörper befindet und dieser deswegen im „tile info“-Feld vergrößert dargestellt wird. Wirklich deutlich wird die Mächtigkeit des Viewers aber erst wenn Sprites überlappt dargestellt werden, wie zB die Tür über dem einem Morgue-Angestellten. Fährt man mit dem Cursor über das Maxerl, wird es im „tile info“-Feld vollständig, ohne Türe dargestellt.

Ich habe keine Ahnung wie es sich bei scrollenden Darstellungen verhält, so weit bin ich mit dem Auseinandernehmen (und analysieren was da gerade abgeht…) noch nicht. Die Vermutung das sich das Bild dennoch im Speicher aus 8×8 Pixel Quadraten aufbaut und am Bildschirm versetzt dargestellt wird liegt aber verdammt nahe. Zumindest funktioniert das Skyline-Hochhaus-Intro von Shadowrun auf diese Weise.



Der Tag nähert sich dem Ende und ich kann sagen das ich hier das Grundprinzip meines aktuellen Versuches die Sprites zu extrahieren meiner Meinung nach gut erklärt habe. Warum das aber noch nicht das Ende der Fahnenstange ist und warum ich extra meinen „SpriteXtractor“ (Ja, ich mag den Angebernamen immer noch *g*) bastle um die dabei anfallende Arbeit wenigsten ein bisschen auslagern zu können erkläre ich demnächst.