Hello, Guest the thread was called27k times and contains 409 replays

last post from xboxown1200 at the

Basic Mega65 - Boulder Dash

  • Genau.


    8530 : POKE $D800-$0800+E0+YY*40+XX,F%(OF)


    In der Variablen E0 ist das Offset für den Bildschirmspeicher, also $0800 enthalten. Damit wurden die Farben an die Adresse ab $E000 geschrieben.

  • Das war mit seinem Source, den er davor gepostet hat.


    Folgende Zeilen geändert:


    3080 POKE PS(Z),32:POKE PS(Z)-1,178:POKE $D000+PS(Z)-1,F%(2):PS(Z)=PS(Z)-1:F=1


    3410 POKE PS(Z),32:POKE PS(Z)+1,178:POKE $D000+PS(Z)+1,F%(2):PS(Z)=PS(Z)+1:F=1


    3710 POKE PD(D),32:POKE PD(D)-1,144:POKE $D000+PD(D)-1,F%(6):PD(D)=PD(D)-1:DF=1


    3860 POKE PD(D),32:POKEPD(D)+1,144:POKE $D000+PD(D)+1,F%(6):PD(D)=PD(D)+1:DF=1

  • Genau.


    8530 : POKE $D800-$0800+E0+YY*40+XX,F%(OF)


    In der Variablen E0 ist das Offset für den Bildschirmspeicher, also $0800 enthalten. Damit wurden die Farben an die Adresse ab $E000 geschrieben.

    Na, auf diese Idee kam ich auch schon. Aber wenn ich das auf $d000 stelle, werden die Diamanten mit schwarz gezeichnet.


    Aber liegt der Farbram nicht bei $d800 ? :roll:


    Zumal die Explosion mit Rockfort bei $d800 funktioniert. :nixwiss:

  • So viele POKEs! :cry:

  • Danke, werde ich einbauen

  • Ist alles halb so schlimm. Das bezieht sich ja nur auf den Screen und den Farbram. :D

  • Der Punkt ist, dass in E0 die Position des Objekts enthalten ist, z.B. bei $08FF würde die Farbe an $E0FF ($D800+$08FF) geschrieben.


    Das Schwarz kommt wohl daher da in der Variablen F%(OF) nur 0-Werte enthalten waren.


    Testen kannst du das, wenn du in 8530 statt F%(OF) mal eine 1 einträgst.

  • OK, habs getestet, läuft jetzt mit den Farben. Warum das vor nicht ging :oob:

    :zeig: Na weist du das immer noch nicht. Immer daran denken, die größte Fehlerquelle sitzt vor der Tastatur.


    Ok habs herrausgefunden warum die Diamanten schwarz waren. Ich habe den falschen Farbindex genommen. :schande:


    Und hier eine fertig PRG Datei zum testen.

    Wenn ihr mit ein anderen Level anfangen wollt, einfach in der Zeile 235 LV=4, den Wert änderen. Immoment habe ich 4 Levels.

    Sobald der Butterfly sich bewegt, melde ich mich wieder.

    BD-Mega65-Basic.prg

  • Hier mal ein kurzes Erkenntnis über Variabeln mit %


    Als mir Acron die Routine des Levelaufbau von Boulder Dash I gegeben hat, hat er jede Variabel mit ein % versehen.

    Ich fands gut, weil in meinen Hinterkopf noch gespeichert war das Variabeln mit % schneller bearbeitet werden.

    Jetzt gabe es aber ihr und dort ein paar Meinungen das das nicht ganz stimmen würde, jetzt bezogen auf den Mega65.

    TheRealWanderer hat mir geschrieben

    Quote

    1. Verwende keine Variablen mit %. Diese sind rund 9% langsamer als Variablen ohne % (auch wenn es bei Integer eigentlich schneller sein sollte). Wenn % Variablen bei Arrays benutzt werden, macht es nur rd. 5% aus.

    Also habe ich mir die Mühe gemacht alle Variabeln mit % aus dem Programm zu entfernen. (Notepad++ war das sehr hilfreich ^^)

    Jetzt war ich richtig gespannt wie schnell der Levelaufaufbau wird.

    Das Ergebnis hat mit direkt umgehauen.

    Denn das Level war jetzt anderes eingeteilt. :emojiSmiley-33:


    Vermutlich ist das Ergenis mit und ohne % anders.

    OK das ist ein kleiner Dämpfer, jetzt sind halt Level anders als von orginal BD I.

    OK ist den der Aufbau schneller. Hier zwei Bilder


    das erste Bild sind die Variabeln ohne %


    das zweite Bild sind die Variabeln mit %


    Da der Aufbau jetzt keinen so großen Unterschied macht in Sachen Geschwindigkeit, werde ich nur da die Variabel mit % versehen wo die Berechnung des Pseudo Zufall statt findet.

    So habe wir dann auch die Levels gleich im Bezug zu BD I.

    So das war es mal wieder. Diesmal keinen Code. Beim nächsten mal wieder.


    Snoopy vielleicht kannst du das auch mal checken wenn du Lust hast. Viellcht liege ich auch falsch damit

    Dann hier der Code einmal Variabeln mit % und einmal ohne.

    BD-in Basic -Variabeln ohne %.prg

    BD-in Basic - Variabeln mit %.prg

  • Also habe ich mir die Mühe gemacht alle Variabeln mit % aus dem Programm zu entfernen. (Notepad++ war das sehr hilfreich ^^ )

    Nur mal als Tipp, falls du sowas nochmal vorhast:


    In BASIC 65 kannst du das mit CHANGE "%" TO "" erledigen lassen.



    Entweder die erste Anfrage mit * und RETURN bestätigen, dann werden alle % zu "" ("Nichts") geändert.


    Oder jeweils einzeln mit Y und RETURN bzw. N und RETURN bestätigen, wenn du mitkontrollieren willst.


  • Ich schreibe einfach mal alles auf, was mir beim Durchsehen so auffällt. Ist nicht böse gemeint, das ist einfach als - hoffentlich - hilfreiches Feedback gedacht. ;)


    Mit deinen Variablennamen wirst du früher oder später Probleme bekommen. In alter Commodore-Tradition werden auch in BASIC 65 intern nur die ersten beiden Zeichen beim Variablenname unterschieden.


    Deine B10, B11, B12 und B13 haben nach Zeile 140 den gleichen Wert, nämlich den zuletzt an B1 zugewiesen Wert 183.



    Da solltest du genau darauf achten, dass sich immer die ersten beiden Zeichen der Variablen eindeutig unterscheiden, sonst kann es "unerwarte" Effekte geben und du suchst dir dann mitunter einen Wolf, bis du den Fehler gefunden hast. ;)

  • Was ein Problem sein kann: Nachdem du die % entfernt hast, kommen sich deswegen Variabeln in die Quere.


    Du hast z.B. eine Variable F und eine F% (beim READ der Daten). Und im Programm nach dem Entfernen der % sind diese beide identisch F und können nicht mehr vom Programm als zwei verschiedene Variablen gesehen werden.


    Das musst du nach dem Ändern am besten nochmal genau durchgehen, dass sich die Variablen auch weiterhin unterscheiden.



    So, ich lege mich jetzt erstmal ins Bett. Morgen ist auch noch ein Tag! :)

  • Das Programm mit den Variablentype REAL funktioniert nur wegen dieser Zeile nicht mehr korrekt.


    51145 PA=PA+P2/2:IF PA>255 THEN PA=PA AND 255


    Und damit es wieder richtig läuft.


    51145 PA=PA+P2/2AND255:IF PA>255 THEN PA=PA AND 255


    Verwende mal für P1 und P2 den Type BYTE.

  • das zweite Bild sind die Variabeln mit %

    Ich frag zur Sicherheit mal nach: :)


    Das Bild ist vom richtigen Aufbau des Levels?

    Ja


    Wow das wusste ich gar nicht, Klasse Befehl


    Das fliegt später wieder raus, Ist für mich nur eine Gedakenstütze. Nein über konstruktive Kritik bin ich immer froh. Denn ich habe die Weisheit auch nicht mit Löffeln gegessen.

    Ok werde ich mir genauer mal anschauen.

    Oh Super das werde ich heute Abend gleich abänderen. :thumbsup:

    Wie sage TheRealWanderer, wir brauchen nachher alles an Optimierung was geht.

    Super Danke euch beiden:thumbsup:

  • Wie sage TheRealWanderer, wir brauchen nachher alles an Optimierung was geht.

    Eine große Bremse beim Erzeugen der Level ist das Auswerten, welche Farbe bei Zeichen X benötigt wird. Leider sind solche IF THEN Geschichten von ein gewissen D. immer Gift für Basic, da diese viel zu viel Zeit kosten. Das Berechnen der Pseudo-Werte kostet ebenfalls sehr viel Zeit, weil hier jeder Überlauf nachgebildet werden muss.

    Und wieder ist hier IF THEN der Übeltäter, der das ganze deutlich ausbremst. Dabei wäre gar kein IF THEN nötig, wenn man den Variablentyp Byte verwenden könnte, da dieser beim Überlauf kein ?ILLEGAL QUANTITY ERROR erzeugt. Leider gibt es keine Möglichkeit so einen Überlauf abzufragen und damit bleibt nur der Umweg.

    Aber ein IF THEN kann man ersetzen, und zwar durch FOR A%=0 TO 799 : NEXT, das ist auch merklich schneller. Als letztes bleiben die hohen Zeilennummern, die bremsen ebenfalls etwas. Dann habe ich noch das Binäre schieben gefunden, leider ist das kaum schneller als IF THEN, weil man mit A&=A&<<7 verschieben muss.

    Ein rollen von A&=A&>>2 wäre bestimmt schneller gewesen, das wird aber nicht angeboten.


    Für den Schleim (Glibber) aus Boulder Dash II, wird ebenfalls die Pseudo-Routine benötigt. Deshalb habe ich auch im Programm Leveldaten die Routine angepasst, da der Schleim mit den zuletzt erzeugten Werten weiter rechnet. Ich verwende immer noch Integer und Byte, da der Typ Real zur Zeit mit vielen Konstanten der Haupt-Routine belegt ist.

    Das Programm vom C64 läuft jetzt auf dem Mega65, dafür musste ich nur die Adresse vom Bildschirmspeicher auf 2048 setzen. Zusätzlich habe ich die schöne Kino-Grafik (online Textkorrektur) von Drachen geklaut, teilweise aber mit andere Farben für die Zeichen versehen.


    Genug der Worte, es ist etwas schneller aber nicht viel hust hust.