Hallo Besucher, der Thread wurde 14k mal aufgerufen und enthält 81 Antworten

letzter Beitrag von bbock am

Vektorgrafik für den C64

    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

    Zitat von bbock

    Hmm - das Interesse scheint etwas abgeflaut zu sein...

    Die meisten Nichtprogrammierer werden halt nicht viel mit den Details anfangen können. ;)


    Dann stellt sich die Frage des praktischen Nutzens. Vektorgrafiken kenne ich dafür, dass man sie beliebig groß ohne Kantenbildung ausdrucken kann. Sowas mache ich mit dem C64 nicht.
    Ich denke, hier geht es vordergründig darum, zu zeigen, dass man es kann. Witzig ist es schon, dann solche Formate auch auf dem C64 darstellen zu können.


    Wie gesagt, eine großen praktischen Nutzen sehe ich hier nicht. Aber da sind wir bem C64 eh wieder bei der Sinnhaftikeit angekommen: Weil wir alten :pumpkin: immer noch / wieder Spaß dran haben.:thumbsup:

    Zitat von Tobias

    Dann stellt sich die Frage des praktischen Nutzens. Vektorgrafiken kenne ich dafür, dass man sie beliebig groß ohne Kantenbildung ausdrucken kann. Sowas mache ich mit dem C64 nicht.

    Du sagst es ja später selbst, dass du "Sinn/Nutzen" in Bezug auf uns Retro-Verrückte meinst, nicht im globalen Maßstab. Aber man kann natürlich fragen, welchen Nutzen so ein Format für uns hätte. Meines Erachtens sind wir mit den aktuellen Viewern (hoffentlich) noch ganz am Anfang. Durch die festgelegte Auflösung in der ersten Format-Definition ist aus meiner Sicht der einzige Vorteil gegenüber Bitmap, dass man der Grafik beim Aufbau zugucken kann – vielleicht gibt es je nach Komplexität auch einen Speicherplatzvorteil (ab wann der sich umkehrt, weiß ich aber nicht, weil ich mir die Dateigrößen nicht angeguckt habe).


    Vorteile bei Vektorgrafik gegenüber Bitmap sehe ich eigentlich bei der Auflösungs-Unabhängigkeit bzw. Skalierbarkeit, die beim Zoomen, Drehen und Drucken (und Austausch mit Systemen, die höhere Auflösungen haben) zum Tragen käme. Davon haben wir aber bei den C64-Viewern noch nichts. Der allergrößte Vektorgrafik-Vorteil würde sich erst entfalten, wenn wir statt eines Viewers einen Editor bekämen, mit dem man die Grafiken bearbeiten kann.


    Ein weiterer Nutzen könnte sich entfalten, wenn es Programme gäbe, die das Format "platzieren" könnten, z.B. eine Textverarbeitung, in die man eine Chart-Grafik einbetten möchte. Dafür wäre es sinnvoll, sich etwas vom alten EPS abzuschauen, nämlich die optionale Einbettung eines niedrig aufgelösten Vorschaubildes (beim C64 z.B. 160 x 100 px oder noch weniger). Dann könnte ein Textprogramm die Vorschau (schnell und ohne Renderer) platzieren und ein Druckprogramm könnte die Vorschau durch die echten Daten ersetzen und rendern, damit es auf einem Drucker (oder PS-Export) gut aussieht.


    Ach ja, by the way, ein Text-Befehl wäre im Format hilfreich, um z.B. in einem Organigramm oder Chart Beschriftungen durchführen zu können. Die kann jede Plattform interpretieren/darstellen, wie sie will – beim C64 würde das wohl immer (mangels Alternative) mit der Systemschrift dargestellt werden.


    (jaja, reicht man den C64-Verrückten den kleinen Finger, wollen sie gleich die ganze Hand) ;)

    Tobias: Für mich persönlich hat es wenig praktischen Nutzen, in verschiedenen Threads (vgl. vertikales Arcade-Game auf C16) zu lesen, dass Du manche Aktivitäten hier für nicht sinnvoll oder interessant hälst. Hier ist offensichtlich eine Gruppe von Leuten, die sich gern mit einem Thema beschäftigen. Oft kommt es gar nicht dazu, dass sich mehrere Interessierte finden für ein Thema. Hier ist das geglückt - und warum soll man nun überall sich einmischen und sagen: Das ist nicht interessant/relevant/sinnvoll? Das kann ja jeder für sich entscheiden, und natürlich kann man etwas langweilig finden, aber man kann ja einfach die Diskussion den Leuten überlassen, die sich dafür interessieren. Die Diskussionen hier im Forum sind teilweise auf Jahrzehnte ausgelegt, weil retro in einem gewissen Sinne zeitlos ist. Da kann ein Thread auch mal eine Dürreperiode haben über einen Zeitraum.

    Zitat von emulaThor

    Tobias: Für mich persönlich hat es wenig praktischen Nutzen, in verschiedenen Threads (vgl. vertikales Arcade-Game auf C16) zu lesen, dass Du manche Aktivitäten hier für nicht sinnvoll oder interessant hälst. Hier ist offensichtlich eine Gruppe von Leuten, die sich gern mit einem Thema beschäftigen. Oft kommt es gar nicht dazu, dass sich mehrere Interessierte finden für ein Thema. Hier ist das geglückt - und warum soll man nun überall sich einmischen und sagen: Das ist nicht interessant/relevant/sinnvoll? Das kann ja jeder für sich entscheiden, und natürlich kann man etwas langweilig finden, aber man kann ja einfach die Diskussion den Leuten überlassen, die sich dafür interessieren. Die Diskussionen hier im Forum sind teilweise auf Jahrzehnte ausgelegt, weil retro in einem gewissen Sinne zeitlos ist. Da kann ein Thread auch mal eine Dürreperiode haben über einen Zeitraum.

    Es ist niemals eine Absicht von mir, destruktive Kritik zu geben. Niemals.
    Im C16 Arcade-Thread habe ich lediglich gesagt, dass sowas für MICH (leider) nicht sinnvoll ist, da ich nur auf Original-Hardware inkl. CRT unterwegs bin und man da eben nicht einfach den Monitor um 90° drehen kann.

    Jede Aktivität für unser altes Schätzchen finde ich generell klasse. Interessant finde ich fast alle, sonst würde ich die Threads nicht lesen. Wenn ich erst bei Seite 59 hinzustoße, gebe ich zu, nicht immer jedes einzelne Wort der vorherherigen 58 Seiten durchgelesen zu haben.:saint: Somit kann es schonmal zu falschen Schlüssen oder unnötigen Fragen kommen. Ich bitte um Nachsicht.


    Hier im speziellen Fall wurde ja vom Urheber direkt gefragt, warum es u.U. etwas still geworden ist. Hierzu habe ich MEINE Gedanken geteilt. Nicht mehr.
    Retrofan hat offensichtlich ähnliche Gedanken, die er im Gegensatz zu mir (ohne Programmierkenntnisse) weiterführt.

    In diesem Sinne: weitermachen.:thumbsup:

    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.

    Da wäre es eigentlich nur konsequent, als nächsten Schritt auch eine Vektor-Bildschirmsteuerung dazu zu bauen, das steigert die Ausgabegeschwindigkeit immens und schaut auch noch steampunkmäßig cool aus.


    Vor Jahren waren ja mal so Spielereien wie analoge Uhren auf ebenso analogen Oszi-Schirmen "in", die Preise für die kleinen alten Hamegs und Voltcrafts etc. gingen zeitweise durch die Decke...


    Aber aktuell kräht da kein Hahn mehr danach und dank Userport wäre so ein 2Kanal analog plus eine Schaltfunktion für den Z-Kanal doch schnell gebaut...

    Röhre mit langer Nachleuchtdauer und schon gehts mit 2-5 FPS flimmerfrei in den 3D-Bereich ;-)


    Zwei Latches z.B. 74xx373 für die x/y Koordinaten, das vorderste Bit als Vorzeichen interpretiert (da der Strahl ohne Ablenkspannung ja in der Mitte des Schirms steht), nach dem Latch ein schlichter R2R-DA-Wandler und eine OPV-Stufe, die auch für die Polaritätsumschaltung dann zuständig ist, sowie ein Ausgang für die Dunkeltastung, mehr sollte es da nicht brauchen... Wäre dann 256x256 Auflösung und liesse sich einfach auf 512x512 erweitern, indem man die Polarität über 2 weitere Extrabits erzeugt...


    Müsste sich von den nutzbaren Bits am Userport gerade noch so ausgehen...

    Zitat von Retrofan

    Durch die festgelegte Auflösung in der ersten Format-Definition ist aus meiner Sicht der einzige Vorteil gegenüber Bitmap, dass man der Grafik beim Aufbau zugucken kann...

    Daher wäre ich auch für ein "virtuelles Format", dass die 2 Bytes (X und Y) auch ausnutzt und dann auf den Bildschirm scaliert werden kann. Hat man einen Plotter angeschlossen scaliert man den entsprechend anders (beim 1520 ist Y nahezu "unendlich"). Zudem könnte man auch einfach nur Ausschnitte anzeigen lassen und so in ein Bild rein- und rauszoomen (oder hin und her drehen). Ja, ja, das sind riesige Rechenzeiten und vom "zoom" effekt sieht man erstmal nichts, aber wenn man die erzeugten Einzelbilder jeweis auf Platte bannt bzw. in eine REU, dann könnte man nachher die Animation in einem Rutsch abspielen.

    Zitat von bbock

    Hmm - das Interesse scheint etwas abgeflaut zu sein...

    Das kann man so nicht sagen...;)


    Ich war nur mit dem Format wie es war für meine Zwecke völlig zufrieden und von daher haben mich die Erweiterungen nicht wirklich interessiert. Ich habe lieber Zeit darein investiert, meine Variante zu beschleunigen. Es war ja nicht fair :D, dass alle anderen Varianten auf Line- und Plot-Befehle in Maschinensprache zurückgreifen konnten und die BASIC V2-Version nicht. Von daher habe ich mir mal die Zeit genommen, ein paar compilerfreundliche Grafikroutinen zu bauen (also ohne BASIC-Syntax-Erweiterung und ohne SYS XXX,Y,Z-Hacks). Damit ergeben sich für den Lehrer Lämpel nun diese Zeiten im Vergleich:


    C von bblock (alte Version): 1m 40s

    TSB von GoDot: 15m 35s

    BASIC V2 compiliert (MOSpeed/ML-Grafik): 2m 54s

    BASIC V2 (ML-Grafik): 17m 14s

    BASIC V2 compiliert (MOSpeed/BASIC-Grafik): 4m 46s

    BASIC V2 (BASIC-Grafik): 24m 45s



    Damit bin ich erstmal ganz zufrieden.

    Zitat von Retrofan

    Könnte man das Ganze nicht auch über den VDC in doppelter X-Auflösung rendern lassen, wenn man die X-Koordinaten einfach verdoppelt?

    So, hat etwas gedauert, liegt aber auch schon eine Woche bei mir rum...

    Ich habe mich für UltraHires entschieden, das gab es mal zum abtippen, sollte damit mehr oder weniger "gemeinfrei" sein.


    1. C128 anschmeißen

    2. Ultra Hires booten

    3. vec viewer starten

    Zitat von GoDot

    Ist das nicht der Vorläufer von Basic8?

    Ja! [ http://blog.c128.net/?s=ultra+hires ]

    Das wurde damals in der RUN veröffentlicht.


    Zitat von oobdoo

    Was ist denn UltraHires? Ich kann dazu nix finden.

    Muss man auch nicht suchen, diese BASIC-Erweiterung für den VDC ist ja auf der Disk enthalten.

    Zitat von bbock

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

    00000000 00000001: Dot

    Tückisch...ich habe mich an der Dokumentation orientiert und nicht am Beispiel darunter. Der Text sagt "byte" für das Flag, das Beispiel sagt "uint". Mit byte sah der Ergenis aber sehr ungewöhnlich aus...;)


    Ansonsten habe ich die Änderungen mal umgesetzt, die meisten neuen Angaben ignoriere ich aber. Beim gefüllten Polygon verwende ich einen Floodfill, was zwei Nachteile hat: Ich muss einen Punkt innerhalb des Linienzugs ermitteln. Das mache ich nur heuristisch und das kann fehlschlagen. Außerdem funktioniert ein Floodfill natürlich nicht korrekt, wenn die Figur über andere gezeichnet wird, weil dann Teile nicht gefüllt werden. Naja, besser als nichts.


    Sieht dann so aus:


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

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


    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!?

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

    Zitat von EgonOlsen71

    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.

    Zitat von 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

    Zitat von EgonOlsen71

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

    Weil hier gerade ein Amiga 500 auf dem Tisch steht, habe ich mal eine Amiga-Basic-Version darauf gebaut. So merkwürdig hatte ich Amiga-Basic gar nicht in Erinnerung, aber ist halt auch 30 Jahre her...


    Jedenfalls ist es langsam. Der Lehrer Lämpel braucht auf einem A500 ohne alles 13m 15s und ist damit nur 4 Minuten schneller als der C64, wenn man dort das Zeichnen in Maschinensprache macht. Kompilieren war auf dem Amiga leider nicht angezeigt. Cursor kann es nicht (da fehlen Befehle wie Circle), ACE crasht beim Versuch und der AC-Basic Compiler kann manches zeichnen, aber aus irgendwelchen Gründen nicht den Lehrer Lämpel....geht also auch nicht 100%ig. Wo es ging, war das Kompilat etwa 2mal schneller...nicht die Welt und damit immer noch wesentlich langsamer als kompiliertes C64-Basic...eigentlich traurig.


    Naja, bootfähiges ADF hängt an. Auf der Diskette sind ein paar Testdateien mit dabei.