Hello, Guest the thread was called4.5k times and contains 99 replays

last post from BIF at the

BASIC-Programme - "wirbleibenzuhause"

  • Gibt es das auch als CBR-Datei, damit man es sich auf ein FC ziehen kann? Oder das neue Kung Fu Flash?

    TSB ist ein Onefiler von $8000 bis $cfff mit Stellen, die beschreibbar bleiben müssen ($c000.. ist Farbram für die Grafik, $c500.. ist Parameter-Puffer, $cc00.. ist Videoram nach MEM). Ein paar Bereiche werden u.U. ausgetauscht (bei NRM, MEM, INST und GRAPHICS). Kung Fu Flash?


    Arndt

  • Gibt es das auch als CBR-Datei, damit man es sich auf ein FC ziehen kann? Oder das neue Kung Fu Flash?

    TSB ist ein Onefiler von $8000 bis $cfff mit Stellen, die beschreibbar bleiben müssen ($c000.. ist Farbram für die Grafik, $c500.. ist Parameter-Puffer, $cc00.. ist Videoram nach MEM). Ein paar Bereiche werden u.U. ausgetauscht (bei NRM, MEM, INST und GRAPHICS). Kung Fu Flash?


    Arndt

    Ok, dann geht das natürlich nicht. Oder doch - es müsste sich halt erst ins RAM kopieren, irgendwie wäre das bestimmt möglich. Ich bin aber kein Fachmann.


    Das Kung Fu Flash ist ein neues Modul, Hier gibt es Infos dazu:

    Kung Fu Flash Cartridge


    Ich hab eins hier, Bigby bietet ab und zu über den Marktplatz fertig aufgebaute Module an.

  • Vielleicht freeze ich es für mein Archiv mal, kurz vor dem Animations-Start, dann muss man gar nicht mehr warten.

    Wenn du es so speicherst, hast du aber immer das selbe Bild. Der zufällige Aufbau ist dann außen vor. Für ein einzelnes Bild würde

    ich nur die Bitmap speichern und dann den Code für die Animation hinzufügen.


    Und weil wir gerade bei "Linien ziehen" sind: Gab es für Homecomputer nie so etwas, wie das Hobbythek Bilderrätsel, bei dem man mit einem Filzer auf dem Bildschirm einem Leuchtpunkt folgen und am Ende dann das bildlich dargestellte Wort erraten musste? Das wäre doch gar nicht so schwer umzusetzen, oder?

    Hallo Retrofan, ich habe so ein Programm für den C64 fertig. Ich brauche nur noch jemanden zum Testen. Ich halte es aber für sinnvoller das Programm

    für den PC zu schreiben. Dann kann man statt des Filzstiftes mit der Maus dem Lichtpunkt folgen.


    Sieht auf jeden Fall schon grafisch stark aus.

    Danke. Mit Animation wird's noch besser.



    Eine Zufallsfunktion, was die Farben sowie die Dicke der Kreisringe angeht, könnte noch cool sein.

    Beides ist möglich. Zufällige Farben sehen wahrscheinlich nicht so gut aus, weil die Farben zueinander passen sollten.

    Unterschiedlich dicke Kreisringe vertragen sich nicht so gut mit der Animation. Aber das Programm ist noch ausbaufähig,

    ich teste noch ein bisschen herum.

    Ist der CCS64-Emulator schneller als der Vice-Emulator?


    Ich war mal so frei, das zu kompilieren (läuft danach ungefähr 4,5mal schneller).

    Ja, die kompilierte Version ist um einiges schneller. Das liegt aber auch zum Teil daran, dass du die

    Zahl der Kreise reduziert hast.




    Gruß,


    Neptun

  • Wenn du es so speicherst, hast du aber immer das selbe Bild. Der zufällige Aufbau ist dann außen vor. Für ein einzelnes Bild würde

    ich nur die Bitmap speichern und dann den Code für die Animation hinzufügen.

    Das stimmt natürlich, der bessere Weg ist über die WARP-Funktion des CCS64 und dazu noch eine kompilierte Version des Programms zu nehmen, wie es etwa der User "EgonOlsen" weiter vorne gemacht hat, dann geht's auch so schon richtig flott, bis das Bild voll aufgebaut ist und die Animation startet.


    Ist der CCS64-Emulator schneller als der Vice-Emulator?

    Er lässt sich, meiner Erfahrung nach, auf jedenfall wesentlich schneller beschleunigen als alle anderen C64 Emulatoren, da er bei weitem die geringsten Ansprüche an die CPU des PC's stellt. Schon auf wirklich alten Rechnern, läuft der CCS64 bereits in Fullspeed ohne Frameskipping. Ich bekomme ihn auf meinem PC, der jetzt auch nicht gerade top-aktuell ist, auf 37-fachen Speed (3700%), das geht dann schon ordentlich ab. Musst du mal ausprobieren auf deinem System mit der Version 3.9.2 des CCS64, du wirst dich wundern wie schnell man ihn bekommt. Im Menue des Emu's kann man maximal bis zu 100-fachen Speed einstellen, aber ich weiss nicht, ob das in der Realität überhaupt möglich ist, wegen der Bildwiedergabe. Wahrscheinlich wird man nicht auf die vollen 10000% Speed kommen, aber mal sehen wieviel Speed dein PC da dann schafft, da könntest du mal eine Rückmeldung geben, es würde mich interessieren.

  • Ich war mal so frei, das zu kompilieren (läuft danach ungefähr 4,5mal schneller).

    Ja, die kompilierte Version ist um einiges schneller. Das liegt aber auch zum Teil daran, dass du die

    Zahl der Kreise reduziert hast.

    Ich verstehe nicht, was genau du meinst!? Ich habe an dem Programm doch gar nichts in der Richtung verändert...jedenfalls nicht bewusst.

  • Hallo Retrofan, ich habe so ein Programm für den C64 fertig. Ich brauche nur noch jemanden zum Testen. Ich halte es aber für sinnvoller das Programm

    für den PC zu schreiben. Dann kann man statt des Filzstiftes mit der Maus dem Lichtpunkt folgen.

    Nur wegen der Maus müsstest du nicht zum PC wechseln – die gibt es auch für den C64. Ich weiß aber nicht, inwiefern sich der Spaß ändert, wenn man dem Punkt mit dem Mauspfeil folgt, statt mit dem Filzer. Ich kann die Frage ja mal in die Runde werfen ...

  • Ich verstehe nicht, was genau du meinst!? Ich habe an dem Programm doch gar nichts in der Richtung verändert...jedenfalls nicht bewusst.

    Also, in dem Programm, das ich gepostet habe steht die Anzahl der Kreise auf 11. Zeile 80: n=11
    Das heißt, es sind immer 11 Kreise sichtbar. Bei deinem kompilierten Code werden aber immer 8

    Kreise gezeichnet. Könnte ein Tippfehler sein, oder der Compiler hat ein Problem mit dem

    Programm.


    Gruß,


    Neptun

  • Also, in dem Programm, das ich gepostet habe steht die Anzahl der Kreise auf 11. Zeile 80: n=11
    Das heißt, es sind immer 11 Kreise sichtbar. Bei deinem kompilierten Code werden aber immer 8

    Kreise gezeichnet. Könnte ein Tippfehler sein, oder der Compiler hat ein Problem mit dem

    Programm.

    Ahhhh, ok. Vielen Dank für den Hinweis. Ja, der hatte tatsächlich ein Problem mit dem Programm. Weil du da beim Initialisieren des Arrays immer mal mit GOTO aus der inneren Schleife springst. Was der Interpreter bei dieser Schmutzigkeit macht, war mir nicht klar. Dieser Fall ist mir in all meinen (über 100) Testfällen auch noch nie untergekommen. Deswegen habe ich das in der Compiler-Runtime falsch behandelt und den Stack nicht entsprechend bereinigt. Ist jetzt korrigiert, im Anhang ist eine richtig laufende Fassung. Das sollte auf die Geschwindigkeit selber aber eigentlich keine große Auswirkung haben, weil auch das alte Programm durchaus alle 11 Kreise bearbeitet hat...nur lagen eben immer ein paar davon irgendwie außerhalb, weil das Array nicht vollständig mit "guten" Kreispositionen initialisiert worden ist.

  • Weil du da beim Initialisieren des Arrays immer mal mit GOTO aus der inneren Schleife springst.

    Ja, das stimmt. Das C64-Basic erlaubt das Verlassen der Schleife mit Goto, warum

    sollte man es nicht nutzen. Exit For oder ähnliches gibt es ja nicht. Die Alternative

    sieht auch nicht sehr elegant aus. Man müßte die Schleifenvariable auf den Endwert

    setzen und dann mit Goto zu dem Next springen. Außerhalb der Schleife springt man

    dann flaggesteuert wieder vor die Schleife.



    Ist jetzt korrigiert, im Anhang ist eine richtig laufende Fassung.

    Getestet und funktioniert.


    Hier noch mal eine überarbeitete Version der konzentrischen Kreise mit 16 Farben.

    Sollte etwas schneller sein:


    Gruß,


    Neptun

  • Ja, das stimmt. Das C64-Basic erlaubt das Verlassen der Schleife mit Goto, warum

    sollte man es nicht nutzen. Exit For oder ähnliches gibt es ja nicht. Die Alternative

    sieht auch nicht sehr elegant aus. Man müßte die Schleifenvariable auf den Endwert

    setzen und dann mit Goto zu dem Next springen. Außerhalb der Schleife springt man

    dann flaggesteuert wieder vor die Schleife.

    Nee, eine Art BREAK gibt es nicht. Weil es im Prinzip auch gar keine Schleifen gibt. Ja, steile These, aber: FOR und NEXT hängen im BASIC V2 nicht direkt zusammen, wie sie das in einer modernen Sprache tun würden. Es sind voneinander unabhängige Befehle, die nur über den FOR-NEXT-GOSUB-Stack verbunden sind. Es kann kein BREAK geben, weil der Interpreter gar nicht wissen kann, welches der zu unterbrechende Schleifenblock sein soll...weil es strukturell gar keinen gibt. Deswegen sind mit FOR-NEXT alle möglichen Schmutzigkeiten möglich. Ich bin davon überzeugt, dass mindestens die Hälfte davon quasi "aus Versehen" entstanden ist und gar nicht bewusst so entworfen worden ist. Ich kann problemlos ein Programm mit einem FOR und 25 NEXT schreiben...oder umgekehrt. Völlig blödsinnig, aber syntaktisch korrekt.

  • Nur wegen der Maus müsstest du nicht zum PC wechseln – die gibt es auch für den C64.

    Ja, aber ein C64 mit Maus ist selten.

    Hier mal die C64-Basic-Version des Hobbythek-Bildschirmrätsels zum Testen:


    Gruß,


    Neptun

  • Ja, das stimmt. Das C64-Basic erlaubt das Verlassen der Schleife mit Goto, warum

    sollte man es nicht nutzen. Exit For oder ähnliches gibt es ja nicht. Die Alternative

    sieht auch nicht sehr elegant aus. Man müßte die Schleifenvariable auf den Endwert

    setzen und dann mit Goto zu dem Next springen. Außerhalb der Schleife springt man

    dann flaggesteuert wieder vor die Schleife.

    Falls ich mich recht erinnere, baut FOR eine Referenz auf die Variable auf den Stack, und NEXT zählt bei Bedarf den mit TO gegebenen Wert dazu (wobei das Inkrement glaube ich auch zusammen mit dem höchsten Ziel-Wert auf dem Stack steht). Was also passiert, wenn man eine Schleife "grußlos" verlässt, ist, dass der Schleifen-Müll auf dem Stack stehen bleibt. Macht man das oft genug, müllt man sich den Stack total zu.

    Mein Vorschlag wäre daher, beim Verlassen die Variable auf den letzten Wert zu setzen, und dann ein letztes NEXT durchzuführen, dass erkennt, dass die Variable hoch genug ist (oder niedrig genug bei negativem Step), den Mǘll vom Stack entfernt, und dann weiter läuft. Der nächste Befehl kann ein GOTO sein. Beispiel:


    Code
    1. FOR I=0 TO 10
    2. .. blabla
    3. IF <Bedingung>THEN I=10:NEXT:GOTO <exit>
    4. .. blabla
    5. NEXT I
    6. <exit>..

    OK, habs nicht ausprobiert, sollt aber so oder so ähnlich funktionieren.


    Nachtrag: Habs doch ausprobiert. Funzt! Wichtig ist nur, dass im Programm-Ablauf nicht zweimal dieselbe Variable "genexted" wird. Das gibt einen Fehler "?NEXT WITHOUT FOR ERROR IN .."

  • Falls ich mich recht erinnere, baut FOR eine Referenz auf die Variable auf den Stack, und NEXT zählt bei Bedarf den mit TO gegebenen Wert dazu (wobei das Inkrement glaube ich auch zusammen mit dem höchsten Ziel-Wert auf dem Stack steht). Was also passiert, wenn man eine Schleife "grußlos" verlässt, ist, dass der Schleifen-Müll auf dem Stack stehen bleibt. Macht man das oft genug, müllt man sich den Stack total zu.

    Das mit dem Stack stimmt im Prinzip, aber in diesem Fall wird immer wieder eine neue Schleife mit derselben Laufvariablen gestartet. Die ersetzt dann den jeweils auf dem Stack verbliebenen Eintrag für diese Variable (und killt alle später auf den Stack gepushten Einträge). Das wusste ich auch nicht, deswegen hat meine Compiler-Runtime das auch anfangs nicht korrekt behandelt. Das ist eine dieser Eigenschaften, von denen ich denke, dass die mehr aus Zufall so sind wie sie sind.

  • Falls ich mich recht erinnere, baut FOR eine Referenz auf die Variable auf den Stack, und NEXT zählt bei Bedarf den mit TO gegebenen Wert dazu (wobei das Inkrement glaube ich auch zusammen mit dem höchsten Ziel-Wert auf dem Stack steht). Was also passiert, wenn man eine Schleife "grußlos" verlässt, ist, dass der Schleifen-Müll auf dem Stack stehen bleibt. Macht man das oft genug, müllt man sich den Stack total zu.

    Das mit dem Stack stimmt im Prinzip, aber in diesem Fall wird immer wieder eine neue Schleife mit derselben Laufvariablen gestartet. Die ersetzt dann den jeweils auf dem Stack verbliebenen Eintrag für diese Variable (und killt alle später auf den Stack gepushten Einträge). Das wusste ich auch nicht, deswegen hat meine Compiler-Runtime das auch anfangs nicht korrekt behandelt. Das ist eine dieser Eigenschaften, von denen ich denke, dass die mehr aus Zufall so sind wie sie sind.

    Danke für die Korrektur. Sehe ich es richtig, dass jedes "next" diesen Eintrag bloß erneuert? Stimmt nun meine Aussage mit dem Stack-Müll, den man hinterlässt, wenn man nicht zuende "nextet"?

  • Sehe ich es richtig, dass jedes "next" diesen Eintrag bloß erneuert? Stimmt nun meine Aussage mit dem Stack-Müll, den man hinterlässt, wenn man nicht zuende "nextet"?

    Ja, aber eben nicht unter allen Bedingungen. Das ist nur dann ein Problem, wenn du verschiedene Schleifen mit verschiedenen Variablen per FOR öffnest und nicht zum Ende durchlaufen lässt. Dann ist der Stack beim 11. FOR voll und du bekommst einen Out Of Memory Error. Wenn du immer dieselbe Variable benutzt, ist das ok. Also soweit das ok sein kann, sowas zu bauen. Oder wenn du die FORs in per GOSUB angesprungenen Unterprogrammen öffnest, aus denen du vor dem "Durchnexten" mit RETURN zurückspringst, dann ist das auch ok, weil das RETURN den Stack bis zum aufrufenden GOSUB abräumt (FOR und GOSUB landen auf demselben Stack).

  • Sehe ich es richtig, dass jedes "next" diesen Eintrag bloß erneuert? Stimmt nun meine Aussage mit dem Stack-Müll, den man hinterlässt, wenn man nicht zuende "nextet"?

    Ja, aber eben nicht unter allen Bedingungen. Das ist nur dann ein Problem, wenn du verschiedene Schleifen mit verschiedenen Variablen per FOR öffnest und nicht zum Ende durchlaufen lässt. Dann ist der Stack beim 11. FOR voll und du bekommst einen Out Of Memory Error. Wenn du immer dieselbe Variable benutzt, ist das ok. Also soweit das ok sein kann, sowas zu bauen. Oder wenn du die FORs in per GOSUB angesprungenen Unterprogrammen öffnest, aus denen du vor dem "Durchnexten" mit RETURN zurückspringst, dann ist das auch ok, weil das RETURN den Stack bis zum aufrufenden GOSUB abräumt (FOR und GOSUB landen auf demselben Stack).

    Danke für die Info!