Eigentlich ist der Titel aussagekräftig genug, aber wenn ich schon diesen Blog führe um zu schwaffeln dann tue ich das auch. *g*
Der SXT ist mittlerweile bei Tag 9 angelang und endlich ist auch der Teil der mit einem einfachen Script umsetzbar gewesen wäre abgeschlossen. Das bedeutet das der SXT jetzt „eigenständig“ den IN-Folder auswertet, vSNES öffnet, ein im Vorfeld definiertes .zst lädt und dann den Screen sowie die einzelnen Layer exportiert.
Da es bei den Layern BG1, BG2, BG3 und bg4 zum auswählen gibt, und bg4 bis jetzt immer „leer“ war woraufhin vSNES mit einer Fehlermeldung reagiert hat wenn man diesen zu exportieren versucht habe ich hier die am 07. Jänner 2019 erwähnte Flächenkontrolle eingebaut.
Zuerst wollte ich mich an dem Vorschaufenster in der „tile info“ im „MemViewer“ orientieren da dieses Grau bleibt sobal ein BG „leer“ ist, allerdings befürchtete ich dann das eines Tages irgendein Tile genau dieses Grau verwenden würde. Ergo habe ich nach einer weiteren Möglichkeit gesucht und sie in den Angaben unter der Vorschau gefunden. Ist der BG „leer“ wird auch hier nichts angezeigt. Sollte etwas vorhanden sein werden die Daten mit schwarzer Schrift angezeigt. Meine Lösung ist nun das ich in dem Feld in dem die äußersten Ziffer angezeigt wird alle _RED32-Werte addiere. Ergibt diese Summe 10800 so ist das Feld Grau und der BG „leer und es nicht notwendig ist ihn zu speichern. (bzw. würde der Versuch die Fehlermeldung provozieren.)
Der nächste Schritt ist dann das Auswerten des Vorschaufensters. Damit diese Daten g’scheit katalogisiert werden können, ist es auch notwenig mein „Pseudo-OCR“ umzusetzen. Am 10. Jänner 2019 habe ich mich noch gefreut die Ziffern über die mittlere Zeile eindeutig identifizieren zu können… Jetzt bin ich draufgekommen das mir die „5“ einen Strich durch die Rechnung macht. Wäre der Querstrich eine Zeile weiter unten, wäre die Welt in Ordnung aber so sind „0“ und „5“ ident.
Da ich wirklich keine Lust habe wirklich alle Pixel zu kontrollieren, habe ich vor im Fall der 0/5-Linie zusätzlich den linken oberen Pixel abzufragen. Ist dieser leer handelt es sich um die „0“. Ist dieser schwarz handelt es sich um die „5“
Eine weitere Sache die ich entdeckt habe ist, das bei x/y-pos nicht nur Pixelwert (in 8er-Schritten) angegeben wird, sonder in den Klammern auch das wievielte Tile es ist. Bis jetzt sind alle SR-Szenen 64×32 Tiles groß. (0-63 und 0 bis 31) Keine Ahnung ob es größere/kleine Szenen gibt aber zumindest zur Nachvollziehbarekeit der Herkunft des Tiles (zB. Map 034 | X-pos 25 | Y-pos 17) sollte diese Erkenntnis sehr hilfreich sein.
Überhaupt sollte ich mir langsam ernsthafte Gedanken machen wie ich die extrahierten Daten ablegen möchte. Seit ich vor ewiger Zeit Kontakt mit den .wad-Files („Where’s All the Data“) habe ich ein Faible für Sammlungen aber ich bin bis dato noch nie weit genug gekommen um herauszufinden ob ein Tilesheet nicht doch schneller wäre. „Sicherer“ wäre die Sammlung, da die Daten erst „mühsam“ exttrahiert werden müssten.
to be continued…