3D-Grafik in V2 BASIC

Es gibt 34 Antworten in diesem Thema, welches 8.278 mal aufgerufen wurde. Der letzte Beitrag (9. Oktober 2015 um 07:41) ist von Tale-X.

  • Hallo,

    ich habe mir zwischenzeitlich mal wieder "C64 - Wunderland der Grafik" von Heimo Ponnath vorgenommen, welches auch auf dem Synology-Laufwerkk des Forum64 liegt.
    Die Kapitel 4,6 und 7 beschäftigen sich mit 2D- und 3D-Grafik.

    Darauf aufbauend habe ich ein paar "3D Objekte" selbst gebastelt. Gerade per Kreisfunktion müssten theoretisch auch Kegel, Zylinder und Donuts abbildbar sein und auch mit versteckten Linien, um den Vordergrund nicht zu überzeichnen.
    Mit kubischen Polygonen scheint mir das Verstecken von eigentlich verdeckten Linien schwieriger zu sein.

    Mike hat mit Bitte melde dich an, um diesen Link zu sehen. eine tolle 3D-Spielerei vom VC20 auf den C64 übertragen. Hat sonst noch jemand mit 3D-Grafik unter V2 BASIC experimentiert? Hat jemand unter V2 BASIc schnellere Zeichenroutinen, egal für was?

    Ich nutze die Bibliothek von Heimo Ponnath, die elegant und schön ist, aber saulahm.

    Unter VICE hilft aber immer Alt-W ganz gut zum Bescheunigen. Und man kann trotzig sagen: 3D geht mit V2 BASIC, auch wenn man drüber einschläft. ;)

  • Anbei noch meine Quelltexte. Besser ist es aber, in Heimo Ponnaths Buch zu schauen als meinen undokumentierten Code zu lesen.
    Hier der private Link zum Download, Synology ist tot seh ich grade.

    Bitte melde dich an, um diesen Link zu sehen.

  • Och, da geht schon was. Gezeichnet wird hier ein Hut in Schräg-Perspektive:


    Warp-Mode oder Maximum Speed > No limit sind auch hier empfehlenswert. ^^

  • Ich hab sowas früher mit Simons Basic gemacht. Die Grafik war halt leidlich schnell, aber das Rechnen hat ewig gedauert...

    Ich hab hier mal paar Sources für cc65 gepostet, dann geht auch das Rechnen deutlich schneller. Also nicht _schnell_ , aber halt _schneller_ ...

    Besser Abstand von Basic nehmen...

  • Zum Experimentieren reicht BASIC allemal.

    Eine BASIC-Erweiterung bringt hier noch den Vorteil, daß man sich nicht mehr um die Implementierung der Grafikbefehle zu kümmern braucht (siehe Zeilen 10 bis 12, 16 bis 18, 27 [SYS58648 zur Rückkehr in den Textmodus] und 29) und sich stattdessen bei dieser Anwendung auf die Mathematik konzentrieren kann.

    Im übrigen hab' ich Bitte melde dich an, um diesen Link zu sehen. auch schon vor Jahren auf dem VC-20 mit MINIGRAFIK geschrieben und dann heute zunächst mal in BASIC V7 die Koordinatendarstellung/Auflösung von 160x192 auf 320x200 angepaßt ... und dann den Code rückwärts nach V2 portiert. :D

  • Danke Mike,

    Dein Code zum Zeichnen ist zudem viel schneller als die Routinen aus dem Wunderland der Grafik-Buch.
    Irgendwann mal soll sich ein Würfel in einem Intro zu Laufschrift und SID-Sound drehen. Die Mathe-Basics dafür muss man ja eh lernen und dann in Assembler umsetzen. Das Lernen der Mathematik ist in BASIC anschaulicher als mit Assembler.

    Edit: Wegen der Sin/Cos-Berechnungen und dem Punkte-Setzen merkt man es nicht so mit dem Geschwindigkeitsunterschied. Aber bei Tribar merkt man es dafür umso mehr, dass Mikes Routinen fürs Linienzeichnen schneller sind.

  • Als Nachtrag, die Herumspielerei hat bisserl gedauert. :)

    Sehr interessant und nett zum rumspielen, die reine Basic-Implementierung. Vor allem, man braucht einfach sonst nix dazu. ;) Deswegen hab ich dann auch noch so einfache "Erweiterungen" mal außen vor gelassen.

    Wenn ich mir das Listing so anschaue, ist gleich mein interner Optimierer angesprungen und ich wollte wissen, ob diese da
    wirklich was bringen ... Gleich vorab: Wegen der massiven Nutzung der trigonometrischen Funktionen (also wenn man das nicht durch vorberechnete Felder ersetzt), kann man in diesem Fall "nur" so um 5 % bei der Laufzeit rausholen.


    Das ist auch noch die Zeitmessung mit TI$ drinnen (und die Tastenabfrage am Schluss fällt durch). Ist auch angehängt.

    Praktisch sind freilich für die Grafikprogrammierung folgende einfache Optimierungen:

    Statt Zeile 17:

    Code
    3 DIMF%(8000):CLR

    Löscht den im Basic-RAM liegen Hires-Speicher BIF- äh blitzschnell, da Basic Felder initialisiert. Solle auch mit Fließkommafelder gehen, aber mit 2 Byte pro Element rechnet es sich leichter. ;)

    Die Zeile 29 ersetzt durch:

    Code
    29 AD=LI(YP/8)+(XPAND504)+(YPAND7):POKEAD,PEEK(AD)ORBI(XPAND7):RETURN

    Ersetzt die Modulo-8-Rechnung durch ein simples AND.

    Dazu kann man freilich dann noch mehr mit Variablen herausholen, wo Konstanten, die aufwändig vom Interpreter immer jedes Mal in die Fleißkommadarstellung umgerechnet werden müssen, durch Variablen ersetzt werden. Die häufigen Variablen werden damit mittels DIM
    zuerst in der Variablenliste angelegt (ohne sie gleich mit einem Wert belegen zu müssen), entsprechend der Häufung in der Nutzung.

    Zeitmessungen: (hmm als Quellcode, wegen der Formatierung)

    Code
    Variante                Dauer   Verbesserung    in %------------------------------------------------------Original                56:23Adressberechnung        56:11   00:12           <0.4Grafiklöschen+Adressb.  55:46   00:37           1Gra.löschen+Adress+Var. 53:40   02:43           <5
  • Hi, Jeek!

    Dein Beitrag ist mir erst jetzt aufgefallen (und das auch nur durch den Verweis in Tele-X's weiterer Umformung... :whistling:).

    Jetzt solltest Du die "Zeitersparnis" durch deine "Optimierungen" nur noch ins Verhältnis setzen zu der Zeit, die Du benötigt hast, um diese Änderungen ins Programm einzubringen. Und dann fällt die Bilanz durchgehend negativ aus, wenn man davon ausgeht, daß das Programm nur einmal laufen gelassen wird. :(

    Weiterhin leidet die Einsichtigkeit durch die Verwendung von Variablen anstelle von numerischen Konstanten ganz erheblich. Gerade der Ersatz von einstelligen Konstanten durch Variable lohnt sich (mit Ausnahme von - etwa - E=1 und E direkt als erste Variable definiert) fast überhaupt nicht, Null kann aber problemlos überall durch den Dezimalpunkt ersetzt werden. Ersatz von mehrstelligen und 'gängigen' Konstanten wie etwa mit V=53248 ist aber in Ordnung.

    Die "Deklaration" von häufig genutzten Variablen hingegen bringt durchaus etwas, wenn es um eine enge Schleife geht und im wesentlichen nur die Grundrechenarten im Spiel sind. Wovon man im aktuellen Beispiel aufgrund der SQR() und COS() Funktionen leider auch nicht sprechen kann. Ich hab' aber mal in einem anderen Programm (Apfelmännchen) die innere Schleife so erheblich beschleunigt:

    Code
    17 FORI=1TON:X2=X*X:Y2=Y*Y:IFX2+Y2<4THENXY=X*Y:X=X2-Y2+R:Y=XY+XY+J:NEXT


    Zusammen mit dem restlichen Programm *) brauchte das für das Ausgangsbild (die "Grundmenge") zunächst mal 195 Minuten. Als ich dann die Variablen X, Y, X2, Y2, XY, R und J (in dieser Reihenfolge) als erste Variablen deklariert hatte, fiel die Rechenzeit auf 156 Minuten! Dabei war es nicht nötig, die Laufvariable I und den Endwert N früh zu deklarieren, da FOR einen Zeiger auf seine Laufvariable ermittelt und so immer schnellen Zugriff hat, und der Endwert auch nur einmal ausgewertet wird und dann mit auf den Stapel geht. Aber als ich dann die Konstante 4 auch noch durch eine Variable ersetzt hatte, wurde das Programm schon wieder langsamer!

    Letztenendes war aber genau diese Schleife dann der Knackpunkt und genau die hatte ich dann später mal in Maschinencode übersetzt, wo dann die Arithmetikroutinen des Interpreters direkt aufgerufen wurden. In der Folge wurde dann diese Schleife um den Faktor 3 beschleunigt, zusammen mit dem restlichen Programm lag dann beim Ausgangsbild die Zeit bei ca. 90 Minuten. Ein anderer Koordinatensatz (mit 254 als maximale Rechentiefe) wurde z.B. von 2360 auf 840 Minuten beschleunigt. :)

    Um noch mal zum Hut-3D-Plotter zurückgekommen: mein Originalprogramm war ja auch schon nicht ganz ohne Optimierungen. Zum Beispiel muß man den Bitwert zum Einmaskieren ja nicht unbedingt mit angezogener Handbremse (sprich: mit 2^(7-(XPAND7))) berechnen. Auch die Adreßberechnung arbeitet ja bereits mit einer Tabelle, anstatt ständig den vollen Ausdruck 'AD=8192+320*INT( YP/8 )+8*INT( XP/8 )+(YPAND7)' auszuwerten (mit 'XPAND504' geb' ich dir aber Recht... hab' ich auch schon mal verwendet... :whistling:)

    Ansonsten gilt nach wie vor: Experimentieren macht Spaß! ^^

    Gruß,

    Michael

    *) das war auf dem VC-20, und da hatte ich den Grafik-Teil bereits mit einer eigenen BASIC-Erweiterung implementiert!

    P.S. so ein "nosmiley"-Tag für Fließtext wär' manchmal ganz brauchbar. Ständig wird '...8 )' durch '...8)' ersetzt...

  • Hi,

    ich glaube nicht, dass der Hut nur einmal gezeichnet wurde ;) ich hatte ihn mehrfach durchlaufen lassen und verschiedene "Optimierungs"variationen probiert. Z.B. wie sich die Verwendung von Integer-Variablen statt normaler Variablen auf die Laufzeit auswirkt oder ob ich via Print den Farbbildschirm schneller gesetzt bekomme als mit Poke. Der Hut ist durch seine kompakte Programmgröße und lange Laufzeit ideal dafür geeignet.

    Die Verwendung von Konstanten statt Zahlen hatte bei meiner Zeichenroutine übrigens schon den einen oder anderen Geschwindigkeitspunkt (oder besser Pünktchen) gebracht. Allerdings macht die Grafikausgabe nur ca. 10% der Laufzeit aus (hatte ich auch mal getestet). Die Einsparbrocken sind also woanders zu suchen. Dank Deiner Beschreibungen hab' ich wieder paar neue Ideen... :)

    Kleine Frage zur Codezeile: das Next dort wird nur dann ausgeführt, wenn die Then-Bedingung erfüllt ist? Dann müsste ja dann noch ein Next für den "Else"-Fall stehen. Wie stellst Du da sicher, dass ein zweites Next für die I-Schleife nicht zu einem Fehler führt (falls er im IF-Teil die I-Schleife komplett durchläuft)? Mir ist da keine saubere bzw. nicht umständlich aussehende Lösung eingefallen.

    Viele Grüße
    Tale-X

    Wissen ist das einzige Gut, das sich beim Teilen vermehrt. Also seid vorsichtig damit!

  • Zitat von Tale-X

    Kleine Frage zur Codezeile: das Next dort wird nur dann ausgeführt, wenn die Then-Bedingung erfüllt ist? Dann müsste ja dann noch ein Next für den "Else"-Fall stehen. Wie stellst Du da sicher, dass ein zweites Next für die I-Schleife nicht zu einem Fehler führt (falls er im IF-Teil die I-Schleife komplett durchläuft)? Mir ist da keine saubere bzw. nicht umständlich aussehende Lösung eingefallen.


    Im Rest des Programms wird diese Schleife nicht fortgesetzt, und darum - richtig beobachtet - 'hängt' die Schleife zunächst, wenn die IF-Anweisung nicht (mehr) ausgeführt wird. Das ist aber weiter kein Problem, wenn man dann bei der nächst äußeren Schleife die Laufvariable explizit angibt. In diesem Fall sucht NEXT den Stapel nach der FOR-Anweisung mit der passenden Laufvariable ab und entfernt sauber alle 'hängenden', nicht abgeschlossenen Schleifen dazwischen. 8)

    Hier ist das komplette Programm (auf VC-20 mit MINIGRAFIK). Die 'Aufräum-Anweisung' ist das 'NEXT S' in Zeile 28:


    In einem ähnlichen Zusammenhang kann man z.B. auch aus einer offenen Schleife in einer Unterroutine direkt mit RETURN zurückkehren, ohne daß man dazu die Schleife vorher beenden muß.

  • Zitat von »Tale-X«

    Rest des Programms wird diese Schleife nicht fortgesetzt, und darum - richtig beobachtet - 'hängt' die Schleife zunächst, wenn die IF-Anweisung nicht (mehr) ausgeführt wird. Das ist aber weiter kein Problem, wenn man dann bei der nächst äußeren Schleife die Laufvariable explizit angibt. In diesem Fall sucht NEXT den Stapel nach der FOR-Anweisung mit der passenden Laufvariable ab und entfernt sauber alle 'hängenden', nicht abgeschlossenen Schleifen dazwischen.

    Oder wenn ein FOR die gleiche Laufvariable verwendet, werden etwaige bereits offenen FOR-NEXT-Schleifen (und alle darin verschachtelten) vom BASIC-Stack entfernt. Schaut mitunter wild aus - im Forum war in jüngerer Zeit eh so ein Listing nur mit gleicher Schleifenvariable mit an allen Ecken und Enden offenen Schleifen ...

    Oder Bitte melde dich an, um diesen Link zu sehen.: Wenn das in einem Unterprogramm ist, dann räumt das RETURN auch alle im Unterprogramm offen gebliebenen FOR-NEXT-Stack-Frames weg. ;)

  • Jetzt solltest Du die "Zeitersparnis" durch deine "Optimierungen" nur noch ins Verhältnis setzen zu der Zeit, die Du benötigt hast, um diese Änderungen ins Programm einzubringen. Und dann fällt die Bilanz durchgehend negativ aus, wenn man davon ausgeht, daß das Programm nur einmal laufen gelassen wird.

    Macht ja nix, zu diesem Zweck alleine war es auch nicht gedacht. Die Neugier nach dem konkreten Verhalten war hier völlig ausreichend. Wenn es danach ginge, sollte man vielleicht generell die Finger vom C64 lassen. ;)

    Weiterhin leidet die Einsichtigkeit durch die Verwendung von Variablen anstelle von numerischen Konstanten ganz erheblich. Gerade der Ersatz von einstelligen Konstanten durch Variable lohnt sich (mit Ausnahme von - etwa - E=1 und E direkt als erste Variable definiert) fast überhaupt nicht, Null kann aber problemlos überall durch den Dezimalpunkt ersetzt werden. Ersatz von mehrstelligen und 'gängigen' Konstanten wie etwa mit V=53248 ist aber in Ordnung.

    Das kommt darauf an, an welcher Stelle die Variablen definiert bzw. in der Variablen-Liste aufzufinden sind.
    Ich hatte das bislang nicht im Detail untersucht bzw. in allen Varianten verglichen, aber wenn ich mir das jetzt so ansehe, dann ist "." für 0 in der Tat nicht zu unterbieten. Aber dann sind einstellige Konstanten erst dann schneller (manche brauchen länger) erst wenn die Variable an 10. Stelle definiert ist. Ok, da müsste man schon recht aufpassen. Bei 2-stelligen Konstanten (da haben wir ja schon ein Fließkommamultiplikation drinnen), sind ca. die ersten 28 Variablen (da muss man schon 2-stellige nehmen, die aber geringfügig die Suche verlangsamen) schneller als die Konstante.

    Klar, das Gefummle mit den Variablen will man sich freilich nicht antun und wie du schon sagst kann man jedenfalls guten Gewissens alles was mind. 3-stellig auf jeden Fall in eine Variable packen und muss dabei nicht mal an die Reihenfolge achten, um auf jeden Fall einen Geschwindigkeitsvorteil zu erhalten.

    Die "Deklaration" von häufig genutzten Variablen hingegen bringt durchaus etwas, wenn es um eine enge Schleife geht und im wesentlichen nur die Grundrechenarten im Spiel sind. Wovon man im aktuellen Beispiel aufgrund der SQR() und COS() Funktionen leider auch nicht sprechen kann. Ich hab' aber mal in einem anderen Programm (Apfelmännchen) die innere Schleife so erheblich beschleunigt:

    Das hab ich ja nicht verschwiegen bzw. es explizit erwähnt. ;)

    Zusammen mit dem restlichen Programm *) brauchte das für das Ausgangsbild (die "Grundmenge") zunächst mal 195 Minuten. Als ich dann die Variablen X, Y, X2, Y2, XY, R und J (in dieser Reihenfolge) als erste Variablen deklariert hatte, fiel die Rechenzeit auf 156 Minuten! Dabei war es nicht nötig, die Laufvariable I und den Endwert N früh zu deklarieren, da FOR einen Zeiger auf seine Laufvariable ermittelt und so immer schnellen Zugriff hat, und der Endwert auch nur einmal ausgewertet wird und dann mit auf den Stapel geht. Aber als ich dann die Konstante 4 auch noch durch eine Variable ersetzt hatte, wurde das Programm schon wieder langsamer!

    Die FOR-NEXT-Schleifen hab ich ja deswegen auch nicht optimiert, außer die Werte lagen sonst schon in Variablen.
    Wegen der "4", siehe oben. ;)

    Letztenendes war aber genau diese Schleife dann der Knackpunkt und genau die hatte ich dann später mal in Maschinencode übersetzt, wo dann die Arithmetikroutinen des Interpreters direkt aufgerufen wurden. In der Folge wurde dann diese Schleife um den Faktor 3 beschleunigt, zusammen mit dem restlichen Programm lag dann beim Ausgangsbild die Zeit bei ca. 90 Minuten. Ein anderer Koordinatensatz (mit 254 als maximale Rechentiefe) wurde z.B. von 2360 auf 840 Minuten beschleunigt.

    Auch beachtlich. So ein Compiler ist nicht zu verachten.

    Um noch mal zum Hut-3D-Plotter zurückgekommen: mein Originalprogramm war ja auch schon nicht ganz ohne Optimierungen. Zum Beispiel muß man den Bitwert zum Einmaskieren ja nicht unbedingt mit angezogener Handbremse (sprich: mit 2^(7-(XPAND7))) berechnen. Auch die Adreßberechnung arbeitet ja bereits mit einer Tabelle, anstatt ständig den vollen Ausdruck 'AD=8192+320*INT( YP/8 )+8*INT( XP/8 )+(YPAND7)' auszuwerten (mit 'XPAND504' geb' ich dir aber Recht... hab' ich auch schon mal verwendet... )

    Der "^"-Operator ist freilich ein ziemlicher Klotz am Bein. So eine Polynom-Auswertung für die Exponentiation ist freilich dahingehend echt massiv.

    Ansonsten gilt nach wie vor: Experimentieren macht Spaß!

    Das ist das Motto!

    LG, speziell allen Experimentierern
    JeeK

  • Ah gut, hab's verstanden, gut auch der Hinweis mit dem Gosub. Die im Laufe der Zeit entstandenen (Wissens)lücken schließen sich langsam wieder.

    Oder wenn ein FOR die gleiche Laufvariable verwendet, werden etwaige bereits offenen FOR-NEXT-Schleifen (und alle darin verschachtelten) vom BASIC-Stack entfernt. Schaut mitunter wild aus - im Forum war in jüngerer Zeit eh so ein Listing nur mit gleicher Schleifenvariable mit an allen Ecken und Enden offenen Schleifen ...

    In den 80ern wurde man für sowas geteert und gefedert. Eigentlich eine gute Tradition... :bgdev

    Wissen ist das einzige Gut, das sich beim Teilen vermehrt. Also seid vorsichtig damit!

  • Zitat von Mike

    Letztenendes war aber genau diese Schleife dann der Knackpunkt und genau die hatte ich dann später mal in Maschinencode übersetzt, wo dann die Arithmetikroutinen des Interpreters direkt aufgerufen wurden. In der Folge wurde dann diese Schleife um den Faktor 3 beschleunigt, zusammen mit dem restlichen Programm lag dann beim Ausgangsbild die Zeit bei ca. 90 Minuten. Ein anderer Koordinatensatz (mit 254 als maximale Rechentiefe) wurde z.B. von 2360 auf 840 Minuten beschleunigt.

    Zitat von JeeK

    Auch beachtlich. So ein Compiler ist nicht zu verachten.


    Hmm, nein, nix Compiler. Liebevoll selbstgeschriebener und dann assemblierter Maschinencode:


    Das ist bereits für den C64 und kam dann in der portierten Fassung des Mandelbrotgenerators in einem anderen Thread (Bitte melde dich an, um diesen Link zu sehen.) auch zum Einsatz. :)

    Außer daß I und N jetzt als 16 Bit unsigned Integer "deklariert" sind, macht diese Routine exakt dasselbe wie zuvor Zeile 17 in dem Programm - die Parameterübergabe für R und J übernehmen die beiden Routinen bei $AEFD (Check für Komma) und $AD8A (Ausdruck auswerten und nach FAC), so daß man die Routine mit SYS828,R(...),J(...) aufrufen und die Anzahl der tatsächlich stattgehabten Iterationen danach mit 'PEEK(3)+256*PEEK(4)' herausholen kann.

    P.S. Nicht wundern über die &-Zeichen bei den Hex-Konstanten. Das ist der Inline-Assembler von BBC BASIC. 8)

  • Der Hut verleitet zum Experimentieren - ich habe jetzt die Berechnungen als nächstes Optimierungsziel entdeckt:

    Code
    (restlicher Code)
    8 yl=200:n1=-1:n5=.5:z=0:nh=900:eh=100:hs=160:sf=56:vz=14:e=1
    (restlicher Code)
    19 fory=30to-30stepn1:xp=int(z4*sqr(nh-y*y)+n5)
    20 forx=-xptoxp:xr=x/sf:yr=y/vz:r=sqr(xr*xr+yr*yr)
    (restlicher Code)


    Mal etwas umstellen:

    Code
    r=sqr(xr*xr+yr*yr)
    r=sqr((x/sf)*(x/sf)+(y/vz)*(y/vz))
    r=sqr((x*x)/(sf*sf))+(y*y)/(vz*vz))


    sf und vz sind Konstanten, die nur an dieser Stelle verwendet werden, so dass vz*vz und sf*sf schon vorher berechnet werden kann. Eine weitere Abkürzung: die Teilberechnung y*y findet sich auch in Zeile 19 wieder. xr und yr entfallen ersatzlos. Die geänderten Codezeilen lauten dann:

    Code
    (restlicher Code)
    6 dimbi(7),li(24),ad,yq
    (restlicher Code)
    8 yl=200:n1=-1:n5=.5:z=0:nh=900:eh=100:hs=160:sf=3136:vz=196:e=1
    (restlicher Code)
    19 fory=30to-30stepn1:yq=y*y:xp=int(4*sqr(nh-yq)+n5)
    20 forx=-xptoxp:r=sqr(x*x/sf+yq/vz)
    (restlicher Code)


    Ergebnis: statt 53:17 jetzt 52:01. Mit weiteren Optimierungen (Streichen von z1 bis z9, Arraydefinition nach hinten schieben) lande ich bei 51:09 und der Code sieht wie folgt aus:


    Dauer org 56:23
    Dauer neu 51:10
    ->5:10 Minuten Ersparnis (9%)Ist doch schon mal was, oder?

    Okay, nicht berauschend, also weiterschauen:
    Die einzelnen Kurven sind axialsymmetrisch (Kosinus ftw!) und gehen immer von -x bis +x - warum berechnen wir dann die Werte doppelt? Also mal fix das Programm umgestrickt, dass wir gleichzeitig von links und rechts zeichnen (rechts ab Zeile 26), dann reicht bei x auch der halbe Wertebereich:


    Laufzeit jetzt: 30:08 (gegenüber Urfassung eine Einsparung von 26:15 Minuten -> 46% Einsparung). Das bringt was! :)

    Inspiriert hat mich dazu übrigens der KC85/3 mit seiner Kreiszeichenroutine (8 Punkte gleichzeitig) - das war sichtlich effizienter als das was Simons Basic malte...

    Und nu viel Spaß beim knacken der 30:00er Marke - im Array- statt Poke-Thread gibt's einen Tipp dafür.

    Frohes Experimentieren (und nicht immer nur auf den Code schauen! ;) )
    Tale-X

  • Klasse Arbeit. Freut mich zu sehen, wie das von vielen gescholtene 64er BASIC doch noch Verwendung findet. :ilikeit:

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom:

  • Danke *verneig* Das Basic vom C64 ist nicht zu verachten - welches Basic hat so einen mächtigen Befehl, der sämtliche Grafik- und Soundbereiche abdeckt :bgdev

    Ich weiß nicht, ob ich's schreiben soll, aber ich bin jetzt beim Hut bei 21:56 Minuten Laufzeit... in Basic :whistling:

    Wissen ist das einzige Gut, das sich beim Teilen vermehrt. Also seid vorsichtig damit!

  • Danke *verneig* Das Basic vom C64 ist nicht zu verachten - welches Basic hat so einen mächtigen Befehl, der sämtliche Grafik- und Soundbereiche abdeckt :bgdev


    Du willst doch nicht wirklich dazu ne Antwort von mir hören, oder? 8o

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom:

  • Danke *verneig* Das Basic vom C64 ist nicht zu verachten - welches Basic hat so einen mächtigen Befehl, der sämtliche Grafik- und Soundbereiche abdeckt :bgdev


    Ich beantworte das mal: jedes Basic (zumindest auf den 8-Bittern)

    (Ich bin C64-Fan, dennoch...)

  • Gibt ja noch die andere positive Sichtweise: kaum ein anderes Basic macht einem den Wechsel zu Assembler so leicht :D

    Wissen ist das einzige Gut, das sich beim Teilen vermehrt. Also seid vorsichtig damit!