Vektorgrafik für den C64

Zitat von GoDot

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.

Zitat von GoDot

Zitat von bbock

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

Zitat von Retrofan

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.

Zitat von EgonOlsen71

Sehr cool! Ich konnte es, auch angeregt durch GoDots BASIC-Version, nicht lassen, eine Version in reinem BASIC V2 zusammenzuklöppeln...inkl. Linienziehen und Kreisemalen in glorreichem BASIC. Zumindest die mit MOSpeed compilierte Fassung läuft gar nicht mal sooo schlecht. Für den Lehrer Lämpel sind die Zeiten im Vergleich:

• C von bblock: 1m 40s
• TSB von GoDot: 15m 35s
• BASIC V2: 25m 28s
• BASIC V2 compiliert: 8m 55s

Bei den kleinen Figuren fällt die BASIC-Version natürlich im Vergleich stärker ab, weil dann der Großteil der Zeit im Linienziehen verdödelt wird, und das ist in BASIC eben nicht so wirklich rasant.

Hat jemand eine vec-Datei mit Kreisen oder Ellipsen? Ich habe den Support dafür zwar eingebaut, aber ich glaube, es gibt keinen Testfall dafür bei den Dateien auf dem Diskimage, oder?

Alles anzeigen

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