Spontan beschlossen…

Ha… wo fange ich an? Seit meinem letzten Eintrag ist einiges passiert. Ohne ins Detail zu gehen kann ich sagen das so gut wie kein Stein mehr auf dem anderen steht. Weitere Details sowie jegliche Deutungen ob das jetzt etwas positives oder negatives ist sind hier fehl am Platz. Punkt.

Die vielleicht (also wenn es denn jemanden interessieren würde) auffälligste Änderung ist das ich das WordPress-Layout jetzt öffentlich gemacht habe. Baustelle hin oder her, die alte Seite war echt nicht mehr repräsentativ. Dieses neue Layout beinhaltet zwar immer noch all die geekigen Auswüchse, legt den optischen Fokus jetzt aber auf meine Zeichnerei.

Ich habe in Ermangelung sonstiger selbsttherapeutischer Möglichkeiten wieder begonnen „mehr“ zu zeichnen. Nachdem ich dadurch wieder auf ein zivilisiertes Level gekommen bin, habe ich die Tim Turbo Fanfiction wieder ausgegraben und gebe jetzt bei der Gas.

Nachdem ich es geschafft habe meinen während bored und Drawlloween gefundenen Zeichenstil fortzuführen, habe ich durch das umarrangieren der bisherigen Seiten auch noch eine halbe Logiklücke schließen können.

Zwei Seiten und etliche Stunden Recherche später, bin ich sogar mit der Planung so weit fortgeschritten das ich sogar die erste Doppelseite umsetzen kann.

Das heißt zwar für einen im Internet veröffentlichten Comic nichts, aber wozu arbeite ich im Digitaldruck wenn ich nicht zumindestens ein Heft tatsächlich drucken werde? *g*

Tja… und kaum war ich wieder voll in Fahrt… the return of the black dog. Habe mich am Wochenende mehr oder weniger erfolgreich damit abgelenkt den zweiten South Park-Teil duchzuspielen und heute die Bastlerei an dieser Seite vorgeschoben. Eigentlich sollte ich damit alle mehr oder weniger sinnvollen Möglichkeiten zur Prokrastination ausgeschöpft haben.

Macht und Magie

Während ich mich vorgestern mit der imo optimalen portablen Konfiguration der Gog-Version herumgeplagt habe, kam ich gestern endlich dazu mich mit dem Spiel an sich zu beschäftigen.

Nachdem ich die Einleitung im Handbuch durchgewälzt und die Umsetzung des Erfahrenen grob skizziert habe, kam ich zur Charaktererschaffung. Grob gesagt gibt es sechs Charakterklassen und ebensoviele Slots. Von jeder Klasse eine/n VertreterIn in der Party zu haben ist also ein No-Brainer. Drei Gesinnungen und zwei Geschlechter ergeben überhaupt eine ausgewogene Gruppe.

Positiv überrascht hat mich das beim Werte-erwürfeln automatisch nur die Klassen wählbar sind, die mit den Werten möglich sind, einen komplett verhunzten Char kann man sich also von Haus aus nicht bauen.

Während es schnell ging die Charaktere grob zu skizzieren (Klasse + Rasse + Gesinnung + Geschlecht = Idee fürPersönlichkeit), hat die Namensfindung dann ewig gedauert. Und mit ewig meine ich wirklich ewig. Meisterwerke wie Robobob und Hobobunny (Final Fantasy VII ftw.) sind es zwar nicht geworden aber es hat sich ausgezahlt und ich bin zufrieden. Ich hoffe bloss das ich die Party in den weiteren Teilen (so ich tatsächlich fertig werde und weitere Teile angehe) importieren kenn, denn mein Haufen Abenteurer hat, zumindestens am Papier, wahnsinnig viel Potential.

In der Praxis haben sie dann den ersten Kampf überlebt, mangels brauchbarer Waffen und Spellpoints dann aber als ich mich am Rückweg zum Inn (Natürlich habe ich bei meinem Testlauf nicht gemappt, auch wenn einem das im Handbuch gefühlt auf jeder Seite als Feature nahegelegt wird…) verlaufen habe im zweiten Kampf eine weniger gute Figur abgegeben.

