Posts by GoDot

    Zwischenstand beim OCP-Saver: Alle Routinen tun bereits das, was sie sollen (schreiben also ein exakt gerendertes OCP-Bild auf die Diskette). Allerdings ist OCP Art Studio sehr pingelig, was die im Header eingetragenen Dateilängen und die Header-Checksumme angeht. Stimmen die nicht mit dem File überein, dann stürzt OCP ab. ManageDsk ignoriert hier die "liberalen" Einstellungen. Ich hatte gehofft, dass ich einfach immer die Maximallänge eines Bildes eintragen kann ($4000), um mir zu ersparen, vor dem Speichern einen Komprimierungsdurchlauf durchzuführen. Leider hat sich diese Hoffnung also nicht ergeben. Daher bin ich jetzt dabei, einen Speicherdurchlauf ohne Speichern zu absolvieren, damit ich vorher die genaue Dateilänge kenne.


    Ehrlich? Muss das sein? Das hat mich schon bei IFF genervt... ;-)


    Arndt


    PS: Beim OCP-Lader werde ich wohl noch mal die Farbpalette ändern, damit Lader und Saver das gleiche Ergebnis liefern. (Es geht um die beiden Cyan-Werte, die die C64-Graus ersetzen.)

    Neues Modul: mod.MapColorbase


    Damit kann man sperrige Bilder (also Bilder, die sich wegen merkwürdiger Farben partout nicht konvertieren lassen) dennoch zur Mitarbeit bewegen. Hier ein Beispiel mit einem Bild aus der CPC-Welt:



    Kann man was mit anfangen, oder? Wie das geht, im Online-Handbuch (Link in der Überschrift).


    Arndt

    haben die, wie beim C64, auch Klartext-Namen?

    Ja, haben sie. Man kann theoretisch je Bild 16 aus den 27 Farben festlegen.

    wenn der CPC geringe Farbbeschränkungen je Kachel hat als der C64

    Hat er, jede Farbe kann beliebig verteilt auf dem ganzen Canvas erscheinen, also auch alle 16 in einer Kachel (soweit ich das verstanden habe).

    die beiden fehlenden Grautöne durch ein Grau/schwarz- und ein Grau/weiß-Raster darzustellen

    Das wäre aber nur in Doppelpixel-Größe möglich, also so, wie der Koala Painter (das Malprogramm) das gemacht hat. Über eine solche Grau-Entsprechung hab ich schon nachgedacht, aber erstmal wieder verworfen, weil automatische Konversionen nicht auf Ästhetik achten, und das Ergebnis wohl eher bescheiden aussähe.

    Ich hatte vor Jahren mal angefangen was in Excel zu basteln.

    Danach bin zuerst vorgegangen (s. Post #2), aber die Zuordnungen werden dem Ursprungsbild nicht gerecht. Daher meine Palettenänderungen, die man in den Froschbildern sieht.


    Wie werden die Dateien eingelesen? Direkt vom DSK oder ziehst Du die mit einem anderen Tool runter?

    Ich konvertiere mit GoDot unter VICE, speichere auf D64, ziehe die Bilder mit Dirmaster auf den PC und schreibe sie von dort mit ManageDsk in ein CPC-DSK-File. Auf dem CPC (entweder mit JavaCPC oder mit Winape) verwende ich Advanced OCP Art Studio. Die Screenshots hier hab ich mit XnView gemacht.


    Arndt

    Ich bin jetzt mal zufrieden. Wer vom C64 konvertieren will, kann das nun in beliebiger Menge tun. Manche Bilder sind weniger geeignet (wie das schon auf der Seite aus Post #66 anklang (Bilder mit viel Grau, Bilder, die Real-Gesichter zeigen). Andere kann man aber auf dem CPC weiterbearbeiten (wie auch auf obiger Seite zu sehen) und hat dann super Ergebnisse. Hier noch ein Beispiel:



    Ich mach dann mal weiter mit den abschließenden Arbeiten.


    Arndt

    hab sie durchgelesen (der übliche Wir-sind-besser-nein-wir-Kram). Die Konversionen dort waren zu einem großen Teil _Nachbearbeitungen_, es wurden komplett _andere_ Farben verwendet (aber gut gemacht). Ich nehme mit, dass die beiden Graus meistens mit Dunkel- und Hellcyan ersetzt wurden, außerdem ist bei mir das Hellrot noch zu lasch (bzw. das Orange im Vergleich damit). Hat schon was gebracht. Danke!


    Arndt

    Frag mal Retrofan. Der kann doch gut pixeln.

    Nein, das nützt nichts, denn diese beiden Farben fehlen komplett im CPC. Ich hab sie jetzt ersetzt durch das dunkelste Magenta und durch Bright Cyan. Am besten im Pilz (s. Bild) und in den Steinen dort zu erkennen. Was ich probieren will, ist, ob meine jetzige Farbwahl bei möglichst vielen Bildern akzeptabel ist. Dann kann ich den Saver abschließen und allgemein zur Verfügung stellen. Dauert etwas. Soll ich hier weitere Bilder posten? Andere Vorschläge?


    Arndt

    Hab die Farben geändert, sind jetzt besser. Nur die beiden Grau gefallen mir weiterhin nicht. Screenshot aus Winape:



    Ich probier noch ein bisschen... ;-)


    Arndt

    Das erste von GoDot generierte CPC-Bild (Screenshot aus JavaCPC):



    Was mir Probleme macht, ist, dass der CPC kein dunkelgrau/hellgrau hat. Ich hab die beiden Farben erstmal durch dunkelblau/cyan ersetzt (im Pilz links und in den Steinen unter dem Frosch zu erkennen). Außerdem gefällt mir das Braun _überhaupt_ nicht (im Körper des Frosches), gibt es irgendwie einen sinnvollen Ersatz dafür? Ein Tipp?


    Arndt


    Edit: Im zweiten Bild sieht man das auch deutlich: hellgrau ist ersetzt mit cyan, dunkelgrau mit dunkelblau (Rand des Schädels).

    Bin sehr zufrieden mit meiner Watch5.


    Alle Vorteile, die hier genannt wurden, kann ich bestätigen. Die EKG-Genauigkeit wird sogar vom Herz-Zentrum in Bad Oeynhausen bestätigt (gehört zu den führenden Herzkliniken in Deutschland). Noch nicht genannt: Solltest du mal hinfallen und bewusstlos liegen bleiben, wird automatisch eine Nachricht an die nächste Notfall-Einrichtung und an deine angegebenen Kontakte abgesetzt, einschließlich GPS-Position. Das funktioniert, zum Ausprobieren habe ich einen Sturz simuliert (heftiger Schlag mit der Hand) und die Watch fragte sofort nach, ob es mir gut gehe (was man betätigen kann und dann passiert auch nichts).


    Arndt

    bei vielen Games oft das Gefühl gehabt das der 64er mehr Farben in einer höheren Auflösung darstellen kann als ein CPC

    Daran kannst du sehen, wie gut die Graphicians mit den Farben und Pixeln am C64 umgehen können. Ich bin auch bisweilen hin- und hergerissen, was mir da auf meinem C64-Bildschirm alles entgegenleuchtet. Schau dir einfach mal so ein Bild hier an oder auch so eins. Alles schlichtes Multicolor. Das haut mich jedesmal um!


    Arndt

    Neuer Lader: OCPAmstrad!


    Lader für Bilder der CPC-Computer von Schneider bzw. Amstrad. Erwartet auf der CPC-Seite Mode-0-Bilder in 16 der möglichen 27 Farben und erzeugt auf C64-Seite Bilder im IFLI-Format. Ein Saver folgt noch, damit die CPC-Fans auch was davon haben. Damit sind auch die lange vernachlässigten CPC-Fans mit im GoDot-Boot! :-)



    Hier das Demobild von der Art-Studio-Diskette. Es gibt im Forum auch einen expliziten Thread zu diesem Thema.


    Arndt

    Snoopy : Das einzige brauchbare Bild war dies hier:


    jardin3.gif


    Alle Farben direkt im C64 darstellbar, also rein Multi. Wenn ich den GoDot-Saver fertig habe, sehen alle konvertierten Bilder auf dem CPC genauso klar aus wie dieses hier. Darauf freue ich mich schon mal. ;-)


    Arndt

    Guck mal hier

    Hab ich. Die Bilder sind ohne AMSDOS-Header. Ist das üblich? Dann muss ich noch eine Erkennung dafür einbauen. Und WIN-Dateien sind sowas wie Clips (Bildausschnitte), die kann der Lader auch nicht. Die zwei OCP-Dateien sind C64-Bilder. Gibt's nicht noch mehr Bilderquellen?


    Arndt

    Vorläufig fertig!


    Ich hab jetzt noch ein Flickerfix für die IFLI-Farben eingebaut, dann kann man die auch in Multicolor bereits erkennen und in IFLI flackert's eben weniger. Sieht so aus (Screenshot in VICE):



    Jetzt könnt ihr die drei Versionen vergleichen.


    Der Lader ist nur für Mode-0-Bilder (und weist andere ab), gepackt oder ungepackt. Was mir fehlt, sind OCP-Bilder. Ich finde partout keine im Netz! Weiß einer was? Devilmarkus ?


    Arndt

    Und auch das gelöst. Die Kompression funktioniert so, dass im File (in diesem Fall) alle 4096 Bytes das Kompressionsflag (5 Bytes lang) wiederholt wird. Das wusste ich nicht und hatte daher vier Mal fünf Bytes zu viel geladen. Merkwürdiger Algorithmus!


    Die Bilder kommen als IFLI-Bilder in GoDot an, die Farben sind aber so gewählt, dass sie auch in Standard-Multicolor in etwa so aussehen wie im Original. Siehe hier:



    Das ist das Testbild in Multicolor. Geht auch.


    So, jetzt auf die Suche nach vielen Mode-0-Bildern, um den Lader zu testen. Dann der Saver (dann brauche oobdoo s und Mac Bacon s Diagramm wieder, Post #2) ;-)


    Arndt

    Ok, das Farbproblem ist behoben (ich hatte in der Lookup-Tabelle zwei Zeilen vergessen - kann ja mal vorkommen ;-) )



    Jetzt ans Dekodierproblem...


    Arndt

    Erster Erfolg:



    Dies ist eins der Beispielbilder auf der OCP-Diskette (RAYTRACE.SCR), Mode 0, 16 aus 27 Farben. In GoDot verwandle ich die Farben in IFLI-Pseudofarben. Dies hier ist mit svr.PNG abgespeichert. Es stimmen ein paar Sachen noch nicht, z.B. sollte das Schachbrettmuster nicht weiß/himmelblau, sondern hellpurpur/himmelblau sein. Außerdem hab ich ich noch einen Fehler im Entpackalgorithmus, aber das sollte zu lösen sein... ;-)


    Arndt

    Und verständlich ist keins der beiden Diagramme

    :emojiSmiley-12:


    Arndt


    (Zum Konvertieren brauch ich das Diagramm so herum. Reicht ja, wenn ich das verstehe. Ansonsten wollte ich nur den Fortschritt am Konverter vermelden und meine Überlegungen, die ich dazu angestellt habe.)

    Das Diagramm in Post #2 ist ziemlich irreführend. Hier mal ein korrektes (und verständliches) Diagramm für die Pixelverteilung in Mode 0:



    Ein Databyte von $c0 (also Bit 7 und 6 gesetzt) würde dann umgewandelt in die beiden Pixel mit den INK-Indices $11 (also linker Pixel=1, rechter Pixel ebenso). Dieser Wert (jeweils 1) ist also der Index in die Tabelle der Farben aus der Palette (von 16 Farben) im Palette-File. Vergesst die Post#2-Darstellung, die hat mich zwei Tage Rumprobieren gekostet! :-) Die hier sieht ja auch viel schöner aus, oder? ;-)


    Arndt