Hello, Guest the thread was called13k times and contains 274 replays

last post from Drachen at the

Basic Mega65 - Boulder Dash

  • Ein drumherum Update von mir, über das Basic und seine Eigenheiten mit dem Datentype Real. Ach wäre es schön, wenn Integer nicht nur bei FOR TO NEXT verwendet würde.

    Schleifen sind damit extrem schnell im Vergleich zu Real. Leider sind in der Hauptschleife von BD nur IF THEN nötig und die sind extrem lahmmmmm im Vergleich zu FOR. Das liegt natürlich an den Datentype Real, der deutlich langsamer ist. Bei PEEK und POKE ergibt Real gar keinen Sinn, aber selbst da wird intern mit Real gerechnet. Man kann sogar solchen einen Unsinn schreiben A=53280.999:POKE A,1. Kurz noch, es gibt das Binäre verschieben mit << >>, das auch langsamer als * oder / ist hmmmm.

    Aber zurück zu IF THEN und die viel schnellere Alternative dazu.


    Hier mal eine Zeile der Abroll-Routine -> Stein/Diamant.

    Code
    1. 60 IF PEEK (O+39) =. THEN IF PEEK (O-L) =. THEN NEXT
    2. 60 FGOTO A(PEEK(O+39))
    3. 65 FGOTO A(PEEK(O-L ))
    4. 70 NEXT

    Im Bench benötigt eine Schleife von 10000 ca. 1,95 Sekunden und mit FGOTO nur 1,34. Und das auch nur, weil ich hier den Punkt verwenden kann, sonst wäre IF noch langsamer. Man könnte jetzt einfach FGOTO verwenden und gut ist, aber der arme Drachen müsste sich Tage und Nächte lang in den Code einlesen. Und sich durch eine Wüste von DIM Feldern kämpfen, um Zeilennummern anzulegen oder zu ändern.


    Mit FGOTO würde das in etwas so aussehen.

    Code
    1. 20 O=O+1:FGOTO A(PEEK(O)) : REM Hauptschleife
    2. 30 FGOTO B(PEEK(O+40)) : REM Stein (liegt) unten
    3. 40 FGOTO C(PEEK(O+39)) : REM Stein (liegt) links unten
    4. 50 FGOTO D(PEEK(O+41)) : REM Stein (liegt) rechts unten
    5. 60 FGOTO C(PEEK(O-1 )) : REM Stein (liegt) links
    6. 70 FGOTO D(PEEK(O+1 )) : REM Stein (liegt) rechts
    7. 80 POKE O,.:POKE O-1,14:GOTO 20 : REM Stein (liegt) links bewegen -> Stein fallend
    8. 90 POKE O,.:O=O+1:POKE O,14:GOTO 20 : REM Stein (liegt) rechts bewegen -> Stein fallend

    Für den fallenden Stein werden nochmal drei DIM Felder benötigt. Bei den anderen aktiven Objekten kommen nochmal unzählig Felder dazu. Man könnte dann sogar die Zeilen im Programm so legen, das die häufig ausgeführten Zeilen möglich oben im Programm liegen. Allein die Sprünge für jedes Feld zu definiert, damit jedes Objekt richtig behandelt wird, kostet viel Zeit und besonders viel, wenn sich ein Fehler eingeschlichen hat.


    Jetzt die Frage IF THEN belassen oder DIM und damit Drachen in den Wahnsinn treiben mit A(0)=20:A(1)=20. Übrigens, jedes Feld hat eine Dimension von (52), das sind viele Sprünge, die man eintragen muss. Aber allein das Entfernen von ON GOTO durch FGOTO führte zu ein spürbares Speedup, obwohl jetzt hohe Zeilennummern benutzt werden. Mit Einser schritte von 0 ab sollte für ein weiteres Speedup sorgen, aber das ist erst beim fertigen Spiel sinnvoll.

  • Bei PEEK und POKE ergibt Real gar keinen Sinn

    Leider doch, weil BASICs Integer Signed Int 16 sind und nur bis 32767 gehen. Da ginge dann also schon kein POKE53280,0 mehr.


    Gibt's denn gar keinen Basic-Compiler für den MEGA65? Evtl. tut ja sogar Blitz schon (dann bleiben alle neuen Befehle unbeschleunigt, aber dürfte ziemlich egal sein) - damit hätte man dann deutliche Beschleunigung ohne die ganzen eher hässlichen Hacks à la "Unterprogramme ganz zuerst", "nur einstellige Variablennamen" und so weiter.

  • Müssen wir dann alles komplett neu machen. Sprich denn jetzigen Stand anhalten und von vorne beginnen mit deinen vorgeschlagender Version ?

    Wenn es dadurch schneller wird, warum nicht.

    So wie ich diesen Code verstehe, gehst du da alle Positionen durch das Spielfeld durch, oder sind die Variabeln die Steine.

    Könntest du da mal ein kurzes Programm schreiben.

    Und das mit den vielen Variabelnamen, kann man das dann nicht so machen A(1) - Stein liegt unten, A(2) - Stein liegt links unten usw.

    Dann bräucht man nicht soviele Variabeln, denn es kommen ja auch noch der Firerfly, Butterfly, Amoeba.


    Ich wäre dazu bereit das auch wieder umzuschreiben, wenn es dadurch schneller wird.

    Aber das schaffe ich dann nicht über Pfingsten, :schreck!:

  • Ich wäre dazu bereit das auch wieder umzuschreiben, wenn es dadurch schneller wird.

    Ich habe das jetzt mal beim liegenden Stein getestet und wir müssen Dich doch nicht in den Wahnsinn treiben. Im direkten Vergleich kann man keinen Unterschied sehen, zweimal Mega65 gestartet und laufen laufen laufen gelassen. Nochmal Glück gehabt, die Abfrage erst unten links und rechts zu testen ist optimal, dadurch wird IF THEN für links rechts selten ausgeführt.

    So wie ich diesen Code verstehe, gehst du da alle Positionen durch das Spielfeld durch, oder sind die Variabeln die Steine.

    Ja ich gehe alle Positionen durch und die Engine arbeitet von oben nach unten, damit wird das Verhalten der BD-Engine genau nachgebildet.

    Könntest du da mal ein kurzes Programm schreiben.

    Ich Versuche das mal kurz zu erklären:

    Mit PEEK(O) wird das aktuelle Objekt ausgelesen. Die Reihenfolge der Objekte geht von CHARDEF 0 - CHARDEF 52.

    CHARDEF 0 ist SPACE

    CHARDEF 1 ist SAND

    usw.

    CHARDEF 13 ist der Stein liegend und 14 fallend.


    Wird mit der Zeile O=O+1:FGOTO A(PEEK(O)) zum Beispiel SPACE gelesen, springt die Routine direkt wieder auf die Zeile. Da in A(0)= die Zeilennummer für die Aktion von Space steht. Bei passiven Objekten wird praktisch die Zeile solange ausgeführt bis ein aktives Objekt gefunden wird. Beim Stein A(13) zeigt der Sprung auf die Routine -> Stein unten, da bei unten mehrere Abfragen möglich sind, wird wieder ein FGOTO B(PEEK(O+40)) verwendet.

    Wenn jetzt unter den Stein ein Space ausgelesen wird, springt die Routine direkt nach Stein fällt runter. Dadurch werden keine unnötigen Abfragen gemacht.

    Mit diesen einen FGOTO ist sofort klar, was zu machen ist, Space = fallen : Stein = rollen : Diamant = rollen : Magische Mauer = Stein zu Diamant : usw.


    Ich hoffe, das Prinzip ist jetzt etwas klarer.

  • Müssen wir dann alles komplett neu machen. Sprich denn jetzigen Stand anhalten und von vorne beginnen mit deinen vorgeschlagender Version ?

    Wenn es dadurch schneller wird, warum nicht.

    Übrigens, es besteht hier absolut kein Zwang, wenn Du mit der Variante von TheRealWanderer besser klar kommst, warum nicht. Man kann ja das ein oder andere übernehmen.

    Die schlechte Kollisionsabfrage kann man durch mehrfach abfragen deutlich verbessern. Normalerweise wird die Kollision vom Stein ausgelöst, da der Schmetterling ebenfalls eine Kollisionsabfrage für den Spieler und Amöbe enthält, könnte die nach oben Abfrage zusätzlich auf fallenden Stein erweitern. Dann sollte die Kollision mit einem fallenden Stein besser erkannt werden.

  • Nein noch nicht ganz. :roll:

    Wie kommst du auf 52 Objekte!

    Bei BD sind es ja nur 12 Grafikelemen, ohne Animationsphasen beim Rockfort, Butterfly, Firerfly, Diamant, Magische Wand und Amoeba

    Oder es ist wirklich spät und in meinen Gehirn passt nichts mehr rein. :gruebel


    Ich hatte ganz am Anfang so eine ähnliche Routine wo ich das komplette Spielfeld als Array Feld hatte z.B. Feld(x,y).

    Ich wurde aber auf Grund des ständigen einlesen des Spielfeldes vom System ausgebremst.

    Deswegen fand ich ja deine und die von TheRealWanderer so klasse. Denn die verfolgen ein anderes Einlesesystem.


    Hast du zufälligerweise einen Codeschnippsel für einen fallenden Stein, vielleicht checke ich es dann.

  • In Feld (B) sind alle Zeilennummern, die den liegenden Stein betreffen. Mit Feld (A) werden die entsprechenden Routinen angesprungen.

  • In Feld (B) sind alle Zeilennummern, die den liegenden Stein betreffen. Mit Feld (A) werden die entsprechenden Routinen angesprungen.

    OK so allmählich komme ich auf den Trichter wie du das meinst.

    Du gibst alle Fälle ein wo auftreten können bei den Objekten. Das wird aber ein sehr langes Listing. :D

    Schaue ich mir an, und fange dann mal an das so umzuschreiben. :D

  • Wenn man es Verstanden hat, ist das sehr simpel. Die BD-Engine von Peter Liepa macht das übrigens für die Hauptschleife genauso. Ich verwende das zusätzlich beim Stein/Diamant und der Amöbe. Bei der Amöbe nur, weil man nachdem wachsen überprüfen muss, ob diese noch frei ist.


    Noch was zur Kollision:

    Normalerweise werden nur beim Glühwürmchen und Schmetterling alle vier Richtungen überprüft. Das hat einen großen Nachteil, für den Spieler ist jedoch ein Vorteil. Deshalb sollte man auch beim Spieler ein Kollisionstest einbauen.


    Sonst kann man sowas machen.

    Bekanntlich arbeitet die Engine von links oben an, das Zeile für Zeile. Wenn man beim Glühwürmchen wartet, bis diesen genau unter einem ist, würde beim nächsten Durchgang eine Kollision erkannt. Da der Spieler eine Zeile höher steht als der Glühwürmchen, kann man noch einen Schritt gehen, zeitlich hat die Kollision ja noch nicht stattgefunden. Bewegt man sich in die Laufrichtung des Glühwurms, sieht das im Spiel so aus, als wenn der Spieler genau über dem Glühwürmchen ist. Das kann man sehr schön bei Level I aus BD-II testen.

  • Ich benutze aber gleich deine neue Levelaufbauengine dafür.

    Das wird aber eine weile brauchen bis ich das so umgeschrieben habe, da ich über Pfingsten nicht so viel Zeit habe, wie sonst. :D


    Mal schauen wann ich was liefern kann. Der erste Abschnitt wird sein, fallende Steine und Diamanten. Bin gespann was TherealWanderer dazu meint

  • Leider doch, weil BASICs Integer Signed Int 16 sind und nur bis 32767 gehen. Da ginge dann also schon kein POKE53280,0 mehr.

    Was spricht dagegen den Datentyp WORD einzuführen. Dann hätte man alle relevanten Datentypen für Basic drin. Bei FOR TO NEXT wäre auch direkt der ganze Adressbereich abgedeckt.

  • Hallo Acron,


    habe endlich mal Zeit gehabt mich mit deiner Engine auseinander zu setzten.

    Also ich habe erstmal alle deine Multicolorgrafik in meiner Hiresgrafik ausgewechselt. Hat geklappt.

    Dann habe habe ich deine neue Levelaufbau Engine mit gegen deine alte ausgetauscht.

    Und hier haben dann die Probleme angefangen, habe auch schon ein paar ausmerzen können. Aber das größere Problem eben nicht.

    Die Engine scheint nicht mit deiner neuen Aufbauroutine nicht laufen zu wollen. Die Steine wollen einfach nicht fallen, obwohl deine Engine das Bild ständig abfragt.

    Vielleich hämgt es mit dem Anfangswert zusammen. Du beginnst ja bei Stelle 2088, ich möchte aber bei 2128 brginnen, weil ich die ersten zwei Zeile für die Anzeige des Spiels brauche.

    Könntes du eventuell mal drüber schauen woran es liegen kann. Ich konnte bis jetzt nichts falsches finden, aber das will ja nichts heißen. Sicherlich ist es ein blöder Fehler den ich einfach nicht sehe.

    in der ZIP-Datei ist die BAS-Datei und das PRG-Datei

    Boulderdash_Mega65_Basic.zip


    Im Voraus vielen Dank für deine Mühe

  • Sicherlich ist es ein blöder Fehler den ich einfach nicht sehe.

    Das liegt daran, dass du Stein 12 genommen hast und dafür gibt es noch gar keine Routine. Der richtige Stein liegt auf Zeichen 13 und der Diamant hat Zeichen 17.

  • Sicherlich ist es ein blöder Fehler den ich einfach nicht sehe.

    Das liegt daran, dass du Stein 12 genommen hast und dafür gibt es noch gar keine Routine. Der richtige Stein liegt auf Zeichen 13 und der Diamant hat Zeichen 17.

    Oh Danke für die Info werde ich verbessern.

    ************************************************************************************************************************************


    So habe das jetzt mal geänder, läuft super.

    Jetzt noch die Farbe anpassen und noch ein paar anderen Sachen