Hallo Besucher, der Thread wurde 3,2k mal aufgerufen und enthält 15 Antworten

letzter Beitrag von Rapid Eraser am

Drei Fragen zu Pixel Perfect

    Da dieses tolle Tool irgendwie an mir vorübergegangen ist, erst heute - nach Jahren also - meine Fragen aus GoDot-Sicht dazu. Sie drehen sich um das gepackte Bildformat, das ungepackte habe ich schon im Kasten. Herausgefunden habe ich erstmal Folgendes: Das gepackte Bild fängt vier Bytes früher an (statt an $3c00 an $3bfc) und wird nach einem einfachen RLE gepackt (Indikator, Zähler, Byte), der Indikator ist das Byte an $3bff und lautet $11. Jetzt die Fragen.


    1. Ich stelle fest, dass der Zähler immer um eins niedriger ist als die Anzahl der gezählten Bytes. PP zählt also mit $00 los. Wie geht PP mit 256 Wiederholungen um? Ist das $11, $00, $xx?
    2. Wie behandelt PP ein Vorkommen des Packbytes selber? $11, $01, $11? Oder anders?
    3. Was bedeuten die drei allerersten Bytes im File? Bei einem Beispielbild steht da dreimal $10, es kann sich also nicht um Farben handeln (für Border oder Hintergrund oder so, der Hintergrund steht eh an $7f7f).


    Würde gern schnell den Saver komplettieren und dann noch den IFLI-Lader mit PP updaten. Wer kennt sich also aus und kann helfen?


    Arndt

    Ich habe gerade mal in den code geschaut


    Zitat von GoDot

    1. Ich stelle fest, dass der Zähler immer um eins niedriger ist als die Anzahl der gezählten Bytes. PP zählt also mit $00 los. Wie geht PP mit 256 Wiederholungen um? Ist das $11, $00, $xx?

    Stimmt, der gespeicherte Zähler ist immer gleich runlength-1. Daraus folgt das bei einem Run mit einer Länge von 256 Zeichen der Wert $ff als Zähler abgespeichert wird. Höher als $ff kann der Zähler auch nicht werden.
    256 Wiederholungen eines Zeichens (also einen run von insgesamt 257 Zeichen länge) würde in Form eines Runs + einem darauf folgenden Literal codiert werden.


    Zitat von GoDot

    2. Wie behandelt PP ein Vorkommen des Packbytes selber? $11, $01, $11?

    Genau so. Der Escapecode wird immer in Form eines Runs gespeichert. Der zugehöre Zähler kann von $00-$ff gehen, wodurch sich Sequenzen von 1-256 aufeinanderfolgenden Escapecodes darstellen lassen. (bei allen anderen Bytes wird zuvor geprüft ob die runlänge > 3 ist. falls ja wird ein run codiert, falls nicht werden die Bytes einfach so ausgegeben)


    Zitat von GoDot

    3. Was bedeuten die drei allerersten Bytes im File? Bei einem Beispielbild steht da dreimal $10, es kann sich also nicht um Farben handeln (für Border oder Hintergrund oder so, der Hintergrund steht eh an $7f7f).

    K.A... Ich konnte auf die Schnelle keinen Programmteil entdecken welcher diese Bytes beschreibt. Möglicherweise ist es eine Magicnumber?

    Zitat von Rapid Eraser

    Möglicherweise ist es eine Magicnumber?

    Ah, vielen Dank für die Infos! Der Quelltext ist sehr nützlich, das bedeutet nämlich, dass ich statt der $11 (die ich im Beispielbild als Escape-Code gefunden habe) auch irgendeinen anderen verwenden kann. Eine Optimierung dieses Codes halte ich sowieso für überbewertet, weshalb ich in GoDot (und dann in Zukunft sicher auch im Saver für Pixel Perfect) einfach $AD verwende. Liegt bei meinem Namen irgendwie nahe, hehe... ;-)


    Meine Encodierungsroutine erscheint mir kürzer. Hier der Code:

    Dafür hat mein Code den Nachteil, nicht 256 zu erreichen. Ist aber zu verkraften, finde ich.


    Bleiben die drei $10 am Fileanfang: Die bedeuten was, denn wenn ich sie ändere, wird das Bild nicht mehr ordentlich dargestellt. Außerdem scheint das gepackte Bild seine Hintergrundfarbe irgendwo anders herzubeziehen als das ungepackte, denn im obigen Fall kriege ich immer Weiß (ich setze aber generell Schwarz...)


    Arndt

    Kann es sein, dass die $10 den ebenfalls um 1 verringerten Indicator darstellt, der in dieser Datei verwendet wird, und dass der Indikator in jedem File anders ist? So macht es jedenfalls der Packalgorithmus der Gfx/Anims in Bards Tale 1 von Burgerbecky.
    Dort sind die zwei verschiedenen Indikatoren in jedem File anders und werden ermittelt durch die ersten Bytes, die in den Bilddaten nicht vorkommen, um ein Escapen zu vermeiden.

    Zitat von GoDot

    Eine Optimierung dieses Codes halte ich sowieso für überbewertet, weshalb ich in GoDot (und dann in Zukunft sicher auch im Saver für Pixel Perfect) einfach $AD verwende. Liegt bei meinem Namen irgendwie nahe, hehe... ;-)

    Ah, nein, mit $AD funktioniert es leider nicht. Aber ein $RE würde gehen. :whistling:


    Zitat von GoDot

    Bleiben die drei $10 am Fileanfang: Die bedeuten was, denn wenn ich sie ändere, wird das Bild nicht mehr ordentlich dargestellt.

    Du sollst eine Magicnumber ja auch nicht ändern, Arndt. :P


    Wenn ich das richtig erkannt habe dann wird nach dem Laden eins Bildes, egal ob gepackt oder ungepackt, die folgende Routine aufgerufen (die Daten werden nach Adresse $4000 geladen):

    Schaut für mich ersteinmal so aus als würde die $10 $10 $10 tatsächlich nur zur Unterscheidung von gepackten und ungepackten Bildern dienen.


    Zitat von GoDot

    Außerdem scheint das gepackte Bild seine Hintergrundfarbe irgendwo anders herzubeziehen als das ungepackte, denn im obigen Fall kriege ich immer Weiß (ich setze aber generell Schwarz...)

    Hast du mal probiert ein Bild mit verschiedenen Hintergrundfarben abzuspeichern? Da müsste man im Vergleich ja herausbekommen wo die Farbe gespeichert steht.



    PS: bei der Kommentierung des Packers habe ich mich bei den Kommentaren gegen Ende hin glaube ich mit Input- und Output-Buffer vertan. Und wahrscheinilch stecken da auch noch andere Fehler drin... Darauf sei ein geneigter Leser hiermit hingewiesen.

    Zitat von Rapid Eraser

    C:2447 78 SEI
    .C:2448 A9 34 LDA #$34
    .C:244a 85 01 STA $01
    .C:244c AD 7F 83 LDA $837F
    .C:244f 48 PHA

    Ah! Da steht also, dass beim gepackten Bild die Hintergrundfarbe nicht aus der Bitmap des ersten Teilbildes (von $7f7f) geholt wird, sondern nun aus dem ersten Videoram des zweiten Teilbildes (von $837f). Das probier ich gleich mal aus. :-)


    Und: $AD funktioniert, hehe. Mit $RE hättest du ein Problem. :P


    Arndt

    Ich hab mal reingeschaut. Die Stelle ist mitten im gepackten Code, d.h. die Hintergrundfarbe bei einem gepackten Bild ist nach dem Laden im Editor immer zufällig! Das ist ein Bug! Die Adresse $837f macht keinen Sinn! In meinem Bild (wo Weiß herauskommt) steht da $61, das Lo-Nibble ist $01, also weiß.


    Was nun?


    Arndt

    Zitat von GoDot

    Ich hab mal reingeschaut. Die Stelle ist mitten im gepackten Code, d.h. die Hintergrundfarbe bei einem gepackten Bild ist nach dem Laden im Editor immer zufällig!


    Hmm, ich habe den Code noch anders verstanden. Getestet habe ich es nicht, aber für mich sieht das Konzept folgendermaßen aus:
    1) lade das Imagefile (egal ob gepackt oder ungepackt) nach Adresse $4000
    2) überprüfe anhand von $10 $10 $10 ob die Daten gepackt sind
    2a) falls ja dann entpacke sie nach Adresse $4000 (ab $1b29/$1b59). anschließend stehen sie im gleichen Format wie ein ungepacktes Bild im Speicher (das sollte ja so aussehen wie in den docs beschrieben):
    $3c00-$4000 $d800 memory
    $4000-$6000 color memory 1
    $6000-$7f40 bitmap 1
    $7f7f background color
    $8000-$a000 color memory 2
    $a000-$bf40 bitmap 2
    3) egal ob das Bild von Anfang an ungepackt war oder gerade entpackt wurde, die Daten ab $4000 müssen nun im Speicher neu arrangiert werden damit der VIC das Bild darstellen kann (ab $2447). Da die Daten gegenüber der obigen Tabelle einen Offset von $0400 haben (sie liegen ja ab $4000 im Speicher und nicht ab $3c00) findet sich die Hintergrundfarbe dementsprechend nicht bei $7f7f sondern bei $837f. Der Wert wird vor dem rearrangieren gerettet (ab $244c), dann wird "color memory 2" nach $8000-$a000 kopiert - wodurch $837f freilich überschrieben wird - und zum Schluß wird die gerettete Hintergrundfarbe nach $7f7f geschrieben (ab $247f), wo sie ja auch hin soll.

    Zitat von Rapid Eraser

    1) lade das Imagefile (egal ob gepackt oder ungepackt) nach Adresse $4000
    2) überprüfe anhand von $10 $10 $10 ob die Daten gepackt sind
    2a) falls ja dann entpacke sie nach Adresse $4000 (ab $1b29/$1b59). anschließend stehen sie im gleichen Format wie ein ungepacktes Bild im Speicher

    Ja, nach dem Source-Text zu urteilen, soll das wohl so sein. Hm. Da muss dann was schief gehen. Bei allen anderen Bildern, die ich getestet habe, kommt ebenfalls Weiß raus. Mir fällt da nur ein, dass ich das Ganze auf VICE teste und der Autor ausdrücklich sagt, PP sei für die Real Machine geschrieben. Leider macht es mein alter (erster und nunmehr einziger) C64 nicht mehr (er steht hier als zu bewunderndes Ausstellungsstück im Regal), ich kann das nicht selber verifizieren. Der Saver ist auf godot64.de zum Download (im dritten D64, Name: svr.PixelPerfect). Vielleicht ist das Problem ja gar keins.


    Hehe, und ich weiß jetzt, was dreimal $10 sein soll: "ppp" in Bildschirmcode! :-) Na, sowas! :-)


    Arndt

    Zitat von GoDot

    Da muss dann was schief gehen. Bei allen anderen Bildern, die ich getestet habe, kommt ebenfalls Weiß raus. Mir fällt da nur ein, dass ich das Ganze auf VICE teste und der Autor ausdrücklich sagt, PP sei für die Real Machine geschrieben.

    Ich habe es auch nur mit vice v2.4 getestet, und dort zumindest kann Perfect Pixel selber die Hintergrundfarbe korrekt speichern/laden (getestet nur mit dem Beispielbild).


    Wenn ich in der post-load-routine

    Code
    1. .C:2447 78 SEI
    2. .C:2448 A9 34 LDA #$34
    3. .C:244a 85 01 STA $01
    4. .C:244c AD 7F 83 LDA $837F
    5. .C:244f 48 PHA

    das LDA $837f in z.B.

    Code
    1. .C:244c AD 7F 83 LDA #$06
    2. .C:244e EA NOP

    ändere, dann setzt er nach dem Laden auch tatsächlich diese Hintergrundfarbe. In $837f sollte also durchaus die Farbe drin stehen.
    Wie sahen denn deine Tests aus? Magst du mir mal die Sourcen für deine pack/depack-routinen per pm senden?





    Zitat von GoDot

    Hehe, und ich weiß jetzt, was dreimal $10 sein soll: "ppp" in Bildschirmcode! :-) Na, sowas! :-)

    Aahhhsoooistdas... 8o

    Da haben wir's ja schon:

    JSR PACK verändert den Accu. Wenn man in WRITE0 das BNE WR0 durch BNE WRITE0 ersetzt dann klappt's. (zumindest bei dem PP-Beispielbild hat er dann korrekt schwarz als BG-Color abgespeichert. ansonsten hatte er in dem Bereich halt immer Einsen (cnt) ausgegeben).

    Jetzt ist alles fertig: Saver (wieder mal mit eurer Hilfe!) und ebenso der Lader (der jetzt vier bzw. fünf Formate automatisch erkennt). Download auf der Downloadseite von GoDot.


    Arndt


    :essen: (Brauch ich jetzt)

    Zitat von GoDot

    Oh Mann! 8\| Danke!

    Es war mir ein Vergnügen. *verbeug*


    Zitat von GoDot

    Jetzt ist alles fertig: Saver (wieder mal mit eurer Hilfe!) und ebenso der Lader (der jetzt vier bzw. fünf Formate automatisch erkennt). Download auf der Downloadseite von GoDot.

    Lol, ein Freund von mir würde das nun gleich zum Anlass nehmen in seiner nächsten Bewerbung zu schreiben das er "Co-Autor einer Middleware einer inter-plattform orientierten Multimedia-Solution" sei (oder so ähnlich; er konnte noch viel besser schwätzen als ich).
    Hmm, er hatte seinerzeit (vermutlich aufgrund einer solchen Bewerbung) auch sofort eine Greencard bekommen und ist die die USA abgedampft. Mittlerweile lebt und arbeitet er in Australien und macht ordentlich Kohle. Vielleicht sollte ich es ja auch mal auf diese Weise versuchen..? :gruebel


    Zitat von ZeroZero

    Cool!!! Good job!

    Ganz meine Meinung. :thumbup: