Beiträge von GoDot im Thema „Drei Fragen zu Pixel Perfect“

    Jetzt ist alles fertig: Bitte melde dich an, um diesen Link zu sehen. (wieder mal mit eurer Hilfe!) und ebenso der Bitte melde dich an, um diesen Link zu sehen. (der jetzt vier bzw. fünf Formate automatisch erkennt). Download auf der Bitte melde dich an, um diesen Link zu sehen. von GoDot.

    Arndt

    :essen: (Brauch ich jetzt)

    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 Bitte melde dich an, um diesen Link zu sehen. (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! :smile: Na, sowas! :smile:

    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

    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. :smile:

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

    Arndt

    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... :wink:

    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

    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