Kategorie: SR:SNES:DRMM

Veröffentlicht am

sxt_day23/24

Update: Das American Hero Upscale-Projekt liegt wegen der unklaren rechtlichen Lage auf Eis. Das Upscalen per Freeware funktioniert zwar, dauert aber ewig und ich komme nicht wirklich an die Qualität der restlichen Videos ran.

Zurück zu dem was der Titel dieses Beitrages bereits ankündigt: Ich habe mein nach wie vor unverchromtes Hinterteil tatsächlich wieder in die Höhe bekommen und am SRXT weitergebastelt.

Da ich gerade dabei bin die seit Äonen angedachte Shadowrun 6 Pen & Paper-Runde tatsächlich umzusetzen, (Eigentlich wäre ja am internationalen Tag des Reehs der Termin gewesen, aber irgendwie hatte ein die Welt gerade im Griff habender Virus gemeint er hätte was dagegen…) beschäftige ich mich aktuell verdammt viel mit Shadowrun. Und weil ich natürlich Graham angesteckt habe (Ich will endlich den SinCity-Marv-Charakter sehen! *g*), haben wir bei unserem zur Zeit täglichen Dark Alliance-Gegrinde ebenfalls ausgibt über Shadowrun geredet. Zusätzlich habe ich auch die Shadowrun-Playlist von Orkenspalter-TV für mich entdeckt und auf deren Kanal auch ein Video zu Shadowrun Chronicles: Boston Lockdown gefunden. (Damn, I miss this game! 🙁 ) Letzteres war dann der ausschlaggebende Grund weshalb ich ich mich tatsächlich hingesetzt und wieder reingefuchst habe.

Beim letzten Mal habe ich das Pseudo-OCR fertig gestellt gehabt und es hat auch tatsächlich funktioniert. Für das x(00)y(00)-Tile, welches in meinem Test.zst leer/schwarz ist. Jedes andere Tile hat -nicht- funktioniert und es wurden grandioser Mist ausgelesen.

Looong story short: Die Zeile in der Mitte der Ziffer wurde zwar richtig ausgewertet, allerdings haben die Koordinaten nicht gepasst. Denn das Testimage& beginnt warum-auch-immer bei 0 und nicht bei 1, weshalb die mittige Zeile 4 und nicht 5 ist. Und nein, ich habe keine Ahnung wie ich das übersehen konnte. Aber egal, für den potentiellen Fall weiterer Probleme habe ich jetzt die Kontrollzeilen auskommentiert im Quellcode gelassen.

Als nächstes durfte ich herausfinden das bei aktiviertem CapsLock (Überbleibsel vom Dark Alliance Spielen…) die per _SCREENPRINT übermittelten Texte ebenfalls in Großbuchstaben eingegeben werden. Das ist bei Dateinamen die Sonderzeichen enthalten durchaus ein Problem. („0003_shadowrun (germany)_01_screen_8-bit_BG_mode_1“ wird zu „===§_SHADOWRUN 8GERMANY8_=!_SCREEN_(-BIT_bg_MODE_!“). Durch Zufall habe ich relativ schnell den Wiki-Eintrag gefunden in dem der CapsLock-Status abgefragt wird, allerdings hat es bis heute @wrk gedauert bis ich endlich entdeckt habe das die DEF SEG = 0-Zeile notwendig ist damit PEEK tatsächlich funktioniert.

Soviel zu Problemen auf die man erst mal kommen muss…

Als nächstes werde ich noch einmal kontrollieren ob mein Pseudo-OCR jetzt tatsächlich alle Werte korrekt ausliest. Ist dies der Fall werde ich die Routine die das Tile auswertet einbauen. Wenn das funktioniert (Dann halt mal….) möchte ich paranoider/vorausschauender-weise auch noch die Palette speichern. (Eventuell kann ich für die niemals meine PC verlassende Remake-Version damit Platz bei den eingebetteten Tiles sparen…) wird das Ganze so umgemodelte das alle dargestellten Tiles ausgewertet werden.

Dann beginnt der nächste gröbere Haufen Kopfarbeit. Ich möchte nämlich das bereits beim auslesen (bzw. gleich danach) kontrolliert wird, ob dieses Tile schon einmal verarbeitet wurde. Später einmal soll es eine Art Datenbank geben in der alle Tiles abgespeichert sind und jeweils nur ein einziges mal vorkommen. Ich bin gespannt ob der „tile index“ der in vSNES angegeben ist sich nur auf die aktuelle Scene oder auf das gesamte Rom bezieht. Falls letzteres der Fall wäre, könnte ich die Datenbank ohne Probleme umsetzen.

Wahrscheinlich wird es aber nicht so sein und ich muss mir überlegen wie ich mir Scene-übergreifend einen eigenen „tile index“ aufbaue. Einen möglichst sinnvollen… Wie auch immer das aussehen soll. Das überlege ich mir aber dann wenn es soweit ist.

Damit wäre ich dann auch schon am Ende meines berichtbaren Stoffes angelangt. Eventuell wäre noch erwähnenswert das ich in einem Kamikaze-Test geschaut habe ob der SRXT (inkl. vSNES) auch vom USB-Stick weg auf dem Arbeitsrechner funktioniert. Wider erwarten klappt es tatsächlich und die Richtlinien welche Applikationen laufen und welche nicht (zB. CDEx Portable) stellen für mich ein immer größer werdendes Rätsel dar.

Veröffentlicht am

zSNES Movies

Und es hat schon wieder Ewigkeiten gedauert bis ich mein (noch) unverchromtes Hinterteil in die Höhe gehievt habe. Das mag in erster Linie damit zusammenhängen das ich @wrk wirklich keine Zeit mehr für Irgendwas hatte und den ganzen Mist im Kopf mit Heim geschleppt habe dadurch Selbigen nicht mal zum Zocken freibekommen habe. Geschweige denn um mich kreativ oder überhaupt irgendwie produktiv zu betätigen.

Ad acta habe ich SR:SNES:DRMM noch lange nicht gelegt. Zu oft sehe ich Dinge bei denen ich mir denke „In -meinem- Spiel mache ich das auch so bzw. ganz anders.“ Und dann drifte ich ab und tagträume vor mich hin bis ich mich wieder daran erinnere das ich immer noch beim extrahieren bin. Bzw. kurz davor. :-/

Naja, heute bin ich aktiv einem Brainfart gefolgt. Eines meiner Sorgenkinder war ja die Tatsache das mein aktueller Dumpingprozess vorsieht das ich beim Spielen die Geschwindigkeit aufs absolute Minimum runterdrossle und Frame für Frame Savestates anlege. Auf dem Papier funktioniert das super, und in der Praxis auch so irgendwie aber für ein Spiel das wie Shadowrun auf Action ausgelegt ist das vielleicht … na gut, sowas von ziemlich sicher nicht die optimalste Lösung.

Ich weiß nicht warum, aber ich habe mich schon vor längerem von der movie-Funktion von zSNES verabschiedet. Wahrscheinlich war das als ich noch Frames und nicht Savestates grabben wollte.

Jedenfalls habe ich heute ausprobiert ob es möglich ist ein zSNES-movie (.mzt?) in realer Geschwindigkeit aufzunehmen und dann die Wiedergabe runtergedrosselt Frame für Frame abzuspielen: Ja, es geht!

(Soeben habe ich entdeckt das für Savestates einen eigenen Shortcut gibt: F2 \o/)

zSNES legt für jedes aufgenommene Movie einen temporären Folder an. Erstellt man einen Savestate landet dieser ebenfalls darin. Dieser Savestate kann a) abseits der Wiedergabe geladen werden und b) auch von vSNES gelesen werden.

(Apropos vSNES: In diesem gibt es einen Movie Editor der SMV/ZMV verarbeiten kann. Ich schaffe es aber gerade nicht Daten in diesen zu laden. Sollte ich mir auf jeden Fall ansehen. Im optimalsten Fall kann ich direkt auf die Daten im zSNES-movie zugreifen und sie ohne Umwege von dort aus exportieren.

UPDATE: „ZMV support is still incomplete.“ Tjo, das wars damit. Anyway, es sah im Screenshot eh mehr danach aus als ob im SMV nur die Tastendrücke gespeichert werden und man im Editor diese Liste bearbeiten könnte.)

Die Idee der ich nun (bzw. wenn der SXT fertig ist) nachgehen möchte ist das ich dem SXT eine Vorstufe erstelle in dem die Movies angespielt und die Savestates die später zerlegt werden hier automatisch exportiert werden. Im Endeffekt würde ich dann „nur“ die Szene spielen, dabei das movie aufnehmen und dann den SXT sein Ding machen lassen.

Was sich abseits von SXT getan hat? Weder mein neuer Versuch mein Iso-Ascii-Engine-Projekt zum Laufen zu bringen noch der beim letzten Mal erwähnte neuerliche Mono-X-Anlauf sind aus den eingangs erwähnten Gründen weit gekommen. Bei beiden habe ich wieder viel neues gelernt aber sobald ich andeutungsweise in Fahrt gekommen bin habe ich wieder keinerlei Zeit für irgendwas gefunden. Egal, dieses Kapitel meines Lebens lasse ich in Kürze hinter mir und genau aus diesem Grund möchte ich hier auch wieder aktiver werden.

Ein weiteres Anliegen ist meine Zeichnerei. Danke dem ipad das ich von der Besten der Besten geschenkt bekommen habe, bin ich bei meiner Tim Turbo Fanfiction dabei die Bleistiftzeichnungen digital zu inken und in Graustufen zu colorieren. Klingt zach, ist zach und geht genauso zach voran. Aber bald habe ich alles bereits existierende überarbeitet und kann an der Geschichte weiterspinnen… uhm. Weitermachen.

Meanwhile haben die Jungs aufgerufen Beiträge für ihren eigenen Kurzfilmwettbewerb zu erstellen und die Idee (und auch die gewünschte Maximallänge von 1min) hat mich angesprochen.

Storyboard existiert bereits und wer weiß, vielleicht geht es sich ja aus *g*

(( btw. das Beitragsbild stammt aus Solitaire Conspiracy ( https://www.bithellgames.com/the-solitaire-conspiracy .))

Veröffentlicht am

Cyberpunkiges

Long time no see, choomba… uhm.. chummer *g*

Es ist soweit CyberPunk 2077 ist draußen. Einhergehend damit bin ich nun ziemlich komplett von meinem treuen Dell-Notebook auf meinen neuen Stand-PC gewechselt. Was das für SR:SNES:DRMM bedeutet? Nichts, mag nur auch hier mit meinem neuen Rig angeben. xD

Anyway, an der SXT-Front gibt es so gut wie nichts neues. Das Pseudo-OCR ist fertig umgesetzt und dem nächste Schritt (Tiles auslesen) steht nur mein Status als gebranntes Kind im Weg.

Ich möchte nämlilch nicht einfach drauflos schreiben sondern im Vorfeld bereits ein zivilisiertes Library/Ablage-System verwenden. Und da hänge ich gerade ein wenig. Alternativ könnte ich alle Daten irgendwie ablegen und im Nachhinein auswerten und sortieren. Auf jeden Fall möchte ich später nicht draufkommen das mir bestimmte Informationen fehlen oder das System so nicht verwendbar ist.

(Beim Mono-XL-PixelMe habe ich kurz bevor ich komplett fertig war entdeckt das es nicht mögllich war beim Speichern zwischen System, Tiles und Sprites zu wechseln. Nachdem das Speichersystem aber so tief verwurzelt war musste ich einen kompletten Rewrite starten…. und bei dem bin ich bis dato nicht mehr in die Gängte gekommen.)

Aus ‚kreativer Langeweile‘ (All © Felicia Day „feeling creativly bored“) habe ich @wrk spasshalber Mono-X wieder ausgegraben. Ursprünglich um mich zu beschäftigen, später aber mit dem Vorsatz darin für SR:SNES:DRMM ein Mapsystem und das Scripten zu erstellen. Da Mono-X seit Anbeginn der Zeit (Erzähle ich eines Tages vielleicht mal…) reines ASCII ist geht es dabei tatsächlich ohen jegliche gestalterische Ablenkung nur darum die zu Grunde liegendenden Abläufe zu erschaffen.

Trotzdem, aktuell läuft fast ausnahmslos (Wenn ich nicht gerade den in Stone Story RPG offline ergrindeten Loot zerlege…) CyberPunk 2077 am heimischen PC. (Auf der PS5 im Nebenzimmer auch, aber das ist eine andere Geschichte. *g*). Als Vollblut-Shadowrunner der auch schon seit seiner allerfrühesten Kindheit ein stark ausgeprägtes Faible für das Genre Cyberpunk hat bin ich natürlich restlos… nicht ganz restlos, aber doch schon zimelich sehr begeistert von dem Spiel.

Warum nicht komplett? Mir geht irgendwie der RPG-Ansatz ab, selbst ein Gut-Böse-System konnte ich noch nicht entdecken. Nur die Entscheidung ob die Mission im Stealth oder eben >nicht unauffällig< absolviert (bzw. probiert *hüstl*) wird. Mein absichtlich so erstellter Grindgossenpunk ist nur optisch ein Grindgossenpunk. Vom Verhalten her… naja, mal schauen, so weit im Spiel bin ich noch nicht, vielleicht kommt ja irgendwann auch Charaktertechnische Freiheit.

Was mich als Shadowrunner ein bissichen sehr irritiert ist, das fast jeder Bewohner von Night City offensichtliche Cyberware trägt. Egal welche Schicht er angehört, welchen Job er ausübt… unvercyberte Menschen muss man mit der Lupe suchen.

Worauf ich ebenfalls noch gespannt bin, ist ob noch irgendwelche Minigames auftauchen werden. Normalerweise verteufle ich dank vielen Jahren Final Fantasy alle Minigames, aber eine OpenWorld in der ich nur hacken oder mörschern/stealthen kann ist fühlt sich schon ein wenig leer an.

Hier also die ersten Punkte meiner „SR:SNES:DRMM machth’s besser“-Liste:

• Minigames: Und sei es nur ein einziger bescheuerter Billard-Tisch den ich mir einbilde seit ich auf dem MegaDrive im Jump House gelandet bin und im Gegensatz zu Duke Nukem 3D nicht mit den Tischen interagieren konnte. Sollte ich tatsächlich eines Tages den Coop-Modus umsetzen können würde sich gerade Billard als Coop-Spiel anbieten. *g*

• Questdesign: Die simplen „Gehe-von-A-nach-B-und-töte-alles-dazwischen“-Quests der SNES-Version möchte ich um jeden Preis verhindern. Überhaupt möchte ich die Anzahl der möglichen Optionen sogar im Vergleich zu Returns/Dragonfall/HongKong noch in die Höhe schrauben. Am liebsten wäre es mir wenn ich es schaffen würde mich an die Pen&Paper-Vorlage zu halten und schon beim der Vorbereitung freie Hand haben. (Statt „Kontaktiere NPC xyz um Informationen zu bekommen“ soll es auch bei den eigenen Connections passende Dialogoptionen geben.)

Aber das ist alles ferne Zukunftsmusik. Zuerst muss mal der Remake-Teil fertig werden…

Veröffentlicht am

sxt_day17.7z

Theoretisch ist seit dem letzten Eintrag nicht viel passiert. Praktisch habe ich mich erfolgreich vor dem Start des Fake-OCRs gedrückt indem ich weitere Baustellen abgearbeitet habe:

In der SUB Konfiguration () werden jetzt alle Pixel-Koordinaten die davor hardgecoded waren in einem Array eingetragen. Da mehrere Positionen von der Windows-Umgebung wie z.B. der Breite der Titelleiste oder den Dimensionen der Fenster-Modus-Schaltfläche abhängig sind, möchte ich mich selbst davor bewahren eines Tages alle Werte manuell suchen und ausbessern zu müssen. Ja, mein Glaube daran den SXT noch innerhalb der Lebensezit von WIndows 10 fertigzustellen ist gar nicht mal sooo gefestigt. (Der R:SNES:DRMM jemals fertig zu bekommen ebenfalls nicht wirklich…) Eventuell werden diese Werte eines fernen Tages in einem externes .cfg-File gespeichert. Wahrscheinlicher ist aber das sie in der SUB bleiben und ich nur einen beschrifteten Screenshot mit der Position der Punkte beilege.

Eine allgemeingültige Losung für den Zeilenumbruch sobald eine der letztes Mal erwähnten Statusmeldungen im Konsolenfenster mehr als 80 Zeichen umfasst habe ich noch nicht gefunden. Nur das ich aufpasse dies Meldungen unter diesem Limit zu halten. Es würde natürlich mit MID$ funktionieren aber so viele durch Variabeln generierte Statusmeldungen gabe ich nicht und den Rest kann ich manuel kürzen. Immerhin ist jeder MID$-Aufruf eine weitere Aktion die, zwar nur minimal aber doch, Zeit verschlingt. In Summe käme da schon einiges zusammen und eigentlich sollte ich gerade als QB64-Benutzer schauen das ich so effizient wie möglich schreibe. Eigentlich…

Was noch? Die QB64-Version habe ich gewechselt. Von 1.2 auf 1.4. Das Problem mit den Sonderzeichen ist nach wie vor nicht behoben, aber schoen langsam werde ich richtig gut darin Umlaute zu umgehen. Die restlichen Benefits treffen mich laut dem was ich dem Changelog entnehmen kann nicht wirklich. Aber hey: Hilft’s nix, schad’s nix.

Damit dieser Eintrag endlich einmal fertig wird und nicht komplett leer wirkt, hier meine aktuellen relevanten Recherche-Ergebnisse zum Thema SR(SNES):

  1. 08/15-Eintrag auf Wikipedia.org (.pdf)
  2. Detaillierterer Eintrag im Fandom Wiki (.pdf)
  3. Detailierte Geschicht auf Hardcore Gaming 101.net (.pdf)
  4. Walkthrough & Stuff auf RPG Classics (.pdf)
  5. Schnittbericht auf The Cutting Room Floor (.pdf)
  6. Testberichtscans auf Kultboy.com (.pdf)
  7. Testberichtscans auf Ninretro.de (.pdf)
  8. Retro-Special auf PCGames.de (.pdf)

Ein wahnsinnig interessantes Projekt aus dem Jahr 2013 findet sich hier. Unheimlich schade das es dazu keine weiteren Infos gibt.

Und weil es mir über beim Suchen über den Weg gelaufen ist: 1001 Video Games You Must Play Before You Die beinhaltet ebenfalls einen SR-SNES-Eintrag. Vielleicht organisiere ich mir das Buch eines Tages und gehe die 1001 Spiele durch… wenn ich alle Ultimas durch habe. Und alle Elder Scrolls. Und alle Final Fantasies. Stimmt, die Witcher und Assassin’s Creed-Reihen habe ich ebenfalls begonnen… Vielleicht lasse ich das mit dem Buch lieber xD

Veröffentlicht am

5 days

Seit dem letzten Beitrag bin ich bei SXT_day14.bas angelangt und habe diese (Spätschicht-)Woche jeden Tag daran gebastelt. Zum OCR bin ich zwar immer noch nicht gekommen, aber dafür habe ich etliche andere Sachen repariert.

Als erstes und wichtigstes wäre da die Sache mit den Dateinamen. Aus mir nicht begreiflichen Gründen hat vSNES beim exportieren der Screens manchmal die ersten paar Zeichen des Dateinamens nicht übernommen.

Dieses Problem habe ich nun umgangen indem ich nach dem Speichern (inkl. einer SLEEP 1 Pause da vSNES langsamer schreibt als der SXT kontrolliert.) die erstellte Datei überprüfe und gegebenenfalls den Dateinamen ändere.

Als nächstes gab es noch die „Erster Start des Tages“-Problematik. Jedes mal wenn ich den SXT (Egal ob neuer oder alter build.) zum ersten Mal gestartet habe, ertönte zweimal der Windows-Fehler-„Ding“-Sound beim exportieren. Bei allen weiteren Starts nicht.

Abhilfe hat hier die Umsetzung eines anderen Features geschafft. Long Story short : Nach dem Start wird nun das „Scene Viewer“-Fenster per Mausklick manuell in den Vordergrund gehoben. Warum dies nicht automatisch der Fall war und wieso das bei allen weiteren Starts nicht gestört hat bzw. von alleine geschehen ist weiß ich nicht.

Eine weitere Sache die ich umgesetzt habe betrifft das Konsolenfenster. Da ich brav alles auskommentiert habe, lasse ich mir mittlerweile auch in diesem Fenster die meisten für mich relevanten Informationen anzeigen. Da vSNES aber im Vollbild darüber thront, ist das für die Katz.

Per _SCREENMOVE wird das Konsolenfenster in der rechten obere Ecke des Bildschirms plaziert. Sobald vSNES gestartet wird, wird es per Mausklick aus dem Vollbildmodus in den kleinstmöglichen noch sinnvollen Fenstermodus gesetzt. Dadurch kann ich sogar hier auf auf meinem Notebook beide Fenster zeitgleich nebeneinander sehen.

Durch Zufall habe ich entdeckt das der SXT warum auch immer nicht mehr fähig war die vSNES.ini korrekt und komplett zu editieren. Vor allem das „Scene Viewer“-Fenster wurde nicht mehr richtig plaziert. Dies fiel mir auf als ich entdeckte das vSNES im Fall einer fehlenden vSNES.ini zwar sofort eine neue erstellt, diese aber erst NACH der Beendigung des Programmes schreibt.

Hier blieb mir nichts anderes übrig als die komplette „vSNESanpassen“ SUB neu zu schreiben. Dafür wird jetzt auch der PaletteViewer angezeigt (auch wenn sich das Fenster aus sich mir nicht erschließenden gründen nicht per Variabeln plazieren läßt) und vSNES kann jetzt ohne „Sind Sie Sicher?“-Kontrolldialog geschlossen werden.

(Die Lösung zu dem keine-vSNES.ini-Problem ist sehr simpel ausgfallen: SXT kontrolliert ob eine exisitiert und sollte dem nicht der Fall sein beendet es sich mit dem Hinweis das vSNES einmal manuell geöffnet und geschlossen werden soll. Nach wie vor gehe ich nicht davon aus das außer mir jemand dieses Programm verwenden wird, und defacto spare ich mir die kompletten Luxusfeatures.)

Veröffentlicht am

Script done, OCR coming up next

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…

Veröffentlicht am

Da geht ja tatsächlich was weiter…

Während ich warum auch immer daheim nicht und nicht in Fahrt komme (Dafür aber stattdessen SR:HK „recherchiere“. *hüstel*) habe ich dank dem aktuellen Dreischichtbetrieb @wrk aber dort Zeit und interessamterweise Muse genug mich mit dem SpriteXtraktor zu beshäftigen.

Zuerst habe ich die am 18.09.2020 in Klammern erwähnte „Screenshot-Folder erstellen“-Option eingefügt. Funktioniert soweit, allerdings habe ich hier @wrk den originalen Folder nicht gelöscht sondern nur verschoben und Windows hat daraufhin neu erstellte Screenshots weiterhin in den originalen Folder gespeichert. Egal wo sich dieser befand.

Muss ich eventuell auf einem weiteren Rechner ausprobieren, aber aktuell frage ich mich sowieso ob ich tatsächlich die Screenshot-Option verwenden möchte. Mal schauen…

Als nächstes habe ich mir Gedanken über das Ablagesystem gemacht und beschlossen ich benötige den Inhalt des IN-Folders als Feld im Speicher. Nur um nach ein paar Zeilen draufzukommen das ich das damals bereits getan habe.

Weiter ging es mit der Umsetzung des auskommentierten Textes in AllesExtrahieren. Bei „Save Scene“ entdeckte ich das ich dem meinem Ablagesystem entsprechend pervertierten Dateinamen eingeben muss. Zum Glück gibt es den QB64-Befehl _SCREENPRINT der einem das für jedes Zeichen des Strings qualvoll die jeweiligen Tasten der Reihe nach ansteuern abnimmt. Zum Glück habe ich mich daran erinnert bevor ich die ersten 25 Tasten des Keyboards zusammengeschrieben habe… uhm. Ja.

Beim Zusammenbasteln der Dateinamen habe ich entdeckt das ich das Dateinamen-Feld nie ausgiebig genug getestet habe und es nur innerhalb der SUB in der es per REDIM erstellt und daraufhin befüllt wird funktioniert. Long Story short: REDIM SHARED funktioniert nicht in einer SUB und deswegen ist meine INFolderAuswerten-SUB jetzt zweigeteilt damit sie zwischendurch wieder zurück springen und das Feld korrekt und geshared dimensionieren kann. Schaut blöd aus, ist hoffnungslos unelegant, funktioniert aber…

Beim Austesten habe ich entdeckt das vSNES meckert wenn sich im OUT-Folder bereits eine Datei selben Namens befindet. Da ich keine Lust habe herauszufinden wie ich dieses Dialogfeld bediene bzw. ich nicht wüßte wie ich herausfinde ob die Datei überrschreibbar ist oder nicht kontrolliert die SUB VerzeichnisseEruieren jetzt auch ob sich etwas im OUT-Folder befindet. Sollte dies der Fall sein, wird ein mit Datum und Uhrzeit im Namen versehener Backup-Folder erstellt und alle Dateien dorthin verschoben.

Tjo, und soweit wäre ich dann mal. Mal schauen ob und was heute geht. 🙂

Veröffentlicht am

Ain’t got no time *rant*

Ich habe es in der Zwischenzeit gerade einmal geschafft, die vSNES.ini auf dem Laptop zu sichern, vSNES zu starten, die Verzeichnisse manuell zu suchen und die nun korrekte vSNES.ini seperat abzuspeichern. Hineinzuschauem um herauszufinden wo die Pfadangaben eingetragen werden ging sich noch nicht aus.

Dafür habe ich entdeckt das es zwar schön ist das ich die Cartridge lade, diese aber aufgrund der Durchnummerierung meiner Savestates einen anderen Dateinamen hat und vSNES jetzt trotzdem herummmeckert.

Update: Dieser Umstand wurde damals bereits erkannt und „gelöst“. (Beim Laden des Roms wird einmal zusätzlich „I“ für „Ignore“ gesendet. *g*)

Na gut, dank eines Serverabsturzes kann ich gerade @wrk ein bisschen Zeit abzwicken. Mal schauen ob ich zumindest die Pfadagaben-G’schicht abhaken kann.

((Tja, hab’s verschrien… mehr als diesen Text habe ich heute (22/09/2020) nicht zusammen gebracht. trotz Serverarbsturz zu viel zu tun… @_@ ))

Die erste Pfadangabe befindet sich am Ende des [Form_Cart]-Blocks, die schlicht und ergreifend nur „Paths=“ lauten. Gegen Ende des [Form-Main]-Blocks befinde sich dann „Menu_Cart.Hints=“, „Menu_Cart.ItemCaptions=“ und „Menu_SNES.ItemCaptions=“ wobei “ Menu_Cart.ItemCaptions=“ für das Rom und „Menu_SNES.ItemCaptions=“ für das Savestate steht. Unter [Form_Open] gibt es bei „Path=“ und „LV_Status.ItemCaptions=“ ebenfalls Verweise zu den Savestates.

((Hier das Ende meines Eintrags vom 28/09/2020… Es folgt die Fortsetzung vom 29/09/2020))

Die von mir verwendeten Verzeichnisvariabeln lauten: VerzeichnisProgramm$, VerzeichnisIN$, VerzeichnisOUT$, VerzeichnisScreenshots$ und VerzeichnisVSNES$

Die Pfadangabe die NICHT geändert wird, ist die in [Form_Open] und ich habe aktuell keine Ahnung wieso.

Ich hab’s geschafft. Wo auch immer der Unterschied zwischen „LV-Sl“ und … okay. Beim hier zur gegenüberstellung in den Text kopieren habe ich ich es entdeckt. *facepalm* „LV-Sl“ versus „LV_Sl“ wobei letzteres richtig ist.

Kein Wunder das dieser Abschnitt nicht gefunden wird. Ich kann nur annehmen das ich damals mit einer bereits bearbeiteten vSNES.ini gearbeitet habe und mir nicht aufgefallen ist das diese Pfadangaben nicht geändert wurden da sie bereits korrekt in der .ini standen. Oder so. kA. Herauszufinden warum etwas funktioniert hat das nicht funktionieren sollte gehört jetzt nicht mit zu den Dingen die für mich eine andeutungsweise hohe Priorität haben.

vSNES komplett aus dem SXT gesteuert.

(Weil ich neugierig bin kann ich eventuell mal in den bisherigen Versionen herumstöbern ab wann aus dem Bindestrich ein Unterstrich wurde…)

Anyway, der SXT läuft wieder korrekt bis zum derzeitigen Ende meiner Kommandos durch. (Vllt. sollte ich das @wrk mit den anderen Pfäden sicherheitshalber auch nochmal testen…). Und somit kann ich endlich damit weitermachen meinen Code nachzuvollziehen…

Ich bin das letzte Mal bei SaveStateOeffnen 4 stehen geblieben und finde sofort das nächste Problem.

Während die 4 angibt das ich bei „cartridges“ per Cursor-Tasten den vierte Savestate anwählen möchte, startet die Auswahl nicht automatisch beim ersten File, weshalb mir jetzt zB. das 0007er-File geladen wurde.

Ich bin mir sicher auch dazu gibt es einen Eintrag in der vSNES.ini, allerdings habe ich zuerst entdeckt das mich ein Druck auf POS1/Home ebenfalls an den Anfang der Liste bringt. Während ersteres sicherlich eleganter wäre, ist letztes wahrscheinlich effektiver und für die geplante Stappelverarbeitung zweckdienlicher.

Die im Send_Keys-Eintrag im QB64-Wiki aufgelisteten Tastaturcodes funktionieren nicht. (Zumindest der für POS1 nicht.) Die hier gelisteten schon.

.pdf Datei: 005_vba-tutorial_Tastatur_&_Maus_29_09_2020.pdf

Was ich noch soeben entdeckt habe ist, das ich aktuell mit der 4 nicht das vierte File anwähle sondern da 4x nach unten gedrückt wird das fünfte. Sollte ich ebenfalls zur erleichterten Nachvollziehbarkeit ändern.

So. Der nächst Punkt ist AllesExtrahieren und der besteht zZt. aus folgendem Text:

SUB Alles Extrahieren
   'STR+S -> Save Scene
   'ALT+L -> switch to "layers"
   'ALT+B -> switch to "regular backgrounds"
   '-MAUS auf BG1
   '-STR+S -> Save Scene
   '-MAUS auf BG2
   '-STR+S -> Save Scene
   '-MAUS auf BG3
   '-STR+S -> Save Scene
   'NICHT? -MAUS auf BG4
   'NICHT? -STR+S -> Save Scene
END SUB

Hier habe ich seinerzeit also aufgehört und ab hier sollte ich jetzt weitermachen…

Ich habe tatsächlich @wrk Zeit gefunden und das am 18.09.2020 angedachte Sreenshot-Folder-erstellen-Feature eingebaut.

Veröffentlicht am

Back in Action… oder so…

Der letzte Eintrag liegt 16 Monate zurück, der letzte SR:SNES:DRMM betreffende überhaupt schon 20 Monate…

Es mag vielleicht den/die eine(n) oder andere(n) enttäuschen aber ich existiere noch. Und obwohl 2019 sich mir gegenüber ziemlich derb gebärdet hat und 2020 global gesehen auch nicht wirklich das Gelbe vom Ei ist, darf ich sagen das es mir eigentlich verhältnismäßig gerade recht gut geht. Anyway, wenn ich jetzt jedesmal wenn ich Pausen einlege einen Rechtfertigungsbeitrag verfasse, kommen wir hier nie zu was.

Ich habe Shadowrun:Hong Kong jetzt tatsächlich noch eine Chance gegeben und bereits nach zwei Sessions bereits wieder abertausende Ideen für SR:SNES:DRMM.

Grund genug also den SpriteXtraktor wieder auszugraben und weiterzu… uhm. Mich langsam wieder in den Code einlesen, versuchen herauszufinden was ich da eigentlich gerade getan habe und wo genau ich warum stehen geblieben bin.

'==============================
' SR:SNES:DRMM SpriteXtractor
'------------------------------
'SXT_day5.bas    Fr.28/12/2018
'SXT_day4.bas    So.25/12/2018
'SXT_day3.bas    So.24/12/2018
'SXT_day2.bas    So.23/12/2018
'SXT_day1.bas    So.16/12/2018
'------------------------------
'All (d) by -=[d.s.R.=- except:
'"Directory Enviroment"-Demo by Dav -> "http://qb64.org/wiki/Windows_Libraries#Directory_Environment"
'"Windows User"-Demo by Michael Calkins -> "http://qb64.org/wiki/Windows_Libraries#Windows_User"
'"SENDKEY.BAS" by Dav -> "http://qb64.org/wiki/Windows_Libraries#Send_Keys"
'"Mouse Area"-Demo -> "http://qb64.org/wiki/Windows_Libraries#Mouse_Area"
'"_SCREENIMAGE"-Demo -> "https://qb64.org/wiki/SCREENIMAGE"
'==============================

Tjo… da habe ich ja jetzt gar nicht mal so viel Zeit reingesteckt wie ich angenommen habe … egal. 

VerzeichnisseEruieren
INFolderAuswerten
vSNESanpassen
vSNESoeffnen

((fyi der Übersicht wegen füge ich nicht mehr den kompletten Quelltext sondern nur die relevanten Auszüge ein.))

VerzeichnisseEruiern ist soweit mal klar und hat „lustigerweise“ auf meinem frisch aufgesetzten Notebook zu einem Fehler geführt da der Screenshot-Folder noch nicht existiert hat. Hier sollte ich eventuell eine „Order erstellen„-Option einfügen….

INFolderAuswerten. Na schau dir was an. In einem der letzten SR:SNES:DRMM-Beitrag labber ich noch was von wegen HotFoldern und hier ist er tatsächlich schon implementiert. Der Name bedeutet nämlich IN-Folder-auswerten und nicht INFO-Folder-auswerten. Und in eben diesen IN-Folder kommen alle auszuwertenden .zst-Dateien rein.

vSNESanpassen ist auch klar. Hier werden in der vSNES.ini alle Pfadangaben sowie alle notwendigen Größenangaben soweit angepasst das der SpriteXtraktor damit funktioniert und ohne weiteres Zutun des Benutzers alleine alle Daten im Hotfolder abarbeitet.

vSNESoeffnen spricht auch für sich selbst.

ExtrahierenVorbereiten
ROMoeffnen
SaveStateOeffnen 4

AllesExtrahieren

AllesBeenden
END

ExtrahierenVorbereiten. Okay, ab hier beginnt es kompliziert zu werden: Zuerst wird per Alt+S der Reiter „screen“ ausgewählt. Dann wird der Cursor über „8-bit“ plaziert und einmal geklickt. Als letztes wird mit CTRL+1 BG1 ausgewählt.

((Die angewählten Punkte habe ich der Übersicht wegen Gelb hervorgehoben.))

ROMoeffnen ist notwenig da vSNES sonst beim Laden jedes Savestats rumjammert.

SaveStateOeffnen 4 ist auch klar… killt mich aber hier @wrk wo ich ganz andere Ordnerstrukturen habe. :-/

Das bedeutet ich sollte herausfinden wie ich Ortsunabhängig den notwendigen Pfad in diese Auswahl bekomme. Wahrscheinlich in der vSNES.ini.

to be continued…

Veröffentlicht am

Acht mal acht

Eine Sache die ich beim Herumspielen entdeckt habe und die mir in Folge Kopfzerbrechen bereitet hat, war das manche Scenes größer als der Bildschirm (512x488px) sind.

Ein gutes (und afaik das erste) Beispiel hierfür sind die Einzelteile des Parallax-Scrolling-Skyline-Intros. zB. ist der Skyline-Layer.

Kommando zurück. Wie ich jetzt beim Auslesen der Werte entdeckt habe, ist der fertige Screen 512x488px und der Skyline-Layer 512x256px. Und das obwohl im Screen nur ein Ausschnitt des Layers zu sehen ist. Wie das geht? Durch Zoom aka Pixelwiederholung. Ich habe im Screen keinen einzigen einzelnen Pixel gefunden, alle waren 2×2 Pixel groß.

Was bedeutet das jetzt für mich? Nichts. Nach wie vor werden rechts und unten im Scene_View-Fenster Zeilen ausgeblendet wenn man die 1:1 Ansicht wählt. Da ich in der vsnes.ini keinen Eintrag über die Zoomstufe finde, und ich mich nicht darauf verlassen möchte das tatsächlich niemals ein Layer einen größeren Wert als 512 aufweißt, bleibe ich meiner ursprünglichen Idee mit einer verkleinerten Zoomstufe zu arbeiten treu.

Warum? Im ersten Schritt werden ja alle Layer exportiert. Im zweiten werden sie miteinander verglichen um herauszufinden in welchen es tatsächlich Änderungen gab (zB. wird sich der Skyline-Layer die gesamte Sequenz lang nicht ändern.). Dann werden die Savestates die diese Undikat-Layer enthalten wieder geladen und die Sprites exportiert. Da geschickte Grafiker Sprites so designed haben, daß ein und das selbe mehrmals verwendet werden kann und ich schon im Vorfeld verhindern möchte das zumindest pro Savestate nicht x-mal das selbe Sprite gespeichert wird, mache ich mir ein weiteres vSNES-Feature zu eigen.

Bewegt man den Mauscursor im Reiter „layers“ über das Bild, werden rechts unter „tile info“ Details über das sich aktuell unter dem Cursor befindliche Sprite angezeigt. zB. auch „tile index“. Wenn ich es schaffe diese Infos auszulesen (Pseudo-OCR incoming…) kann ich Duplikate vermeiden.

Das war jetzt viel Bla, von dem ich afair einiges schonmal erwähnt hatte, aber dafür sollte das Gesamtbild jetzt auch außerhalb meines Kopfes klar(er) sein. *g*

Womit ich heute Teile des Vormittages verschwendet habe, war die verschiedenen Zoomstufen in die entsprechenden Quadrate zu zerlegen. Bei 1:1 war es logisch:

Bei 1:2 ebenfalls. Ein Quadrat hat 4×4 Pixel. Geht man davon aus das die Skyline 512x256px groß ist, kann man in dieser Zoomstufe 1024x512px große Layer zerlegen.

Eigentlich hatte ich photoshopgeschädigt mit kreativen Zoomstufen wie 1:3 oder 1:2,75 gerechnet, aber die nächste Stufe die vSNES anbiete ist 1:4. Hier entspricht ein Quadrat (Trommelwirbel bitte) 2×2 Pixel und es sind 2048x1024px große Layer möglich.

Es gäbe noch die Stufe 1:8 bei der jeder Pixel einem Sprite entspricht und Layer bis 4096x2048px auswertbar sind aber ich behaupte mal das ich diese Stufe nie benötigen werde. (Auch wenn es verführerisch wäre den Curosr immer nur einen Pixel weiter zu verschieben und fix davon ausgehen zu können das der Layer immer komplett angezeigt wird. Hm…)

Und damit wäre das Kapitel Zoomstufen und alle Sorgen die ich mir diesbezüglich gemacht habe abgehakt. Als nächstes sollte ich mich entweder mit dem erkennen der ausgeblendeten bg-Reiter oder meinem Pseudo-OCR auseinander setzen…

Da ich die ausgeblendeten Reiter allerdings mit hoher Wahrscheinlichkeit über die Kontrolle einzelner Pixel (Schwarz = aktiv, Dunkelgrau = inaktiv) lösen können werde, wird es wohl das Pseudo-OCR werden *g*

[~1h später ] Das war einfacher als erwartet.

Glücklicherweise hat creaothceann eine 5x9px Schrift verwendet deren Position sich (zumindest bei den Ziffern, mehr habe ich mir nicht angesehen..) nicht ändert/anpasst. Die Felder in welchen sich die auszulesenden Pixel befinden ändern sich also nicht.

Ich hatte die Hoffnung das ich in jeder Ziffer einen Pixel finden der sich nur in dieser Ziffer befindet, habe aber keinen gefunden. Dann setzte ich darauf das die Summer der ausgefüllten Pixel in einer Zeile/Spalte Rückschlüße zuliese aber dem war auch nicht so, auch über die Gesamtsumme aller Pixel zu gehen wurde durch „6“ und „9“ zerstört. Sollte ich also nicht noch den ultimativen Geistesblitz haben, muss ich tatsächlich mindestens die Hälfte aller Pixel … warte mal…

0 = X…X   1 = ..X..   2 = …X.   3 = ..XX.   4 = .X.X. 5 = X…X  6 = XXXX.   7 = ..X..  8 = .XXX.  9 = .XXXX

Youp, die mittlere Zeile ist bei jeder Ziffer einzigartig. Damit habe ich 45 zu kontrollierende Pixel auf 5 reduziert. \o/ Wohoo!