FAST.BAS : "Rasen mit 310 Km/h" in BASIC - sollte eigentlich ein 10-Zeiler werden, aber da es dann auch spielbar und mit Anreiz sein sollte, sind es 13 Zeilen geworden

  • Ich habe mal im CBM 8032 Handbuch nachgesehen.
    Da steht zwar nicht drin, daß Integer-Variablen nicht verwendet werden können, das scheint aber beim Commodore Basic ganz einfach der Fall zu sein.
    Es werden ausschließlich Gleitkomma-Variablen in den Beispielen verwendet.


    Stattdessen habe ich aber andere nützliche Hinweise gefunden:


    Wenn man die Variable hinter NEXT weglässt, ist die Ausführung schneller, als mit Variable.
    Grund: Wenn keine Variable vorhanden ist, wird automatisch die letzte gestartete Schleife angenommen, was anderes geht ja eh nicht.
    Wird die Variable aber angegeben, wird auch überprüft, ob's die richtige war.
    Das macht sich bei dem kleinen Testprogramm aus Beitrag 27 schon deutlich bemerkbar.
    Ohne Angabe der Schleifenvariable dauert die Ausführung auf dem PET 713 Ticks, mit 884.
    Ziemlich genau 10% länger. Gut zu wissen.


    Ein Rückspung vom Schleifenende (NEXT) zum Anfang (FOR) ist deutlich deutlich schneller, als ein GOTO.
    Der Grund ist im Handbuch nicht beschrieben, dürfte aber klar sein:
    GOTO sucht die passende Zeilennummer ab dem Porgrammanfang (oder aktuell ausgeführter Zeile, sofern die angesprungene eine höhere Zeilennummer hat), bei der FOR-NEXT Schleife wird stattdessen die Adresse des Schleifenanfangs (FOR) gespeichert, und von NEXT aus direkt wieder angesprungen, ohne Suche.


    Das lässt sich natürlich auch für das Raser-Spiel verwenden. Man muß lediglich in der Schleife solange den Zählwert unter dem Endwert halten, wie die Schleife ausgeführt werden soll.

  • Hast Du schon den Austro Speed BASIC Compiler mal damit gefüttert (oder auch den PETSPEED Compiler) ? Das sind beides BASIC Compiler für die PET/CBM Serie.


    Ich selbst hab' erst mal mit einer weiteren Entwicklung aufgehört.
    Meine bisherigen Erfolge können auf meinem Blog "bewundert" werden - dort habe ich übrigens auch eine Windows 7 kompatible Version zum Ausprobieren abgelegt.

    "Probleme kann man niemals mit derselben Denkweise lösen, durch die sie entstanden sind."


    ... und schaut auch mal bei meinem Blog vorbei ...

  • Das ganze durch den Compiler zu schicken würde es natürlich deutlich schneller machen, ich sehe aber eher den Reiz darin, in Basic weiter zu optimieren.
    Auf alle Fälle wollte ich mir mal ansehen, wie Du die schönen Kurven generierst. Bei der momentanen Variante ist die Streckenführung nämlich alles andere als überzeugend.

  • Christian , kann es sein, das deine letzte Version des Programmes nicht auf einem CBM II Rechner läuft?
    Habe es in meinen CBM 610 eingegeben. Irgendwie fängt er an die Straße aufzubauen und bricht dann sofort
    mit dem "Crash" ab. Ich komme erst gar nicht dazu irgendwie irgendwas zu steuern.


    Gruß Björn

  • Das hat meherere Gründe.
    Der Bildschirmspeicher liegt in einem anderen Adressbereich, auf den greift das Programm direkt zu.
    Das ist der Grund für den Crash direkt bei der ersten Kollisionsabfrage.
    Außerdem ist beim CBM-II die Variable TI nicht mehr dem Timer zugeordnet.
    Dort gibt es dafür nur noch die Variable TI$, die dann auch noch ein anderes Format hat.

  • Falls doch jemand noch Interesse daran hat, auf dem PC das Ganze zu verfeinern - da der TIMER auf dem PC normalerweise nur maximal genau auf 18.2ms auflöst, ist ein anderes Delay (gerade wenn man auch einen Compiler benutzt) so nicht mehr möglich.
    Auf http://www.tek-tips.com/faqs.cfm?fid=917 wird beschrieben, wie man die interne Uhr auch noch benutzen kann, sieht komplex aus, ist aber Dank Unterprogrammen/Funktionsdefinitionen einfach zu nutzen.


    PDF-Datei später noch angehängt - der Anhang beschreibt auch, wie man statt 18.2ms nun 1ms (also eine wesentlich kleinere Zeitspanne) als Timer nutzen kann. Das Ganze sieht allerdings nicht mehr besonders einfach aus :-(