Apropos Kämpfe… ich weiß das dieses Spiel 1986 erschienen ist, aber das der Kampfbildschirm tatsächlich nur ein Textfenster ist, ist schwer verdaubar. Zuerst wird einem zwar ein Gegner angezeigt, aber sobald es losgeht ist es nur noch Text. Auch das einem die Sprüche nicht angezeigt werden sondern man zuerst das Level und dann die Nummer (zB. Sorceror Spell 1-4 = Flame Arrow ) eingeben muss, zerstört jeglichen Anflug einer potentiellen möglichen Immersion.

Eines Tages werde ich mir die Sprüche (bzw. die dazugehörigen Nummern) verinnerlicht haben, aber bis es soweit ist habe ich mir alle relevanten Informationen in eine Textdatei übertragen die nun neben dem DOSBox-Fenster geöffnet liegt. Das sich in der Datei euch die rudimentären Charakterdaten (Name, Klasse,…) befinden ist ebenfalls der nicht vorhandenen Immersion geschuldet… nicht meiner kreativen Namensgebung…

Einen zweiten Probelauf habe ich mir gespart und stattdessen ein bisschen in einem Beginners Guide gestöbert. Außer das ich am Anfang kein Geld für bessere Waffen besitze konnte ich beim möglichst spoilerfreien Überfliegen keine weiteren relevanten Informationen ausmachen.

Meine bevorzugten Reviewer haben sich im Großen und Ganzen zu M&M1 ausgeschwiegen und auch sonst konnte ich auf die Schnelle nichts lustiges dazu finden. Anscheinend kann ich mich bei meinem Let’s Draw also ohne Rücksicht auf eventuelle Konkurrenz komplett ausspinnen. *fg

Trotzdem werde ich zuerst Material sammeln, sprich das Spiel spielen bevor ich zu zeichnen beginne. Wie bereits erwähnt wurde es 1986 veröffentlicht, mir läuft nichts weg. Im Gegensatz zu meiner Tim Turbo Fanfiction.

Deren neueste Folge hat zwar ewig gedauert, durch ihr Erscheinen und die weiterführung des Metaplots meine Story aber als obsolet abgestempelt. Sollte ich mir noch mehr Zeit lassen, kann ich das Ganze überhaupt als irrelevant kübeln. Da ich aber eine, uhm, gewagte Idee habe die mir, sobald sie umgesetzt ist, nahezu komplette Narrenfreiheit liefert, sollte ich da jetzt dann doch mal weitermachen…

Meine Notizen habe ich heute Vormittag durchgesehen und dabei auch wieder herausgefunden weshalb ich Fritzl zeichnen lernen wollte. Außerdem habe ich eine dritte Seite mit Fritzl-Skizzen gefunden die zwar etwas gewagter und ziemlich offtopic, aber imho auch qualitativ besser als die bereits veröffentlichten sind.

Brainfart-update…

Einen Großteil ds vergangenen Wochenendes habe ich damit verbracht mir Gedanken über das SR:HK-Let’s Draw zu machen, und im Endeffekt bin ich zu dem Schluß gekommen das SR:HK kein geeignetes Material darstellt.

Während mir ja etwas ähnliches wie Justin Halls Pokemon Sun Playthrough auf Dorkly vorschwebt (Die Betonung liegt auf „etwas ähnliches“…) befürchte ich das es mehr in die Richtung der 1998er Resident Evil Comics gehen würde. Diese beinhalteten neben „Fanfiction“ und den aus den Spielen bekannten Geschichten auch halbgare nahezu 1:1 Umsetzungen der Spiele. Das ich damals als frischgebackener Michael Turner/Marc Silvestri-Fan mit den Zeichenstilen nichts anfangen konnte (und immer noch nicht kann) war nur das geringste Problem das diese Hefte hatten.

Also habe ich die Idee wieder ad acta gelegt und mich mit Tim Turbo beschäftigt. (Um genau zu sein habe ich mir alle Folgen noch einmal angeschaut und Screenshots von Fritzl gemacht, und mir diese für eine ausgiebige Charakterstudie ausgedruckt.)

Da ich nicht davon ausging heute @wrk überfordert zu werden (und es damit auch gleich verschrieen hatte…) habe ich mir eine Handvoll alter DOS-Games als Beschäftigung zusammengepackt. Darunter befindet sich auch Might & Magic I .

Ein halbes Jahrhundert später habe ich es ge-DosBox-t, gepacht und zum laufen gebracht. Spasshalber habe ich mir noch das Handbuch heruntergeladen (Danke Gog) und ausgedruckt. Als ich es dann zu Lesen begann, schlug mein Hirn zu und… naja…

