Hallo Besucher, der Thread wurde 101k mal aufgerufen und enthält 560 Antworten

letzter Beitrag von GoDot am

GoDot Infos

    Hi, Arndt,

    Zitat von GoDot

    Ich hab da was mit Koala-Loader gesehen, reicht das aus?

    das Paar "KOALA EXPORT" und "C64 KOALA LOADER" geht tatsächlich in die andere Richtung: mit KOALA EXPORT kann ein Bild im MG-Format auf dem VC-20 nach Koala gewandelt werden und das zweite Programm ist ein einfacher Viewer auf dem C64, um Koala-Bilder einzuladen.


    Als "Standard"-Import Programme laufen auf dem VC-20 mit MINIGRAFIK die zwei Programme "PGM IMPORT" und "PGM IMPORT MONO". Letzteres ist ideal zum Import von Line-Art - damit hab' ich z.B. eine S/W-Version des 313 mit Donald hineingezogen (vorher auf dem PC mit IrfanView unter Berücksichtigung des Pixel-Aspekts vorverarbeitet) und dann in MINIPAINT koloriert. Die gerasterten Bilder sind mit dem ersten Programm entstanden: das nimmt ein 80x192 *.pgm-Graustufen-Bild her und rastert es in 13 Abstufungen. Die "End"-Farben sind immer weiß und schwarz, aber die beiden Haupt-Zwischenfarben kann man aus den verfügbaren 16 Farben frei wählen (die erste Farbe sollte aber dunkler als die zweite sein, sonst sieht's merkwürdig aus).


    Mit MG sind auch 'Intra'-Format beliebig komplizierte Operationen möglich, ich hab' da mal ein Beispiel angehängt, wo aus vier MG-Bildern eine Kollage gebaut wird. Die Anzeige erfordert in diesem Fall dann allerdings über das "pure" MG-Display hinaus noch eine Raster-Routine, welche die globalen VIC-Farben mitten in jeder Rasterzeile umschaltet:


    pokemon_20th.png


    Mit *.ppm und *.pgm als Eingangs-Dateiformat hab' ich auch auf dem PC noch einen Prototypen für einen PPM-nach-MG Konverter (in C geschrieben) laufen. Der optimiert für alle möglichen Kombinationen der globalen Farben (8x16x16 = 2048) *alle* Attributzellen einzeln, mit Auswahl Hires/Multicolor und Vordergrund und wirft dann das Bild mit dem geringsten Fehler raus. So sind z.B. die Bilder "PARROT" und "TRON" entstanden. Allerdings "beißt" sich dieser Konverter gerne mal fest wenn einfach keine Kombination der globalen Farben richtig gut ist und erzeugt als Ergebnis nur eine wilde Farbsuppe. Ist also nicht wirklich produktionsreif. Die guten Bilder, die er erzeugt, zeigen zumindest schon was mit dem Grafikformat geht, wenn sich mal ein begnadeter Pixelkünstler an MINIPAINT heranwagt - Kolorieren von Lineart ist da eher Klempnerarbeit. ;)


    Ausgehend von GoDot sollte am einfachsten ein Minipaint-Saver zu realisieren sein, der ähnlich wie PGM IMPORT das 4BitGoDot als Graustufen interpretiert - bzw. das linke obere 160x192-Teilbild binärisiert als reine S/W-Hires-Bitmap wegspeichert. Dann ist es auf jeden Fall wichtig, daß Du die ersten 15 Bytes (Ladeadresse u. BASIC-Stub) und die letzten 120 Bytes (Display-Routine) binär-exakt aus den Beispielbildern übernimmst, damit es sich um gültige Bilder im MG-Format handelt (also, mit der Stringenz, wie es im letzten Absatz von Anhang D in der Anleitung drinsteht).


    Viele Grüße,


    Michael

    Mike: Hm, ich hab einen PGM-Saver geschrieben, aber leider machen deine kleinen Einleseprogramme Ärger (String too long). Ich hab die beiden Test-Bildchen mal hier angehängt. Vielleicht hast du eine Idee, was daran falsch sein könnte?


    Arndt

    Mir sind *.pgm und *.ppm-Format so geläufig, daß der Header in drei Zeilen geschrieben wird, die jeweils mit einem Linefeed (ASCII-Code 10) abgeschlossen werden. Nach einem scharfen Blick hier: http://netpbm.sourceforge.net/doc/ppm.html scheint das wohl etwas weiter gefaßt zu sein. Die vier Elemente des Headers: Bildtyp, Breite, Höhe und max. Wert können wohl mit einem beliebigen Whitespace (Leerzeichen, TAB, CR, LF) abgeschlossen werden. Nun ja.


    IrfanView akzeptiert deine Bilder, schreibt aber m.W. *.ppm/*.pgm immer so weg:

    Code
    1. P5(oder P6)<LF>
    2. Breite<Leerzeichen>Höhe<LF>
    3. max. Wert<LF>

    und danach die Bilddaten. Und so kannte ich den Header bislang auch nur. Meinen Programmen gehen also die 3 Linefeeds im Header ab und darum verenden sie mit dem ?STRING TOO LONG Fehler.


    ...


    Lädst Du die zwei Bilder in IrfanView ein, und speicherst sie wieder ab, akzeptieren meine Import-Tools die Dateien. Ergebnis siehe im Anhang.

    Eine Anmerkung noch zu "minip1.pgm.prg": es werden dort nur 4 Graustufen angeboten (sind vlt. auch nur so im Original enthalten), was das in PGM IMPORT bereits enthaltene Dithering grundsätzlich erst mal aushebelt.


    Leider passen die verwendeten Graustufenwerte 0, 80, 160 und 240 aber dann doch nicht exakt zu den 4 (Haupt-)Grauwerten, wodurch PGM IMPORT (effektiv ungewollt) dann doch ein zweites Mal dithert - besonders bei weißen Flächen fällt das auf. Die Graustufenwerte 0, 85, 170 und 255 sind da besser geeignet.

    Zitat von Mike

    es werden dort nur 4 Graustufen angeboten

    Das hatte ich GoDot so machen lassen. Wie viele Graustufen sind denn ideal? Du sprichst öfter von 13? Auch die Werte kannte ich natürlich nicht, was aber umgehend angepasst werden kann. Wie hättest du's denn gern? Lässt sich alles schnell einbauen. Die Vorbereitung mit GoDot sind jedenfalls nur ein paar Klicks mit ApplyDither.


    Arndt

    Zitat von GoDot

    Wie hättest du's denn gern?

    Schwarz sollte als 0 und Weiß als 255 repräsentiert werden. Darüberhinaus stellt PGM IMPORT erst mal keinen weiteren Anspruch an die Graustufendaten. Das ist aber der übliche Bereich, wenn Graustufenbilder vom PC herkommen.


    Das Programm quantisiert den Wertebereich 0..255 dann in 13 Helligkeitsabstufungen, 0 bis 12, und ordnet diesen entsprechende (ordered-)Dither-Patterns zu. Bei der Quantisierung wird gerundet, d.h. die beiden Endwerte 0 und 12 nehmen nur die Hälfte des Helligkeitsbereichs in der Gesamtskala ein, verglichen mit den anderen Werten 1..11. Die 13 Patterns sind sorgfältig entworfen, so daß bei einem nicht zu starken Helligkeitsgradienten nach Möglichkeit vermieden wird, daß zwei 'echte' Farben mit den Helligkeiten I und I+2 nebeneinander liegen.


    Die Patterns sind, so wie sie auf dem Bildschirm dargestellt werden, in den Zeilen 35 bis 38 abgelegt. Jedes Pattern ist 2 (Multicolor-)Pixel breit und 4 hoch.


    Unter Umständen sieht man im Ergebnis ein relativ starkes Banding. Dann sind aber auch Bildquelle oder Motiv selbst relativ wenig strukturiert (etwa, Himmel mit wenigen Wolken) und dann reißt es auch ein anderes Darstellungsverfahren bei der Auflösung kaum - es sind eben nur 4 Grundintensitäten bei 80x192 Pixeln in der Ausgabe verfügbar.


    Kannst trotzdem mal probieren, was herauskommt, wenn Du ein 'schwieriges' Motiv in GoDot vor-ditherst, am besten eben in 13 Graustufen. Diese sollten dann auf die Werte: 0, 21, 42, 64, 85, 106, 128, 149, 170, 191, 212, 234 und 255 umgesetzt werden, damit Du die Mitten der 13 Intensitätsbereiche genau triffst.

    Zitat von Mike

    probieren, was herauskommt, wenn Du ein 'schwieriges' Motiv in GoDot vor-ditherst

    Mist. ;-)


    Im Gegenteil, es erweist sich, dass alles Vorgerasterte weichgezeichnet werden muss, damit es auf dem VC20 ansehnlich bleibt. Daher empfehle ich jetzt folgende Vorgehensweise beim Erstellen von PGMs für MiniPaint: Bild laden (egal, was für eins), weichzeichnen (mit Blur High), dann auf 80x192 Pixel stauchen (mit ClipWorks: Clipbreite: 10, Cliphöhe: 24, danach Shrink) und das Ganze wegschreiben mit svr.PGM (der noch ein UI kriegt und dann veröffentlicht wird). Sowas kommt dabei heraus:



    Links das Original, rechts das, was Mikes "PGM Import" daraus macht. Und ein paar Bilder vom Amiga:



    Dies ist im Original farbig und stark gerastert, das würde ohne Weichzeichner totalen Müll ergeben. Und noch so eins, auch vom Amiga:



    Der Saver wird wahlweise für 80 Pixel Vorlagenbreite (wie alle diese hier), für 160 Pixel (für Hires-Ergebnisse) und für 1:1-Bilder ausgelegt werden. Die Dateien werden dabei ziemlich lang...


    Mit nem eigenen Saver für farbige MiniPaint-Bilder habe ich mich noch nicht beschäftigt. Ach ja, das Vorweg-Reduzieren auf 13 Farben ist unnötig. Macht nur zusätzliche Arbeit ohne viel Gewinn.


    Arndt

    Das Amiga-"Flagface" ist ein sehr dankbares Motiv. Ich hab' spaßeshalber mal die Farbauswahl in meinem ppm2mg-Konverter (s. Post #41) festgeklemmt auf: Hintergrund = Blau, Vordergrund = Weiß, Rahmen = Schwarz und Hilfsfarbe = Rot - strikt in Multicolor.


    Mit dem dann angewandten Floyd-Steinberg-Dithering kommt dann das raus:


    flagface.png


    ... :D

    Der Saver für Portable GrayMaps (PGM) ist jetzt fertig und bereits auf den GoDot-Disketten drauf (auf der dritten). Er speichert sowohl 80x192 (61 Blocks) als auch 160x192 (122 Blocks) und schließlich auch noch 320x200 (235 ? Blocks). Dabei muss man die Daten vorher entsprechend aufbereitet haben. Das GUI sieht so aus (Beschreibung ab morgen auf godot64.de):


    spgm.gif (alternativ hier: "MiniPaint80" oder "MiniPaint160")


    Mike: Du musst in "PGM Import" die Zeile 19 anpassen, da ich im Header "080" schreibe (wegen des zweiten Formats, wo dann an derselben Stelle "160" steht), etwa als ..."AND LI$<>"080 192" THEN"... Außerdem muss in der Dateieröffnung ",p,r" stehen, nicht seriell (",s,r"). Das letztere gilt auch für das "PGM Import Mono".


    Macht schöne Bilder! :-)


    Arndt

    Zitat von GoDot

    Außerdem muss in der Dateieröffnung ",p,r" stehen, nicht seriell (",s,r"). Das [...] gilt auch für das "PGM Import Mono".

    Arndt, die Eröffnung als sequentielle Datei hab' ich mit voller Absicht gemacht. *.ppm und *.pgm sind nun mal keine *.prg-Files im Sinne des KERNALs mit 2-Byte-Ladeadresse vorne dran, sondern exakt das: SEQuentielle Dateien. Und wenn CBM DOS diese Unterscheidung anbietet, nutze ich sie in diesem Sinne, und das solltest Du auch.


    Und "080" anstelle von "80" wegzuschreiben, war jetzt sicher auch nicht nötig. Immerhin sind diese Import-Tools in BASIC geschrieben (mit MINIGRAFIK-Unterstützung natürlich) und so kann jeder ggfs. den Header-Check selbst anpassen. ^^


    ...


    Ich mach' mir der Tage derweil mal Gedanken, wie eine gestraffte Version des PPM-Imports aussehen könnte. Das Programm wird dann ein 80x192 oder 160x192 Bild in 4-Bit-C64-Farben oder 24-Bit RGB hernehmen und auf 4 (vorher vom User ausgewählte) VC-20 oder C64 Farben mit dem Floyd-Steinberg-Verfahren dithern. Inklusive (weitgehend) korrekter Handhabung des Gamma-Exponenten.

    Zitat von GoDot

    Ich könnte noch Ideen gebrauchen, was man im Rahmen so eines Projektes wie GoDot noch sinnvoll alles einbauen könnte.

    Zitat von GenerationCBM

    (Bei GoDot ist das "Gefummel" mehr eine Frage des Jonglierens mit Disketten oder Disk-Images und des Ladens der Module usw., das hätte man dann nicht...)

    Besteht die Möglichkeit GoDot zu einem EasyFlash Image umzustricken? Das wäre der echt klasse und man würde sich das "Gefummel" sparen! ;)
    Die vollständige Unterstützung vom SD2IEC wäre auch super. Im Handbuch habe ich unter "Filerequester" und "mod..ChangeDir" zumindest nichts dazu gelesen.
    Beides zusammen wäre natürlich die ideale Kombination.

    Zitat von Mike

    die Eröffnung als sequentielle Datei hab' ich mit voller Absicht gemacht

    Soso... ;-) Na gut, du hast völlig recht. GoDot ist es eh egal, was für einen Dateityp die Files haben. Darum speichert svr.PGM jetzt die beiden MiniPaint-Größen als SEQ-Dateien ab (die Full-Screen-Größe weiterhin als PRG).

    Zitat von Mike

    Und "080" anstelle von "80" wegzuschreiben, war jetzt sicher auch nicht nötig

    Na ja, es hat mir allerhand Gerödel erspart (schau auf Github nach), aber auch das hab ich jetzt umgebaut. Nichts ist unmöglich... ;-)

    Zitat von Cyberdyne

    Besteht die Möglichkeit GoDot zu einem EasyFlash Image umzustricken?

    Keine Ahnung. Ich hab kein Easyflash (sonst gäb's da schon eine Unterstützung). GoDot ist massiv nachladend, wenn das kein Problem ist, dann wär auch eine Easyflash-Portierung kein Problem.


    Also:ldr.MiniPaint und svr.PGM stehen zum Download bereit.


    Arndt

    Zitat von GoDot

    Ich hab kein Easyflash (sonst gäb's da schon eine Unterstützung).

    Also wenn das alles ist?! Mein EF3 ist im Einsatz aber ich hab noch ein EF1 rumliegen, dass ich dir leihen könnte. Nachdem Donald seinen Laden dicht gemacht hat, weiß ich spontan nicht, wo ich ein EF3 kaufen sollte. Ich muss wohl mal suchen. Bei Interesse, kannst du mir gerne eine PN schicken.


    Zitat von GoDot

    GoDot ist massiv nachladend, wenn das kein Problem ist, dann wär auch eine Easyflash-Portierung kein Problem.

    Da solltest du genügend Infos finden:
    http://skoe.de/easyflash/doku.php?id=develdocs


    Und da war noch eine zweite Frage:

    Zitat von Cyberdyne

    Die vollständige Unterstützung vom SD2IEC wäre auch super. Im Handbuch habe ich unter "Filerequester" und "mod..ChangeDir" zumindest nichts dazu gelesen.

    OK, ohne Fragezeichen ist es nicht wirklich eine Frage aber dann halt jetzt: Wird das SD2IEC von GoDot erkannt und der "native" Modus (also kein Diskimage aktiv) unterstützt? SD2IEC ist so verbreitet und so praktisch, dass eine Unterstützung echt sinnvoll wäre.

    Zitat von Cyberdyne

    Da solltest du genügend Infos finden:
    skoe.de/easyflash/doku.php?id=develdocs

    Hab ich mir gleich mal runtergeladen. Wieder neuer Lesestoff! :-) Ich sag Bescheid, wenn ich da Land für GoDot sehe.

    Zitat von Cyberdyne

    Wird das SD2IEC von GoDot erkannt und der "native" Modus (also kein Diskimage aktiv) unterstützt?

    Hier gilt das Gleiche wie beim Easyflash: Hab ich nicht. Hardware-Support hat es in Godot immer nur für Geräte gegeben, die ich selber vorliegen hatte (eine Ausnahme: der ComputerEyes-Bilddigitizer). Gibt's dafür auch so einen schönen Link wie fürs Easyflash?


    Arndt

    Zitat von GoDot

    Hab ich mir gleich mal runtergeladen. Wieder neuer Lesestoff! Ich sag Bescheid, wenn ich da Land für GoDot sehe.

    Super! Dann drück ich mir mal die Daumen! ;)


    Zitat von GoDot

    Hier gilt das Gleiche wie beim Easyflash: Hab ich nicht.

    Hier gilt das Gleiche wie beim Easyflash: Kann ich dir jederzeit leihen.


    Zitat von GoDot

    Gibt's dafür auch so einen schönen Link wie fürs Easyflash?

    So schön wie fürs EasyFlash?! Entscheide selber:
    https://sd2iec.de/gitweb/?p=sd…t;a=blob;f=README;hb=HEAD
    https://www.c64-wiki.com/wiki/sd2iec_(firmware)


    Wie kann man nur ohne EF3+SD2IEC leben? ;)

    Zitat von Cyberdyne

    Also wenn das alles ist?! Mein EF3 ist im Einsatz aber ich hab noch ein EF1 rumliegen, dass ich dir leihen könnte. Nachdem Donald seinen Laden dicht gemacht hat, weiß ich spontan nicht, wo ich ein EF3 kaufen sollte. Ich muss wohl mal suchen. Bei Interesse, kannst du mir gerne eine PN schicken.

    Derzeit ist ein EF3 gerade im Marktplatz. Ansonsten verkauft Jim B. Doch in seinen Shop welche.

    sd2iec: Kann mal einer ausprobieren, ob GoDot schon ganz ohne irgendwelche Klimmzüge darauf läuft? CMD-Geräte werden ja auch klaglos akzeptiert. Wahrscheinlich gibt's da gar keinen Handlungsbedarf!


    Arndt