Posts by bbock

    Ich habe ein bisschen mit Inkscape rumgespielt, um eigene SVGs zu erzeugen. Das hat auch eigentlich gut geklappt, aber die angehängte Datei fliegt in TinySVG völlig auseinander. Vielleicht magst du dir das ja mal anschauen...

    Die SVG-Daten besteht im wesentlichen aus einem einzigen path-Tag mit einem kilometerlangen d-Attribut. Dass die Flächenfüllungen nicht dargestellt werden, ist klar. Warum einige Linien versetzt sind, kann ich auf die Schnelle nicht sagen - mal sehen, ob ich dahinterkomme...

    Wie bekomme ich bei TinySVG denn einen gefüllten Polygonzug konvertiert? Oder geht das nicht? Ich habe die SVG-Datei im Anhang umgewandelt, aber da ist keine Füllung vorhanden (siehe ebenfalls angehängte VE2-Ergebnisdatei).

    TinySVG erzeugt nur Liniengrafiken, keine Flächenfüllungen. Polygon-Fill wird hier nicht verwendet.

    Quote from EgonOlsen71

    Noch ein Hinweis: Ich stand vor der GUI von TinySVG wie der Ochs vorm Berg, weil ich nicht kapiert habe, wie die eigentliche Umwandlung stattfindet. Dass das magisch von selber passiert, war mir nicht klar. Evtl. kannst du das irgendwie deutlicher machen oder einen Menüpunkt "Erneut umwandeln" oder so einfügen, damit man was zu klicken hat!?

    Die Umwandlung passiert sofort beim Öffnen der SVG-Datei, sofern mind. eine Ausgabedatei konfiguriert ist. Das Programm hat noch eine Nuller-Version, ist also noch nicht final. Eine Anleitung fehlt bisher noch, aber es gibt eine (unvollständige) Anleitung unter https://joyce.de > Update(s) > 10. April 2021 Vektorgrafik - SVG-Grafik für die Schneider Joyce

    EgonOlsen71: Danke für den Hinweis; ich habe die Spezifikation korrigiert.


    Das ist eine schöne Arbeit; die Grafik sieht genau so aus, wie sie aussehen soll. Polygon-Fill ist in der Spec, weil die Grafikbibliothek, für die ich TinySVG ursprünglich entwickelt habe, eine Funktion dafür enthält. Diese ist aber fehlerhaft implementiert, so dass Polygon-Fill auch auf der Schneider Joyce nicht korrekt funktioniert. Mein Anzeigeprogramm für die Joyce zeichnet deswegen zwar das Polygon, füllt es aber nicht aus. Da ist deine Lösung schon ein Fortschritt. :)

    Ob Vektorgrafiken auf dem C64 sinnvoll sind oder nicht, sei mal dahingestellt. Meine Motivation TinySVG und die Vektoranzeigeprogramme für verschiedene Rechner zu entwickeln war, die riesige Welt der SVG-Grafiken im Internet für unsere Oldtimer zu erschließen. Mir macht es immer noch Spaß zu sehen, wie eine Grafik, die für ganz andere Zwecke und für viel leistungsfähigere Systeme erstellt wurde, auf dem C64 (oder einem anderen 8-Bitter) erscheint.


    Erweiterungen der Grafikformate und der Anzeigeprogramme sind auch nicht ausgeschlossen. Vielleicht gibt es ja irgendwann Programme, die die Vektorgrafiken nicht nur anzeigen, zoomen und drehen, sondern vielleicht auch bearbeiten können. Das kommt immer darauf an, wieviel Zeit und Mühe man da hineinstecken möchte.

    Nein, ganz anders. Die SVG-Dateien sind ja im Wesentlichen XML-Dateien, und ich lese das DOM (Document Object Model) ein und traversiere den Baum, wobei ich alle Elemente in Grafikobjekte umwandle, die ich gebrauchen kann. Das sind Tags wie <path>, <line>, <circle>, usw., und diverse Attribute (id, Koordinaten, transform, ...). Da wird einiges geparst, akkumuliert, skaliert und umgewandelt.


    Komplexere Formen wie quadratische oder kubische Bézier-Kurven, elliptische Bögen, aber auch Ellipsen oder Kreise werden je nach Zielformat in Linienzüge umgerechnet. Je mehr hierbei in TinySVG passiert, desto weniger muss das Vektor-Anzeigeprogramm auf dem 8-Bitter können.


    Es wird wohl langsam Zeit, dass ich mal eine ausführliche Dokumentation schreibe. Bis dahin mag dieser Artikel auf joyce.de weiterhelfen: https://joyce.de > Update(s) > 10. April 2021 Vektorgrafik - SVG-Grafik für die Schneider Joyce

    uint ist ein 2-Byte little endian integer. Die Header-Felder für bytesXCoord / bytesYCoord sind nur ein Byte lang (Datentyp byte). In der Praxis werden hier nur die Werte 1 oder 2 vorkommen - zumindest für die 8-Bitter. Wenn beim C64 für die Y-Koordinate nur ein statt zwei Bytes belegt werden müssen, dann bringt das ca. 25% Ersparnis in der Dateigröße und damit auch in der Darstellungsgeschwindigkeit. Ich denke, die kleine Komplexitätserhöhung bei der Leseroutine lässt sich dafür verschmerzen.

    Gerade habe ich mühsam einen halbwegs lauffähigen Prototyp für einen VEC-Viewer auf dem C128-VDC (640x200) erstellt, schon gibt es ein neues Format... :SX/;)

    Das "alte" VEC-Format gibt es ja immer noch, und ich habe die VEC-Ausgabe von TinySVG sogar noch optimiert (jetzt wird vorzugsweise MULTI-LINE statt LINE verwendet, was Platz und Zeit spart). Und VE2 als Nachfolger von VEC ist nicht sooo viel komplizierter...

    TinySVG v0.25 mit VE2-Unterstützung ist jetzt verfügbar: https://joyceforum.de/viewtopic.php?p=453#p453


    Quickstart-Konfiguration für den C64:

    • Optionen > Konfiguration > Zentrieren, Größe anpassen, Bézier-Kurven-Annäherung, Bogen-Annäherung und Linienreduktion aktivieren
    • Voreinstellungen > C64
    • Datei > öffnen > SVG-Datei auswählen. Die erzeugte VE2-Datei befindet sich im selben Verzeichnis wie die SVG-Datei.

    Natürlich habe ich auch das Programm DRAWVECTOR erweitert (Version 2.0), damit es das neue Format darstellen kann. Im angehängten D64-Image sind neben dem Programm auch einige VE2-Dateien enthalten. Besonders test.ve2 ist interessant, weil es alle Grafikelemente (Dot, Line, Box, Square, Ellipse, Circle, Multi-Dot, Multi-Line und Polygon-Fill) enthält. Polygon-Fill zeichnet z.Z. zwar das Polygon, füllt es aber nicht aus. Das ist momentan die einzige Einschränkung.


    Künftig soll es noch möglich sein die Grafik zu skalieren und zu verschieben. Auch eine Drehung der Grafik wäre möglich.


    TinySVG kann bereits VE2-Dateien erzeugen, aber der Code ist noch nicht finalisiert. Wenn es soweit ist, werde ich hier darüber informieren.

    Files

    • DRAWVECTOR.d64

      (174.85 kB, downloaded 12 times, last: )

    Ich habe das Vektorformat VEC erweitert, damit man mehr Möglichkeiten offen hält, wie z.B. Scaling. Das neue Format heißt VE2 und hat die Dateiendung .ve2. Es sollte zu VEC abwärtskompatibel sein (wenn ich nichts übersehen habe :) ). VE2 ist kompakter als VEC, indem es Koordinaten mit unterschiedlichen Längen unterstützt. Für den C64 machen 2 Byte für die X- und 1 Byte für die Y-Koordinate Sinn. Im Header sind außerdem Informationen zu den min. / max. Koordinatenwerten, zur Zielauflösung und zu den verwendeten Features zu finden.


    Header: 'V' 'E' '2'

    uint minX minimum of all X coordinates

    uint maxX maximum of all X coordinates

    uint minY minimum of all Y coordinates

    uint maxY maximum of all Y coordinates

    uint targetResolutionX target resolution X

    uint targetResolutionY target resolution Y

    byte bytesXCoord number of bytes used by an x coordinate

    byte bytesYCoord number of bytes used by a y coordinate

    byte profileFlags bit vector where each 1 bit means the corresponding graphic object can be present in the file

    00000000 00000001: Dot

    00000000 00000010: Line

    00000000 00000100: Box

    00000000 00001000: Square

    00000000 00010000: Ellipse

    00000000 00100000: Circle

    00000000 01000000: Multi-Dot

    00000000 10000000: Multi-Line

    00000001 00000000: Polygon-Fill


    Example with bytesXCoord=2, bytesYCoord=2:

    Byte | 0 | 1 2 | 3 4 | 5 6 | 7 8 |

    -----------------------------------------------------------------------

    Dot | 0 | x | y | | |

    Line | 1 | x1 | y1 | x2 | y2 |

    Box | 2 | xleft | ytop | xright | ybottom |

    Square | 3 | xleft | ytop | width | |

    Ellipse | 4 | xcenter | ycenter | xradius | yradius |

    Circle | 5 | xcenter | ycenter | radius | |

    Multi-Dot | 10 |#dots| x1 | y1 | x2 | ... |

    Multi-Line | 11 |#dots| x1 | y1 | x2 | ... |

    Polygon-Fill | 12 |#dots| x1 | y1 | x2 | ... |

    End | 99 | | | | |


    Space consumption:

    ------------------

    Graphic object (Dot, Line, ...): 1 byte

    Dot x: bytesXCoord bytes

    y: bytesYCoord bytes

    Line x1: bytesXCoord bytes

    y1: bytesYCoord bytes

    x2: bytesXCoord bytes

    y2: bytesYCoord bytes

    Box xleft: bytesXCoord bytes

    ytop: bytesYCoord bytes

    xright: bytesXCoord bytes

    ybottom: bytesYCoord bytes

    Square xleft: bytesXCoord bytes

    ytop: bytesYCoord bytes

    width: max(bytesXCoord, bytesYCoord) bytes

    Ellipse xcenter: bytesXCoord bytes

    ycenter: bytesYCoord bytes

    xradius: bytesXCoord bytes

    yradius: bytesYCoord bytes

    Circle xcenter: bytesXCoord bytes

    ycenter: bytesYCoord bytes

    radius: max(bytesXCoord, bytesYCoord) bytes

    Multi-Dot: #dots: 1 byte

    xn: bytesXCoord bytes

    yn: bytesYCoord bytes

    Multi-Line: #dots: 1 byte

    xn: bytesXCoord bytes

    yn: bytesYCoord bytes

    Polygon-Fill: #dots: 1 byte

    xn: bytesXCoord bytes

    yn: bytesYCoord bytes

    Ok, jetzt verstehe ich; danke für die anschauliche Erklärung. Deine Vermutung war natürlich richtig: TinySVG kümmert sich nicht um verdeckte Linien. Das Ergebnis wäre also wie in "A" gewesen.

    Ich habe jetzt auch eine Vektorgrafik beizusteuern. Es war gar nicht so einfach, aus der Flächen-bezogenen Grafik manuell nur die reinen Linien (und ohne doppelte an aneinander-stoßenden Flächen) zu extrahieren. Als VEC und SVG enthalten.

    Wozu musstest du denn die Linien manuell extrahieren? Das macht doch TinySVG für dich. Wie sieht die Original-SVG-Datei vor deiner manuellen Extraktion aus?


    Da ja schon der Java-Konverter die Grafik auf die passende Zielauflösung umrechnet: Was passiert eigentlich, wenn man eine "falsche" VEC-Datei öffnet? Und kann man vorab an irgendwas erkennen, für welche Zielauflösung die Grafik generiert wurde?

    Das VEC-Format war ursprünglich nur für die Schneider Joyce gedacht, und da ist die Auflösung fix 720x256 (mit Pixeln, die doppelt so hoch wie breit sind). Dass das Format jetzt auch für den C64 genutzt wird, ist neu; man kann die Zielauflösung nicht direkt erkennen. Das sollte vielleicht in das noch zu finalisierende erweiterte VEC-Format einfließen. Wenn das Anzeigeprogramm skalieren kann, dann benötigt man diese Information nicht unbedingt.

    Wenn man eine "falsche" VEC-Datei öffnet, dann können verschiedene Dinge passieren, je nachdem, was das Anzeigeprogramm macht. Im schlimmsten Fall könnte es abstürzen; vielleicht zeigt es aber auch nur einen Ausschnitt der Grafik oder eine zu kleine Grafik an.

    Schöne Analyse; sowas habe ich auch in anderem Zusammenhang schon gemacht, z.B. einen Vergleich der Performance verschiedener Retro-Computer mit dem Algorithmus "Sieb des Erathostenes" (Primzahlberechnung).


    Bzgl. TSB von GoDot: Das Zeichnen selbst sollte in TSB ähnlich schnell laufen wie mit der TGI library des cc65. Der Flaschenhals ist das Lesen von der Floppy.


    GoDot: Statt einzelne Zeichen mit GET zu lesen, wäre es effizienter, gleich einen ganzen Block (z.B. 512 Bytes) von der Diskette zu lesen. Dann kann man Byte für Byte aus dem Puffer lesen, und wenn man das letzte Zeichen gelesen hat, dann liest man den nächsten Block ein - bis EOF. So habe ich das in meinem C-Programm DRAWVECTOR gemacht. Gibt es eine Load-Routine in TSB, die einen Block an eine bestimmte Speicheradresse (oder in eine Puffervariable) lesen kann? Dann könntest du dein Programm deutlich schneller machen.


    Übrigens: meine ersten Versuche die Vektorgrafiken auf dem C64 anzuzeigen waren mit Simons' BASIC. Da ist mir auch nur der langsame GET-Befehl eingefallen...

    Mir als Grafiker fehlt vor allem eine Bezier- oder Spline-Funktion (wie ich sie in meinem Mockup andeutete). In modernen Vektorgrafik-Programmen basiert quasi alles auf Bezierkurven – selbst ein Kreis. Auch einen Linienzug kann man durch Umwandlung eines Eckpunktes zu einem Übergangspunkt in eine Kurve verwandeln. Und natürlich besteht auch quasi jede Schrift aus entsprechenden Kurven (die keine Kreissegmente darstellen).


    Die Frage ist aber, ob ein 1MHz-Rechner dazu fähig ist, solche Kurven einigermaßen performant zu zeichnen.

    Das Ziel meines Ansatzes war, ein einfaches Vektorformat zu erzeugen, das durch 8-Bit-Computer einfach und schnell dargestellt werden kann. Bézier-Kurven und Ellipsenbögen (Arc) werden in TinySVG bereits in Linienzüge umgewandelt, eben weil das recht komplex und aufwändig ist (Catmull-Rom-Kurven übrigens nicht, weil die es nicht in die SVG-Spezifikation des W3C geschafft haben). Je nach Zielformat (das muss bei TinySVG nicht immer VEC sein) werden auch andere Grafikobjekte wie Kreise oder Ellipsen in Linienzüge umgewandelt.


    Man muss einen brauchbaren Kompromiss finden, was auf dem PC und was auf dem 8-Bitter gerechnet werden soll, denke ich. Sonst kann man gleich versuchen SVG direkt auf dem C64 zu interpretieren. Etwas Derartiges gibt es übrigens in der Atari-Ecke: https://github.com/savetz/Renderific

    Hier hat man sich zur Vereinfachung auf die SVG Tiny Spezifikation beschränkt.


    Anm.: Der Name TinySVG hat nichts mit der Spezifikation SVG Tiny zu tun; ich habe den Namen für das Programm festgelegt, bevor ich von der Existenz der SVG Tiny Spezifikation des W3C wusste.

    LINETO-Befehl (spart 2 Koordinaten)

    Den verwende ich beim Linienzug (Poly-Line) bereits. Heißt in TSB dann DRAW TO. Die LINE-Funktion sollte ruhig so bleiben (mit Start- und Zielkoordinaten). Nur dein TinyVec-Konverter könnte von Line auf Poly-Line umgestellt werden (wo das Sinn macht).


    Arndt

    Guter Punkt; werde ich umsetzen.


    Weitere Vorschläge für die erweiterte VEC-Spezifikation?


    Bernd

    Wegen Polygon-Fill noch mal eine Frage an bbock : Schließt der die Fläche umgebende Linienzug automatisch oder muss man den Startpunkt am Ende noch einmal angeben?


    Arndt


    (Ach und noch eine Frage: Wird das Format weiterentwickelt?)

    Da die VEC-Spezifikaton von einer in Turbo Pascal und Z80-Assembler geschriebenen Joyce-Grafikbibliothek abstammt, ist die Antwort aus den Routinen der GRAPHLIB zu entnehmen: der Startpunkt muss am Ende noch einmal angegeben werden.


    Hier ist die Beschreibung der GRAPHLIB; die relevante Passage habe ich in rot hervorgehoben:


    Um eine Linie, einen Kreis oder andere Objekte auf den Bildschirm zu zaubern, müssen zunächst alle Punkte berechnet und einer nach dem anderen gesetzt werden.
    Dafür sind die Prozeduren LINE() bis CIRCLE() zuständig.
    LINE() zieht eine Linie zwischen den Bildschirmpunkten, deren Koordinaten im Aufruf übergeben wurden.
    Die einfachste Art dies zu tun, wäre, mit Hilfe der Geradengleichung f(x) = Steigung * x + y-Achsenabschnitt für die xKoordinaten die Werte für f(x) zu berechnen, sie zu Runden, da der Bildschirm ja nur diskrete Schritte erlaubt, und sie anschließend mit PLOT() zu setzen.
    Da die Berechnung über REAL-Werte erfolgen müßte, wäre dies aber mit Sicherheit auch die langsamste Art.
    LINE() rechnet nur mit INTEGER-Variablen.
    Ausgangspunkt ist auch hier wieder die Geradengleichung — diesmal aber ohne Achsenabschnitt.
    Vielleicht erinnern Sie sich noch mehr oder weniger dunkel an den Mathematikunterricht?!
    Die Steigung einer Geraden läßt sich aus den Differenzen der Koordinaten zweier Punkte — in unserem Fall von Start und Endpunkt — berechnen.
    Umgeformt lautet die Gleichung dann: x * DY = y * DX.
    Mit DX und DY werden bei jedem Schritt die Abweichungen der gesetzten Punkte von der vorgegebenen Gerade bestimmt und zur Auswahl der nächsten Schrittrichtung benutzt.
    Mehr Details will ich Ihnen und mir ersparen.
    BOX() bringt ein Rechteck auf den Bildschirm.
    Übergeben werden die Ecken links oben und rechts unten und — wie auch bei den anderen Prozeduren — der Modus (setzen, löschen oder invertieren).
    Um die Box nicht unnötig zu bremsen, wird nicht LINE() zum ziehen der Linien benutzt, sondern die Sonderfälle für horizontale und vertikale Linien.


    POINT_SWAP() sorgt dafür, daß die Startkoordinate immer kleiner als die Endkoordinate ist und nicht über den Rand gemalt wird.
    SQUARE() ist ein Spezialfall von BOX() und zeichnet — wie zu erwarten — ein Quadrat.
    Als Parameter werden die linke obere Ecke und die Breite in Pixeln übergeben.
    Wie wird nun das Quadrat zum Quadrat?
    Hierfür ist die Konstante ASPECT_RATIO zuständig;
    sie gibt das Verhältnis von Pixelhöhe zu Pixelbreite an.
    Ihr Wert kann durch Ausmessen von »Boxen« am Bildschirm ermittelt werden — probieren geht auch hier über studieren.
    Auch ELLIPSE() und CIRCLE() erhalten durch das Einbeziehen der ASPECT_RATIO erst das gewünschte Aussehen.
    Ebenso wie die Prozedur LINE() vermeidet auch ELLIPSE() weitgehend REALzahlen.
    Auch hier wird nur die Abweichung betrachtet, die durch jeden Schritt entsteht.
    Außerdem macht sich die Symmetrie der Figur nutzbringend bemerkbar:
    Wir müssen nur ein Achtel aller Punkte berechnen, alle ändern erhalten wir durch Spiegelungen entsprechende Kombination von Addition und Subtraktion der errechneten Werte von den Koordinaten des Mittelpunktes.
    Radius_x gibt die Anzahl der Pixel der x-Halbachse an, die y-Halbachse wird so umgerechnet, daß das Größenverhältnis auf dem Bild dem gewünschten Verhältnis von Radius_y zu Radius_x entspricht.
    CIRCLE() wird als Ellipse mit gleich langen Halbachsen berechnet;
    übergeben wird dementsprechend außer den Mittelpunktskoordinaten nur noch der Radius.


    Soweit die »Grundfunktionen«.
    Aber es gibt noch mehr;
    Die Prozedur PLOT_MARKER() ist vor allem zur Darstellung von Meßwerten u.a. gedacht.
    Sie setzt auf den Punkt x,y einen »Marker« aus den in MARKER_TYPE deklarierten Elementen.
    PLOT_MARKER(10,20,Kreis,0) zieht also einen Kreis um den Punkt 10,20.
    Wenn Sie MARKER_HEIGHT mit im Aufruf übergeben, können Sie auch verschiedene Größen erhalten, was mir persönlich allerdings nicht besonders sinnvoll erschien, da die Marker dann zum Teil doch etwas unförmig werden.
    Als nächstes folgen vier POLY_...-Prozeduren.
    Wie der Name vermuten läßt, wird hier etwas mehrfach ausgeführt.
    Die erforderlichen Koordinaten werden als zweidimensionales Array übergeben;
    POINT_ARRAY(.i,0.) enthält die x-, POINT_ARRAY(.i,1.) die y-Werte.
    POINT_ARRAY ist auf 250 dimensioniert, was für die meisten Anwendungen völlig ausreichen dürfte.
    Die Zahl der wirklich benutzten Arrayelemente wird als Parameter mit übergeben.
    POLY_PLOT() setzt lediglich Punkte auf die Koordinatenpaare des Arrays;
    POLY_MARKER() die in MARKER_TYPE definierten Marker.
    POLY_LINE() verbindet die Punkte in der Reihenfolge, in der sie im Array enthalten sind, mit Linien.
    Alle Prozeduren können vielseitig eingesetzt werden.
    Etwa um Funktionen oder Meßwerte darzustellen, wie im Beispiel GRAPHIC.PRO demonstriert, oder um Polygone zu zeichnen.

    Bei POLY_LINE() muß dann das erste Koordinatenpaar noch einmal als letztes im POINT_ARRAY enthalten sein, damit eine geschlossene Figur entsteht.
    Ebenso verhält es sich bei der vierten POLY_..-Prozedur POLY_FILL().

    Sie füllt ein Polygon, dessen Eckpunkte als POINT_ARRAY übergeben wurden, im entsprechenden Modus, d.h. sie füllt den Inhalt »weiß«.
    löscht oder invertiert alle Punkte.


    Allerdings wird es durch die Art der Berechnung notwendig, im Anschluß an das Füllen mit PLOY_LINE() noch die 'Begrenzung' zu zeichnen.
    Ihre Anwendung im Demo-Programm DREID (entnommen aus PASCAL INTERNATIONAL 2(2), Januar 1987) zeigt am besten den Effekt, den man so erzielen kann:
    Hidden-LineDarstellungen ohne komplizierte Umrechnungen und große Arrays.
    Soweit zum Inhalt von GRAPHLIB.INC.


    Der erste Entwurf des VEC-Formats war wohl ein wenig naiv und nur auf die Erfordernisse der GRAPHLIB der Schneider Joyce angelehnt. Aber es macht wohl Sinn, das Format zu erweitern um mehr Möglichkeiten zu eröffnen. Mir fallen auf Anhieb folgende Erweiterungen ein:

    • Minima und Maxima der Koordinaten im Header (für einfachere Skalierung)
    • Länge der Koordinateneinträge für X- und Y-Koordinate getrennt zur Speicherplatzoptimierung (C64: X = 2 Byte, Y = 1 Byte)
    • LINETO-Befehl (spart 2 Koordinaten)
    • Profile für unterschiedliche Zielsysteme; so wird im einfachsten Fall nur Plot und Line unterstützt, je nach verfügbarer Grafikbibliothek dann auch Kreise, Ellipsen, usw.

    Witzig: mein erster Ansatz Grafik auf dem CP/M-Rechner Schneider Joyce (= Amstrad PCW) zu erzeugen, war auch mit HP-GL: https://joyceforum.de/viewtopic.php?f=5&t=53


    Hier ist es ein Programm in Turbo Pascal mit Assembler-Routinen. Die Plot-Funktion und den Bresenham-Line-Algorithmus habe ich von Hand in Z80 Assembler entwickelt bzw. optimiert.


    Die 2-pass-Methode bei der Skalierung kommt mir irgendwie bekannt vor... :)

    Nein, leider nicht. Es gibt bisher auf der ganzen Welt noch keine einzige VEC-Datei, die die Poly-Funktionen nutzt! :D

    TinySVG braucht sie nicht, und andere Programme, die Dateien im VEC-Format erzeugen, gibt es (noch) nicht. Bzgl. des Fill muss ich mir mal die entsprechende Grafik-Routine anschauen. Es ist jedenfalls nicht wie bei Simons' BASIC, wo zuerst das umrahmende Polygon gezeichnet wird und dann die Fill-Routine einen Startpunkt im Inneren des Polygons haben will.

    Oh, TSB ist eine fehlerbereinigte Version von Simons' Basic, Informationen dazu gibt es im C64-Wiki und hier im Forum auch. Der Viewer ist halt ein Basic-Programm, um die TinyVEC-Dateien "abzuspielen". ;-) Ich dachte mir, kann ja nicht schwer sein...

    Das ist ja interessant: ich habe bereits einiges mit Simons' BASIC gemacht und ich habe auch das Steckmodul. Dass Simons' BASIC einige Schwächen (und Fehler) hat, wusste ich bereits. Ich werde mir TSB einmal genauer ansehen. Vielen Dank für die Links!

    Da hab ich gleich eine Frage. Die Befehle "Multi-Dot", "Multi-Line" und "Polygon-Fill" hab ich in meinem Viewer nicht implementiert. Erstens, weil sie in keinem der Beispielbilder vorkommen, und zweitens, weil ich nicht genau weiß, was sie bewirken. Ich gehe bis jetzt davon aus, dass "Multi-Dot" am besten mit "Punktwolke" bestimmt werden kann, und "Multi-Line" mit "Linienzug". Stimmt das? Und "Polygon-Fill"? Geschlossener Linienzug, der am Ende gefüllt wird?

    Das VEC-Format habe ich ursprünglich für die Schneider Joyce (auch Amstrad PCW genannt) entworfen. Dort gibt es ein Grafikpaket, das genau diese Funktionen unterstützt. Für den C64 werden sie - jedenfalls in Verbindung mit TinySVG - nicht gebraucht. Deine Vermutungen bzgl. der Funktionalität sind richtig; offenbar sind sie selbsterklärend. :)