Hallo Besucher, der Thread wurde 18k mal aufgerufen und enthält 107 Antworten

letzter Beitrag von oobdoo am

Rotierender 3D Würfel - Neujahrsgeschenk für Oobdoo und alle Interessierten

  • Huhu!


    Da der geliebte C64 leider ganz ganz schlecht in BASIC Linien zeichnet, habe ich einen Ausflug zum Amstrad CPC 464 unternommen. Der bessere Editor und das um Lichtjahre bessere Basic trieben mir Tränen des Zorns in die Augen wegen der Peek/Poke/And/Or-gien, die man am C64 in Basic betreiben muss, um Ähnliches in zwanzigfacher Verlangsamung zu erreichen. Das C64 Basic ist nicht schlecht, es kann alles, man kommt an alles dran, nur eben nicht schnell. Das C64 Basic ist ein Textmodus Basic, kein Grafikmodus Basic. Dafür atomisiert man dann in 6502 Assembler noch die kleinsten Arbeitsschritte, aber das Ergebnis ist dann wenigstens rasend schnell.


    Mich interessiert aktuell das Thema Vektorgrafik. Ich habe nur die Vorbildung aus dem "C64 Wunderland der Grafik" Buch, wo u.a. Transformation und Kavaliersperspektive ohne Flucht erklärt werden. Die Transformation hätte es am CPC evtl. gar nicht gebraucht, der kennt nämlich einen Origin Befehl zum Setzen des Koordinaten-Mittelpunkts.


    Mein Projekt bestand darin, einen sich drehenden Würfel optisch plausibel abzubilden und zwar echtzeitberechnet. Die Berechnungsergebnisse kann ich in eine Tabelle laufen lassen und das irgendwann am C64 in Assembler abspulen ohne Vertex-Berechnungen im Code.


    Wie beim Sortierversuch vor einigen Wochen wollte ich mir bewusst etwas eigenes ausdenken. Daher habe ich z.B. nicht mit einer Z-Koordinate gearbeitet und der Koordinatenmittelpunkt liegt in der Mitte der Bodenplatte des Würfels, statt in der 3D-Mitte des Würfels, weswegen ich mit dem bestehenden Konzept Schwierigkeiten hätte, den Würfel animiert zu bewegen (wobei das trotzdem ginge). Rotation über mehrere Achsen kann ich aber mit dem Ansatz vergessen.


    Der billige Trick in meinem Fall:
    Ich lasse 2 gegenüberliegende Tangenten eines Kreises die Länge 2r nicht überschreiten und bilde Startpunkt und Enpunkt in 10-Grad-Schritten in einer Schleife um den Kreis herum ab. Die Punkte bilden die 4 Bodenpunkte des Würfels. Ich muss dann nur noch in y-Richtung stur 2r hochgehen und kann die oberen 4 Punkte bilden. diese müssen dann nur noch durch Linien korrekt verbunden und gezeichnet werden. Zeichnen, Rechnen, Löschen, Zeichnen, Rechnen, Löschen.. etc.


    Ich war nicht in der Lage, die hinteren Linien anders einzufärben und im Hintergrund gezeichnet zu lassen so dass die von den Vordergrund-Linien überdeckt werden. Dazu hätte ich evtl. Double Buffering gebraucht und ich wollte ja was Eigenes ausdenken. Wenn man also genau hinschaut, überzeichnen sich die Linien nicht immer korrekt. Die optische Hervorhebung hilft aber trotzdem, die Rotation nachzuvollziehen ohne dass man nur noch wirre Linien sieht.


    Probieren in WinCPC: Mit F11 Autotype öffnen und Listing aus der Zwischenablage einkopieren. Mit Ctrl Shift F4 das Einkopieren beschleunigen, dann mit CTRL Shift F4 den Turbo aus. Dann Return eingeben um sicher zu sein dass der Cursor "frei" ist und mit Run (Return) starten.


    Alternativ die DSK einladen und mit run"cpccube.bas" starten.


    Vielleicht hat noch jemand weiteres Zeug in 3D mit Basic gemacht? Mike? Tribar auch mal auf andere 8 Bitter portiert? Oder die Hutfigur? Oder in der Abbildung von Objekten v ersucht ("Elite Raumschiff"?).


    Viele Grüße und guten Start ins neue Jahr,


    Byteb.

  • Huhu!


    Da der geliebte C64 leider ganz ganz schlecht in BASIC Linien zeichnet, habe ich einen Ausflug zum Amstrad CPC 464 unternommen.

    :knuddl:


    Vektorgrafik hat mich auch immer schon interessiert.

  • Hi Byti!


    Tja, unser BASIC V2 ist nun mal so wie es ist, daran können wir nix ändern, aber mit eigenen ASS-Routinen zur Unterstützung ist dann doch irgendwie alles möglich.


    Die Rahmenfarbe bspw. lässt sich schnell und bequem mit einem einzigen Poke ändern, die 8.000 Bytes einer Bitmap hingegen mit Pokes zu löschen ist unzumutbar langsam. Soll heißen der BASIC Befehl ist nicht unbedingt langsam, aber viele Methoden ihn anzuwenden - da macht der CeVi dann teils eine unglückliche Figur... :(


    Wenn man also professionelle Software entwickeln möchte, hat man alleine mit BASIC schlechte Karten. Und so muss man spezielle Methoden über Maschinensprache realisieren.


    Aber immerhin hatte jeder 64'er-User schon vor über 30 Jahren die Möglichkeit schnell und einfach mit dem Hobby der Programmierung warm zu werden. Bei den heutigen Systemen werden die meisten Besitzer zum "stupiden Anwender" degradiert.


    Finde es wirklich klasse, dass du dich in ein spannendes, aber nicht einfaches Fachgebiet einarbeitest! Wünsche dir dafür weiterhin viel Spaß und Erfolg! ;)

  • Huhu!


    Da der geliebte C64 leider ganz ganz schlecht in BASIC Linien zeichnet,

    Na, das stimmt so nicht ganz (nur für BASIC V2 gilt das)! Wenn du Basicerweiterungen bemühst, klappt das auch mit deinem Projekt besser, z.B. die High-Speed-Grafik oder auch TSB (wobei dort die gleiche High-Speed-Grafik aktiviert werden sollte...) ;)


    Arndt

  • Komischerweise haben wir uns wohl bisher nie in den gleichen Themen verirrt, was!? Viele Grüße nach Minden! ;)

    Holla! Danke für die Grüße, geb ich gerne zurück. Ich bin meist in Themen unterwegs, die was mit Grafik und Programmierung (egal ob BASIC oder ASM) zu tun haben, geb meinen Senf allerdings eher selten dazu. Ab diesem Jahr werde ich wieder aktiver... ;-)


    Arndt

  • @ data land


    Lieber Jörn, danke für das Feedback. Ich sitze jetzt wieder weiter fleißig am Assembler und denke an deine Ratschläge.


    @melli17


    Das Geschabbel kommt vom Wert rh=r-0.25 was ein Pi Mal Daumen Behelf ist um im Bereich 90 Grad /270 Grad die Tangenten nicht ausbrechen zu lassen.


    Für den Bereich um 0 Grad / 180 Grad rechnet xhelp=r/m0 sauber die Tangentenlänge aus.


    Ich suche nach einer Formel für den 90/270 Bereich, wahrscheinlich reicht xhelp2=m0/r als Umkehrung von xhelp.


    Ich poste wieder wenn ich das Geschabbel weg kriegen sollte.

  • Oh, den kannte ich noch gar nicht. Habe wie er auch WinCPC genommen. Damit hätte es dann auch gehen müssen.
    JavaCPC kommt allerdings auch damit klar. Scheint wohl ein WinCPC Bug zu sein.

  • Hach, rotierende Würfel in 3D, da juckts mir direkt in den Fingern. ^^


    <fx='grabbel in HD, such, find, umsetz' von Archimedes auf GBASIC auf dem C64'></fx>


    Ta-daa!


    Die dazu nötige BASIC-Erweiterung muß erst mit LOAD"BOOT",8 und RUN geladen und gestartet werden, dann die Demo mit LOAD"VECTORCUBE",8 und RUN ebenfalls laden und starten.


    Zur Erklärung:


    - Zeilen 10..13 lesen die Geometriedaten aus den DATAs in den Zeilen 60..65 (Ecken- und Kantenliste)
    - Zeilen 15..17 legen die Eulerwinkel und deren Änderungsgeschwindigkeit fest
    - Zeile 19 schaltet die Grafik ein
    - Zeilen 21..27: Eulerwinkel ändern, zugehörige Cosinus- und Sinuswerte ausrechnen
    - Zeilen 29..37: Transformationsmatrix aufbauen
    - Zeilen 39..43: alle Ecken transformieren
    - Zeilen 45..48: alle Ecken auf Bildschirmkoordinaten umrechnen und dabei projizieren
    - Zeile 50: Bildschirm löschen...
    - Zeilen 52..54: ... und ganz fix die neue Bewegungsphase zeichnen (der DRAW-Befehl kann ~20000 Punkte/Sekunde!)
    - Zeile 56: falls keine Taste gedrückt, nächste Phase berechnen und zeichnen
    - Zeile 58: ... sonst Neustart.


    Mit einer SCPU sieht das ganze sogar richtig flott aus! :)

  • Moment ... ich pack dann mal eben den ZX Clone mit 80MHz Soft-Z80 aus ;)

    Geschenkt. Die SCPU (oder evtl. auch Chameleon) war nur ein Vorschlag, wie man den Rest des Programms - ohne die jetzt brauchbar schnellen Grafikbefehle - jetzt auch annehmbar schnell hinbekommt.


    Auf einem Original-C64 kommt jetzt ca. alle 2 Sekunden ein neues Bild, davon "verbringt" der Rechner mit dem Neuzeichnen in den Zeilen 50..54 allenfalls eine halbe Sekunde. Das heißt umgekehrt, daß die Kiste jetzt 75% der Zeit mit Geometrieberechnungen beschäftigt ist, und ich hab' diese Routinen jetzt schon so optimiert, daß sie mit möglichst wenig Rechenoperationen auskommen - 9 Multiplikationen und 6 Additionen für die Rotation jeder Ecke; 4 Additionen, 2 Multiplikationen und 2 Divisionen für jede Projektion.


    Es gibt auch eine Version dieses Programms in Maschinensprache auf dem VC-20 (mit 160x192 Auflösung), die schafft ca. 4..5 Bildern pro Sekunde (Edit: zudem ist dem Würfel da noch ein Ikosaeder einbeschrieben, bedeutet insgesamt 20 Ecken und 42 Kanten!) - hier ist die Geometrieengine aber noch etwas überdimensioniert mit 16 Bit Genauigkeit, da geht also noch was.


    Und das Original (Edit: nur der Würfel) läuft in interpretiertem BASIC auf dem Acorn Archimedes mit 8 MHz mit 25 Bildern/Sekunde (Edit: bei einer Auflösung von 640x480).

  • Kann mich Bytebreaker nur anschließen - sehr schön!


    Ich weiß ja nicht, wie es mit dem Copyright von Programmen in DDR-Literatur aussieht... hab' hier nämlich das Buch "Spiel + Spass mit dem Computer", da ist auch ein 3D-Programm drin. Zwar ohne Animation, aber mehrere Formen und Perspektiven zur Auswahl.

  • Hier ist die TSB-Version von Mikes Archimedes-Programm. Die 60er-Zeilen löschen den Würfel wieder, sonst ist bald alles schwarz. Unter VICE im Warp-Mode sieht's halbwegs nett aus, ansonsten dauern die Berechnungen - ähm - ziemlich lange...




    Ach so, wenn ihr das hier kopiert und in VICE einfügt, müsst ihr die PIs in den Zeilen 15, 16, 17 und 21, 22, 23 anpassen (insgesamt 9 Mal, in VICE "Shift-Entf").


    Arndt

  • Hat TSB denn kein dediziertes Kommando, um den Hires-Bildschirm zu löschen?


    Ich hab' die Befehle schon extra so angeordnet, daß der gezeichnete Würfel während der Berechnungen stehen bleibt. Wenn dann alle Bildschirmkoordinaten zur Hand sind, verbringt das Programm nur die notwendige Zeit damit, den Bildschirm zu löschen und dann die Kanten des Würfels zu zeichnen. Noch besser bekommt man es nur mit dem Einsatz einer zweiten Bildschirmseite hin (was aber durch GBASIC nicht unterstützt wird).


    So wie jetzt in deiner Version wird der Würfel direkt danach wieder gelöscht und ist für die meiste Zeit unsichtbar. :(


    Edit: also, ausgehend von meiner Version sollte es ausreichen, Zeile 19 zu streichen, den Befehl "HIRES 0,1" in Zeile 50 zu setzen (er ist dann immer noch rechtzeitig vor dem ersten Linienbefehl) und die Zeile 53 in der Syntax von TSB wie in deiner Version zu schreiben. Die Tastaturabfrage springt dann zu Zeile 21, und das Linienlöschen deiner Version kann dann ersatzlos entfallen.

  • Ich hab' das jetzt auch nochmal anhand der TSB-Version, die ich von godot.de herunterladen konnte, nachvollzogen.


    Leider 'sprenkelt' das Löschen der Grafik während eines bereits aktivierten Grafikmodus mit HIRES wohl für Bruchteile einer Sekunde mal ein anderes Char-ROM ein, das sieht natürlich nicht so schön aus. Weiterhin rundet TSB auch die Koordinaten beim Linienziehen nicht korrekt. Schräge Linien werden um eine halbe Linienbreite zur Seite 'ausgebeult' und jeweils ein Ende der Linie endet in einem einzelnen Punkt. Das kriegen selbst BASIC 3.5 und BASIC 7.0 besser hin. Schade. :(