Mein Let’s Draw wird also Might & Magic, Book I: The Secret of the Inner Sanctum.

Die anfängliche Form ist ebenfalls bereits gegeben: Classic x-panel Comicstrip. Ich nehme an, sobald ich die Umsetzung der Installation abgeschlossen habe und zur Charakterschaffung komme, werde ich zu einer anderen Form wechseln, aber bis dahin passt das so am Besten.

Und, für den Anfang bleibe ich deutsch. Sollte ich tatsächlich weit genug kommen kann ich’s ja immer noch übersetzen, aber jetzt gilt mal das ich es für mich mache. ^_^

Brainfart of the day: Let’s Draw

Als Ultima Dragon habe ich mir vor hundert Jahren vorgenommen alle Ultima Teile dokumentiert durchzuspielen. Bis jetzt habe ich Akalabeth und Escape from Mount Drash geschafft. Für Ultima I ist alles vorbereitet, nur irgendwie komme ich nicht in die Gänge.

Dann habe ich beschlossen „nebenbei“ mit Final Fantasy das selbe zu tun, aber meine Detailversessenheit und ein Skalierungsproblem (Unterschiedlich große Screenshots kann man nicht zu einer Map kombinieren…) habe mich bei Teil I kurz vor dem zweiten Drittel Schachmatt gesetzt.

Dann war da die Elder Scrolls Anthology mit ihrer supertollen Diskettenversion von Arena auf einer ganzen CD. Dank Gog besitze ich jetzt auch die CD-Version aber auch hier hat mich die Komplexität der von mir erstellten Webseiten mitten drinnen erschlagen.

Zwischendurch habe ich noch überlegt einen Evil-Baldurs Gate I-Run und einen Low-Intelligence-Fallout I-Run zu starten, aber beides ist noch in der Vorbereitungsphase draufgegangen. Mein Reeh vs. Chrono Trigger ist zu aufwendig geworde und meine Idee den Singleplayermodus von Shroud of the Avatar zu dokumentieren scheiterte daran das sich das Spiel dank der MMORPG-Komponente nicht pausieren lässt und einen ausloggt wenn man länger inaktiv (zB. im Notepad an der Formulierung des Geschehenen feilt) ist.

Soviel zu meinen Nicht-Video-Let’s Play-Versuchen. Bis auf mein überambitioniertes Nocturne-Mega-Schnittprojekt habe ich alle sonstigen Video-Let’s Play-Ideen für das Waldtiere-Branding zusammen mit Robert reserviert.

Trotzdem kommt es immer häufiger vor das ich das Geschehen am Monitor nicht undokumentiert lassen möchte. Einerseits weil sich da immens viel Schwachsinn in meinem Kopf angesammelt hat und andererseits weil ich große Spiele nicht mehr am Stück schaffe (Allein schon die Pausen dank meines Schichtdienstes bremsen mörderisch aus.) und regelmäßig Probleme habe wieder Anschluß zu finden.

Soviel zum Thema Let’s Play. Zum Thema Zeichnen habe ich einen ähnlichen Wortschwall…

Ich habe jetzt zum zweiten Mal an Mab Graves Drawlloween Club teilgenommen und wieder habe ich es geschafft dannach eine Pause zu benötigen. Ein Monat lang jeden Tag vier Stunden und das teilweise auch noch zu Themen die mir nichts geben war hart.

Dazu kam da sich diesmal versucht habe eine fortlaufende Geschichte zu erzählen. Ohne Worte und jeden Tag ein Instagram-taugliches Quadrat. Das Experiment ging daneben. Gründlich. Auch das war meiner Lust weiterzumachen nicht wirklich zuträglich.

Die Idee mit dem Shadowrun-Comic auf der selben 1-Bild-pro-Tag-ohne-Worte-Basis habe ad acta gelegt. Obwohl die Geschichte als auch die Charaktere sehr weit ausgearbeitet waren. Aber [rant/ON] ich möchte ja niemanden mit einem Webcomic überfordern… [rant/OFF]

Meine Tim Turbo Fanfiction liegt aufgrund meiner Unfähigkeit Fritzl Fantom auf einem mir genügendem Level zu zeichen auf Eis. Ursprünglich wollte ich Drawlloween zum Üben verwenden, aber… ja… nein.

