GoDot Programierkurs / Handbuch / Quellcode-PDFs

  • Hi, Arndt!

    GoDot schrieb:

    Ich könnte noch Ideen gebrauchen, was man im Rahmen so eines Projektes wie GoDot noch sinnvoll alles einbauen könnte.
    Wenn ich den Import für ZX Spectrum-Bilder sehe, denke ich da an den Import eines Bildformats vom viel näher verwandten ( ;) ) VC-20: das MG-Format, wie es von MINIPAINT bzw. der zugrunde liegenden BASIC-Erweiterung MINIGRAFIK verwendet wird.

    Die dort verwendete 160x192 Auflösung läßt sich recht problemlos zu C64 Multicolor Bitmap bringen, wenn Du die Pixel horizontal verdoppelst, und unten 8 Pixelzeilen in Rahmenfarbe anfügst. In der Batch-Suite ist bereits ein MG-nach-Koala-Export drin, der das Farbmapping definiert: die Farbcodes für Orange und Hellorange werden auf Braun und Orange gemappt, Hellviolett/Hellcyan/Hellgelb auf Dunkel-/Mittel-/Hellgrau.

    Ich habe das Dateiformat im Anhang D der Anleitung zu MINIPAINT (s. Anhang) genau definiert. Im *.d64 der Batch-Suite befinden sich auch einige Beispielbilder zum Ausprobieren.

    Gruß,

    Michael
    Dateien
    • manual.zip

      (241,24 kB, 4 mal heruntergeladen, zuletzt: )
  • Morgen! ^^

    GoDot schrieb:

    So weit bin ich dann schon mal mit Minipaint. Die Farben fehlen noch [...]
    Es gibt drei globale Farben: Hintergrund-, Rahmen-, und Hilfsfarbe werden über die Register $900E und $900F im VIC-I definiert. Deren Aufteilung ist wie folgt:

    Quellcode

    1. $900E: 7 6 5 4 | 3 2 1 0
    2. ^ ^
    3. | |
    4. | sound
    5. | volume (0..15)
    6. |
    7. auxiliary
    8. colour (0..15)
    9. $900F: 7 6 5 4 | 3 | 2 1 0
    10. ^ ^
    11. | |
    12. | exterior border
    13. | colour (0..7)
    14. |
    15. background
    16. colour (0..15)
    Alles anzeigen
    Die Lautstärke hat natürlich mit Grafik nichts zu tun und wird daher in den Datein standardmäßig als 0 abgespeichert.

    Die untere 3 Bits in jedem Farbnibble bestimmen die Vordergrundfarbe für die zugeordnete Kachel. Bei gelöschtem Bit 3 ist die Kachel im Hiresmodus. Sobald bei einem der 240 Farbnibbles bzw. der zugehörigen 8x16 Pixel-Kacheln das Bit 3 gesetzt ist, ist diese Kachel im Multicolor-Modus. Die Zuordnung der Bitpaare zu den Farbquellen ist dann wie folgt:

    Quellcode

    1. %00: Hintergrund
    2. %01: Rahmenfarbe(!)
    3. %10: Vordergrund
    4. %11: Hilfsfarbe
    Anm.: Das ist unterschiedlich zum C64, in dessen Multicolor-Textmodus steht ja %11 für Vordergrund.

    Zu Bit 3 von $900F: das ist üblicherweise gesetzt und steht dann für *nicht*-invertierte Darstellung. Ist es gelöscht, werden alle Hires-Kacheln (und nur die!) invers dargestellt. Die meisten MG-Programme werden wohl $900F wie gewohnt mit Bit 3=1 setzen - MINIPAINT überprüft das aber und erzwingt ggfs. Bit 3 = 1, weil es sonst Probleme mit der UI gäbe... durch internes 'händisches' Umkehren aller Hireskacheln bleibt die Darstellung aber unverändert.

    Die Zuordnung von Farbnummern zu den physischen Farben ist beim VIC-I wie folgt:

    Quellcode

    1. 0 Black 8 Orange
    2. 1 White 9 Light Orange
    3. 2 Red 10 Light Red
    4. 3 Cyan 11 Light Cyan
    5. 4 Purple 12 Light Purple
    6. 5 Green 13 Light Green
    7. 6 Blue 14 Light Blue
    8. 7 Yellow 15 Light Yellow
    Nach Helligkeit sortiert:

    Quellcode

    1. 1 White
    2. 15 Light Yellow
    3. 11 Light Cyan
    4. 13 Light Green
    5. 7 Yellow
    6. 9 Light Orange
    7. 12 Light Purple
    8. 3 Cyan
    9. 10 Light Red
    10. 5 Green
    11. 14 Light Blue
    12. 8 Orange
    13. 4 Purple
    14. 2 Red
    15. 6 Blue
    16. 0 Black
    Alles anzeigen

    GoDot schrieb:

    Soll die Auflösung so sein (160x192)? Oder doppelt breit?
    Doppelt breit. In PAL haben die Pixel beim VIC-I-Chip tatsächlich das Seiten-Höhen-Verhältnis von ca. 1,67:1 (oder 5:3 in ganzen Zahlen) - da ist 2:1 immer noch besser als 1:1.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Mike ()

  • GoDot schrieb:

    Im Moment verteile ich sie waagerecht.
    Genauso ist's richtig.

    Wenn die 120 Bytes in der Datei auf die 240 Bytes im Farb-RAM (bei $9400..$94EF) expandiert werden, steht das niederwertige Nibble (also, Bits 0..3) dann links, also an der kleineren Adresse.

    Die Bitmap ist übrigens deswegen in Spalten angeordnet, weil's geht *) - und dann im übrigen die Adreßfunktion stark vereinfacht wird: an Stelle von AD=4352+320*INT(Y/16)+16*INT(X/8)+(YAND15) tut's dann AD=4352+192*INT(X/8)+Y ... die (),Y-Adressierungsart im 6502 freut sich. :D


    *) dazu werden die Zeichen im "Textbildschirm" bei $1000, der jetzt einfach als Adreßgenerator dient, spaltenweise angeordnet. Der "Zeichensatz" startet ebenfalls bei $1000, aber das erste Zeichen hat den Code 16 und adressiert somit ab $1100. Da der Textbildschirm passenderweise nur 240 (doppelthohe) Zeichen beansprucht, endet er bei $10EF - damit steht für die Bitmap ab da der Speicher bis $1FFF voll zur Verfügung. MG realisiert damit die maximal mögliche Auflösung, insofern man die unteren 1K ($0000..$03FF, auch zugreifbar für den VIC-I) in Ruhe läßt und auch sonst auf CPU-Assistenz für den VIC-I verzichtet.
  • Neuer Zwischenstand:



    Das ist bereits Multicolor (gemischt mit Hires, faszinierend!) Aber es gibt noch Bilder, die Artefakte (hier und da kurze waagerechte Striche) und falsche Farbzuordnungen rauswerfen (z.B. das Natalia-Bild auf der Disk). Außerdem muss ich mir über Zeile 25 noch Gedanken machen (die Minipaint-Bilder haben ja nur 24 Zeilen).

    Bin aber eigentlich ganz zufrieden, hehe... ;)

    Arndt
    GoDot C64 Image Processing
    www.godot64.de
    GoDot on Github
  • GoDot schrieb:

    Aber es gibt noch Bilder, die Artefakte (hier und da kurze waagerechte Striche) [...]
    Hmm. :gruebel Da kann ich mir im Moment keinen Reim drauf machen. Ich geh' mal davon aus, daß Du zumindest schon mit den Originalen im Emulator vergleichst, wenn dir etwas ungewöhnlich vorkommt.

    GoDot schrieb:

    und falsche Farbzuordnungen rauswerfen
    Das kann schon etwas schwierig werden, ja.

    Für die meisten Farben auf dem VC gibt's zwar ein Äquivalent auf dem C64, einige fehlen aber (Hellgelb, Hellcyan und Hellviolett) und bei Orange/Hellorange würde Orange problemlos zugeordnet werden können, aber dann ist für Hellorange nirgendwo mehr Platz. Aufgrund der relativen Helligkeit habe ich seinerzeit Orange(VC) auf Braun(C64) gemappt und Hellorange(VC) auf Orange(C64). Allerdings ist das Hellorange(VC) *wesentlich* heller als Orange(C64) und das stört bei einigen Bildern durchaus.

    Geht man nur nach Helligkeit und erst in zweiter Linie nach passender Farbe, könntest Du folgendes Mapping probieren:

    Quellcode

    1. VC-20 C64
    2. 1 White 1 White
    3. 15 Light Yellow 7 Yellow
    4. 11 Light Cyan 13 Light Green
    5. 13 Light Green 3 Cyan
    6. 7 Yellow 15 Light Grey
    7. 9 Light Orange 12 Grey
    8. 12 Light Purple 14 Light Blue
    9. 3 Cyan 5 Green
    10. 10 Light Red 10 Light Red
    11. 5 Green 8 Orange
    12. 14 Light Blue 4 Purple
    13. 8 Orange 2 Red
    14. 4 Purple 11 Dark Grey
    15. 2 Red 9 Brown
    16. 6 Blue 6 Blue
    17. 0 Black 0 Black
    Alles anzeigen
    ... wo in der C64-Helligkeitsgruppe nach links geschaut die gleiche Farbe beim VC auftaucht, hab' ich sie auch übernommen. Ansonsten ist die Zuordnung bestenfalls noch nach 'kalten' vs. 'warmen' Farben (wenn überhaupt) gelungen. Die Bilder werden dann *sehr* bunt aussehen. :cursing:

    GoDot schrieb:

    Außerdem muss ich mir über Zeile 25 noch Gedanken machen (die Minipaint-Bilder haben ja nur 24 Zeilen).
    Wie ich schon schrub: füll die 25. Zeile einfach mit der Rahmenfarbe auf. Viele Motive beim VC gehen in der Nähe des Randes in die Rahmenfarbe über, und dann fällt diese Belegung entsprechend am wenigsten auf.

    GoDot schrieb:

    Das ist bereits Multicolor (gemischt mit Hires, faszinierend!)
    Gerade dieses Bild enthält aber tatsächlich keine Attributzellen, die als Hires definiert sind. ?(

    Davon abgesehen ist die Charakterisierung der Bilder als pur Hires oder Multicolor ja auch nur bei einem von zwei extremen Grenzfällen angemessen, wenn entweder alle Attributzellen in Hires oder alle in Multicolor sind. Dazwischen ist alles möglich und daher kann der gemischte Modus als Normalfall angesehen werden.

    Ich hab' hier noch zwei weitere Bilder zum Ausprobieren angehängt. :)
    Dateien
    • 313.prg

      (4,1 kB, 2 mal heruntergeladen, zuletzt: )
    • tron.prg

      (4,1 kB, 2 mal heruntergeladen, zuletzt: )
  • Artefakte: Da liegt irgendwo noch ein Denkfehler vor. Den finde ich schon noch. Hier im Bild "Parrot" (links das Original und rechts die Konvertierung im CRT-Mode von Vice) siehst du im Geäst ab und zu hellrote Striche, die gehören da nicht hin. Im dritten Screenshot sieht man das deutlicher (nicht CRT-Modus).



    Bei den Farben hab ich das jetzt auch so: orange gemappt auf braun, hellorange auf orange. Leider ist der "Abstand" auf dem C64 viel größer, Bilder, die auf dem VC20 von diesen Farben leben, sehen auf dem C64 nicht so toll aus ("dog" z.B.) Zusätzlich noch hellpurpur auf hellgrau.

    Unterste Zeile: Gute Idee! Ich hab jetzt die Hintergrundfarbe genommen, aber die passt nicht immer. Wird geändert!

    Hires/Multi: Ich meinte das allgemein, nicht speziell auf dieses Bild bezogen (war aber nicht eindeutig formuliert...) ;)

    Ja, ja, es wird was! :)

    Arndt

    PS: Danke für die weiteren Bilder!
    GoDot C64 Image Processing
    www.godot64.de
    GoDot on Github
  • GenerationCBM schrieb:

    Die Proportionen sind nicht so 100% d'accord, ist das systembedingt unterschiedlich?
    Das hat Mike in Post 24 erklärt (ganz unten). Der Pixelaspekt des VC20 ist nicht 2:1, sondern nur 5:3, deshalb sieht das von GoDot gestreckte Bild leider auch ein bisschen gestreckt aus. @RealWanderer: Das Dithering war im Original bereits drin. Ist also wahrscheinlich handgepixelt.

    Arndt
    GoDot C64 Image Processing
    www.godot64.de
    GoDot on Github
  • Arndt, super Sache! :respect: :drink: :applaus:

    TheRealWanderer schrieb:

    @GoDot: Aber im Original (links) sieht man kein Dithering, aber im Konvertierten Bild (rechts). Das meinte ich
    Das Original sieht auf dem VC-20 tatsächlich auch so aus:

    skeleton.png

    Bei der Wiedergabe als "Original" links in Arndts Post #33 ging wohl das Gelb im Hellorange unter. :whistling:

    ...

    Derweil hab' ich mir die Datei "l_minipnt.txt" im GoDot64-github angeschaut - die liest sich stellenweise wie eine Emulation des VIC-I. 8\| Noch eine Sache wegen des Farbmappings, die Zeilen hier:

    Quellcode

    1. dnib !by $00,$ff,$44,$cc,$55,$aa,$11,$dd
    2. !by $22,$66,$99,$bb,$bb,$ee,$88,$bb
    da werden mehrere Farben auf $BB abgebildet. Hmm...
  • Mike schrieb:

    da werden mehrere Farben auf $BB abgebildet. Hmm...
    Das sind die beiden Farben hellcyan und hellpurpur (die dritte ist eh hellgrau). Für die beiden gibt es keinen akzeptablen Stellvertreter. Das Hellgrau sieht noch am besten aus. Sieht man am Bild "trance gemini" auf der Minipaint-Diskette.

    Mike schrieb:

    Bei der Wiedergabe als "Original" links in Arndts Post #33 ging wohl das Gelb im Hellorange unter.
    Genau, das ist ein VICE-Screenshot, bei dem die CRT-Emulation ausgeschaltet war. Im Bild ist der Unterschied zwischen gelb und hellorange leider nicht deutlich.

    Mike schrieb:

    die liest sich stellenweise wie eine Emulation des VIC-I
    :]

    Arndt
    GoDot C64 Image Processing
    www.godot64.de
    GoDot on Github
  • @Mike: Hast du eigentlich einen Bildimport zu MiniPaint? Ich hab da was mit Koala-Loader gesehen, reicht das aus? Dann könntest du mit GoDot Bildmaterial für MiniPaint aufarbeiten. Bilder in GoDot laden, mit ClipWorks (Breite: 20) und Squeeze2Clip auf (für den VC20) brauchbare Maße bringen, als Koala speichern und dann in MiniPaint nachbearbeiten.

    Ansonsten könnte man auch über einen MiniPaint-Saver für GoDot nachdenken.

    Arndt
    GoDot C64 Image Processing
    www.godot64.de
    GoDot on Github