Vor mehreren Jahren hatte ich noch „Outage„… auch daran könnte ich weitermachen, aber auch hier haben, trotz normalen Comicseiten-Layout, nur die wenigsten das mit dem „fortlaufend“ realisiert. Das sich während dessen Entstehung (und auch seit ich es auf Eis gelegt habe) mein Level verbessert hat dürfte es auch nicht leichter machen anzuschließen.

Robert meinte ich würde für mich und nicht meine Umwelt zeichnen, sollte mir das alles also nicht so zu Herzen nehmen. Bis auf die Tim Turbo Fanfiction (Die Jungs haben soviel blöde Ideen in mein Hirn gepflanzt, die sollen gefälligst an der Ernte beteiligt sein! *fg*) mag das zwar stimmen, aber wie man an „Outage“ sieht neige ich dazu eingelegte Pausen extrem zu dehnen.

Mit Shadowrun und dem vorbereiteten Storyboard für mehr als 100 Bilder wollte ich dem entgegen treten, aber das von mir angedachte Format wäre ja zu viel. Und gerade Shadowrun wäre etwas gewesen bei dem ich unbedingt gerne Feedback gehabt hätte.

Ich sitze also bei zwei meiner Hobbies gerade auf dem trockenen. Warum nicht das Schlechteste daraus machen und sie kombinieren? Aktuell spiele ich mich mit dem Gedanken Shadowrun Hong Kong noch einmal zu probieren. Erstens nervet es mich das ich seinerzeit aufgegeben habe (Ich mochte die „neue“ Matrix nicht und das die Mission auf Zeit war habe ich erst mitbekommen als diese abgelaufen war. Der Frust darüber war… anhaltend.), zweitens hat das Spiel Achievments und drittens ist seit meinem Rage Quit ist die Extended Version veröffentlich worden.

Mit der Idee statt Screenshots Cartoons zu verwenden habe ich mich schon bei Shroud of the Avatar gespielt, aber da hat mich die „Schreib etwas im Notepad und du wirst ausgeloggt„-Sache ausgebremst. Diese Probleme gibt es bei den Shadowrun-Spielen nicht, deren Fenstermodus funktioniert einwandfrei.

Damit wäre es also beschlossen: /me wird ein Shadowrun-Hong-Kong-Let’s-Draw erstellen. Während dem Spiel werde ich mir im Notepad Notizen machen und zusätzlich Screenshots erstellen. Ein Video aufzunehmen ist glaube ich nicht notwendig.

Jetzt gerade bin ich mir unschlüssig wie ich das dann umsetzen will. Das normale Comicseiten-Layout ist traditionell hochformatig und am dynamischten, kann aber auf querformatigen Bildschirmen nur sehr wenig. Das Cartoon-ige „Mehrere-Panels-nebeneinander“ zwingt mich gerade dazu pro Strip ein in sich abgeschlossenes Stück Handlung zu verpacken. Mit dem derzeit etablierten Webcomic-Format bei dem elendiglich lang nach unten gescrollt wird habe ich mich bis jetzt nicht wirklich anfreunden können, aber theoretisch würde es mir die Dynamik wieder zurückbringen. Am liebsten habe ich gerade das von Tardaasa verwendete Swipe-Comic-Format. Quadratische Panels die in Facebook/Instagram „interaktiv“ gelesen werden können und sonst in 2×3 (oder 2×4) Blockform dargestellt werden.

Ich weiß noch nicht ob es die Geschichte erlaubt, aber ad hoc schwebt mir folgendes Frankstein’sches Monster vor: Ich erstelle ein Storyboard das für das vertikal unendliche Webcomic-Format ausgelegt ist, schaue aber das alle essentiellen Teile der Panels in einem Quadrat stattfinden damit ich aus diesen einen Swipe-Comic kreieren kann.

Na dann… vielleicht kann ich dieses Wochenende schon damit beginnen 🙂


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!

_SCREENCLICK

Gestern habe ich beim gelangweilten stöbern im QB64.org-Forum ein Projekt gefunden das (zumindest in der Anfangsphase, weiter habe ich nicht gelesen) wie der SpriteXtractor nur vorgegebene Maus- und Tastatureingaben abspult. Dazu verwendet es den Befehl _SCREENCLICK.

Ich wußte doch das so ein Befehl exisitert.

Mit _SCREENPRINT hätte ich in dem selben Wikieintrag auch die Tatstatureingabe entdeckt.
http://qb64.org/wiki/SCREENCLICK
http://qb64.org/wiki/SCREENPRINT

THEORETISCH müßte ich jetzt die von mir angewandte umständliche Version aus meinem Code gegen die neu gefundenen bereits in QB64 implementierten Versionen austauschen. So wegen potentiellen Geschwindigkeitsgewinn, Umständlichkeit und bla.

Da meine Probleme aber ganz wo anders liegen, lasse ich das aber jetzt so. Es funktioniert und ist in der verbleibenden Anwendung nicht komplizierter als die interne Version.

Der Eintrag zu _SCREENPRINT hat indes einen interessantes Beispiel:
DEFLNG A-Z
SCREEN _NEWIMAGE(640, 480, 32)
PRINT "OPENing and MAXIMIZING Notepad in 5 seconds..."; : _DELAY 5
SHELL _DONTWAIT "START /MAX NotePad.exe" 'opens Notepad file "untitled.txt"
'detect notepad open and maximized 'condition: 80% or more of the screen is white
DO 'read the desktop screen image for maximized window
s = _SCREENIMAGE
_SOURCE s
z = 0
FOR y = 0 TO _HEIGHT(s) - 1 'scan for large white area
FOR x = 0 TO _WIDTH(s) - 1
c = POINT(x, y)
IF c = _RGB32(255, 255, 255) THEN z = z + 1
NEXT
NEXT
IF z / (_HEIGHT(s) * _WIDTH(s)) > 0.8 THEN EXIT DO 'when 80% of screen is white
_FREEIMAGE s 'free desktop image
_LIMIT 1 'scans 1 loop per second
PRINT ".";
LOOP
PRINT
PRINT "NOTEPAD detected as OPEN and MAXIMIZED"


_SCREENPRINT "HELLO WORLD"
SLEEP 2
_SCREENPRINT CHR$(8) + CHR$(8) + CHR$(8) + CHR$(8) + CHR$(8) 'backspace 5 characters
SLEEP 3
_SCREENPRINT "QB64!"
SLEEP 2
_SCREENPRINT CHR$(1) 'CTRL + A select all
SLEEP 2
_SCREENPRINT CHR$(3) 'CTRL + C copy to clipboard
SLEEP 2
PRINT _CLIPBOARD$
_CLIPBOARD$ = "QB64 ROCKS!"
SLEEP 2
_SCREENPRINT CHR$(22) 'CTRL + V paste from clipboard
END

Der Teil der mich so besonders anspricht ist der in dem kontrolliert wird ob 80% des Bildschirms weiß sind. In meinem SpriteXtractor prüfe ich ja nur einzelne Pixel, aber hier wird ein ganzer Bereich herangenommen.

Der Code geht Höhe x Breite alle Pixel ab und zählt alle deren _RGB32-Wert weiß ist zusammen. Dann wird diese Summe (z) durch die Gesamtanzahl der geprüften Pixel (=Höhe*Breite) dividiert und sollte das Ergebnis größer als 0.80 sein gilt dies als Indiz das Notepad geöffnet ist.

Klar ist das es nur funktioniert wenn der Textbereich von Notepad vom Start weg tatsächlich mehr als 80% des Bildschirmes einnimmt. Mehrere Monitore oder manuell skalierte Fenster killen diesen Ansatz schnell.

Da ich beim vSNES afaik alle Fensterpositionen & größen in der .ini definiert habe sollte aktuell für das „erkennen“ ausgeblendeter Buttons eigentlich die Abfrage einzelner Pixel genügen, allerdings habe ich beim testen auch „leere“ Layer entdeckt. Dafür könnte ich die diese Routine adaptieren.

Des Rätsels Lösung…

In aller Kürze: Ich habe herausgefunden was es mit der 1536*864pixel G’schicht auf sich hat! Windows ist schuld. Um genau zu sein die vorgeschlagene Skalierung auf 125%.

Kaum habe ich wieder auf 100% umgestellt, hat wieder alles einwandfrei funktioniert. QB64 kann den vollen Bildschirm kopieren und alle Koordinatenangaben stimmen wieder überei.

Einzig die Schrift ist jetzt wieder fuzzelig und zwingt mich meine Brille aufzusetzen.

Vorerst ist die Welt also wieder gerettet. Problematisch wird’s erst wenn ein QB64-Programm auf einem 125%-skaliertem Desktop in den Breich geschoben wird der sich außerhalb des erfassbaren Bereichs befindet. Aber das ist ein QB64-Problem. (Das ich eventuell mal im Forum zur Sprache bringen sollte…)

Habe btw. Robert von meinen Ideen und Vorstellungen für SR:SNES:DRMM erzählt und nur positives Feedback bekommen. Er teilte vor allem meine Bedenken was die Verstaubtheit des Kampfsystems betrifft und meine Überlegungen von wegen Mouselock & Co. (Darauf gehe ich bei Zeiten mal näher ein…) gefielen ihm recht gut.

Ansonsten kann ich nur sagen das ich gerade mörderisch paranoid bin da im SceneView-Fenster bei unterschiedlichen Savestats unterschiedliche Buttons ausgeblendet sind. Ich werde also für jeden Schritt eine Kontrolle einbauen müssen ob dieser Schritt überhaupt ausführbar ist.

Außerdem bin ich draufgekommen das die Scenes unterschiedlich groß sein können. Das wird Auswirkungen auf das Exportieren der einzelnen Tiles haben da sich die Abstände zwischen den Mauskoordinaten ändern und waaahrg.

Aktuell hoffe ich das die Scene automatisch im Fenster skaliert wird und ich anhand der Größe der exportierten Scene auf die Abstände rückschließen kann.


Frohe Y-nachten…

Gestern habe ich eine halbe Ewigkeit daran herumgebastelt wie ich kontrollieren könnte ob das Scene-View und Memory-View Fenster aktiviert sind nur um dann zu entdecken das sich in der vSNES.ini die Zeile WindowList=Form_Scene,Form_Memory befindet.

Während dieser Versuche habe ich entdeckt das vSNES manchmal länger lädt als die Pausen die ich dafür eingeplant habe andauern. (Warum auch immer, ein System dahinter konnte ich nicht finden.). Also habe ich die oben erwähnte Kontrolle wieder aus der Versenkung geholt und adaptiert.

Im Prinzip wird der Teil des Bildschirms in dem zu diesem Zeitpunkt der noch blauen Scene-View Fensters sein sollte in den Speicher gelegt und dann auf das Vorhandensein der blauen Farbe kontrolliert.

In der Praxis habe ich entdecken dürfen das QB64 nicht nur die 1536*864px-G’schicht sondern auch ein prinzipielles Problem mit der Bildschirmausgabe hat. Ich kann den Vergrößerungsfaktor (noch) nicht genau bestimmen, aber im Ausschnitt links ist die 1 um drei Pixel und die 2 und vier Pixel vergrößert dargestellt!?!

(Im Beispiel links liegt Notepad mit den Ziffern im Hintergrund, darüber liegt der von QB64 erstellte Screenshot dieser Spalte. Rechts daneben ist kA mehr warum ein Teil vom QB64-Fenster.)

Da sich alle Koordinaten weder auf diesen Maßstab noch den der originalen Bildschirmauflösung beziehen, ist es nach vor nur per Trial & Error möglich auf funktionierende Werte zu kommen. Erschwerend kommt auch noch dazu das auch die per POINT ausgelesenen RGB-Daten nicht den in Photoshop angezeigten entsprechen. Und soll ich auch noch erwähnen das _putimage; gerade auch nicht wirklich so funktioniert wie ich gewohnt bin? Nämlich gar nicht.

Ich hoffe ich finde demnächst heraus wo mein Fehler liegt, denn irgendwie möchte ich nicht wahrhaben das QB64 dermaßen kaputt ist.

Heute,  so als eine Art Weihnachtswunder, habe ich es endlich geschafft die Kontrolle umzusetzen. Eigentlich sollte ich jetzt weiter am exportieren basteln… aber ich habe keine Lust. Vielleicht später…

Update: Habe 137 Backup-vSNES.ini’s gelöscht und beschlossen das dies automatisch nach dem Beenden passieren sollte. Gesagt getan, vor Ende des Programms wird jetzt die ursprünglich vorhandene vSNES.ini wiederhergestellt. (alias zurück umbenannt). Weil ich die temporäre RGB-Wert-Anzeige noch nicht deaktiviert hatte, habe ich mich in diesem Zug auch gleich mit der „Status:“-Angabe gespielt.

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.

Sieht gar nicht so tot aus.

Hat jetzt ein paar Tage gedauert bis ich wieder motiviert war… bis ich genug motiviert war um um zu starten.

Während ich also meinen Hintern in die Höhe hievte blieb ich wieder bei der 1536*864px-G’schicht picken. Bei  meinen Recherchen stellte sich heraus das SPI_GETWORKAREA verwendet wird und „Work Area“ ein dehnbarer Begriff ist:

Retrieves the size of the work area on the primary display monitor. The work area is the portion of the screen not obscured by the system taskbar or by application desktop toolbars. The pvParam parameter must point to a RECT structure that receives the coordinates of the work area, expressed in physical pixel size. Any DPI virtualization mode of the caller has no effect on this output. To get the work area of a monitor other than the primary display monitor, call the GetMonitorInfo function.
(Source)

Nachdem ich mich eine Runde gefreut und vergeblich eine Alternative gesucht habe, fiel mir ein das _SCREENIMAGE auch schon herumzickt und ich keine Ahnung habe wie ich das repariere/umgehe. Außerdem war da ja noch die Windows+PrtScrn-Kombination.

(Trotzdem: Die geschwundene Breite konnte ich auf das Startmenü rückführen, die geschwundene Höhe auf die Vorschaufenster der minimierten Tasks. Sollte ich Lust haben könnte ich mal versuchen die Aero-Oberfläche zu deaktivieren… irgendwann mal. 😉)

Zurück in QB64 habe ich mich mit der Verzeichnisstruktur beschäftigt. Der SpriteXtractor (Was für ein Angebername… *g*) kontrolliert beim Start ob es einen Eigene Bilder\Screenshot-Folder gibt (Inkl. kernel32-bezogenem auslesen des Pfades…), wo sich die gerade ausgeführte .exe befindet, wie es mit den IN/OUT-Foldern steht (Falls keine existieren werden sie erstellt.) und ob vSNES im gleichnamigen Unterordner geparkt ist.

Dann habe ich eine Subroutine eingefügt die eine Liste aller .zst im IN-Folder erstellt. (Ziemlich umständlich umgesetzt aber effektiv…)

Aus einer Laune heraus habe ich mich mit der vSNES.ini gespielt und dabei entdeckt das sich in dieser die Fensterpositionen, die letzten Pfäde und sonst noch viel Sinnvolles befindet. Ich kann mir als die angedachte Positions-Kontrolle dadurch ersparen.

Der nächste Schritt bestand also daraus diese vSNES.ini zu bearbeiten. Eines Tages lerne ich ganz sicher wie ich Textdateien editiere und nicht jedes mal neu erstellen muss.. egal. Kurzfassung, ja es funktioniert. (Genauso umständlich umgesezt wie die .zst-Liste… aber hey, solange es funktioniert.)

Als nächstes stand dann schon vSNES an. Dank ich die .zst fortlaufend umbenannt habe (0001_Shadowrun.zst, 0002_Shadowrun.zst, 0003_Shadowrun.zst, …) ist es nicht notwendig das Rom zu laden da dies genauso heißen müsste wie die .zst und ich also für jedes .zst eine Kopie des Roms haben müsste. Bis jetzt habe ich es afair aber noch nie benötigt. Sollte ich herausfinden das es doch notwendig ist, kann ich mich immer noch mit dem Thema befassen. (Und wenn es nur eine Routine ist die Kopien erstellt und umbenennt…)

Das Laden des .zst funktioniert dank der Tastatursteuerung des Programms einwandfrei. (Vor allem das man der Listenummer des aktuellen Files entsprechend „Cursor Runter“ drücken muss ist eine unheimliche Erleichterung.). Das Scene-Fenster öffnen und die relevanten Reiter aktivieren ebenfalls.

Jetzt käme das Speichern der einzelnen Layer an die Reihe. Dazu brauche ich aber noch ein sinnvolles Ablagesystem und muss kontrollieren ob die ausgeblendeten Reiter ausgeblendet bleiben. Sollten sie das nicht tun, muss ich einen Plan entwickeln wie ich herausfinde ob ein Reiter ausgeblendet ist.

Das die für SetCursorPos notwendigen x/y-Koordinaten nicht mit denen die ich im Photoshop aus dem Screenshot auslese übereinstimmen wundert/wurmt mich btw. auch noch.