Puzzle 005

Für diesen Beitrag wurde das CBM prg Studio verwendet.
weitersagen ...
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

CBM prg StudioDen Hintergrund bewegen

Eben haben wir unser Puzzle so geändert, dass wir die Sprites über Tabellen positionieren, aber der Hintergrund des jeweiligen Puzzleteils bliebt unverändert. Das sollten wir jetzt schleunigst ändern.

Wir wollen einfach die Quarate für den Spritehintergrund abhängig von unserer Tabelle  tileorder:, in der ja die Puzzleteile für das jeweilige Feld zufinden sind, zeichnen. Um jetzt die Teile in das jeweilige Feld zu zeichnen, benötigen wir natürlich deren Position. Werfen wir dazu noch mal einen Blick auf unser Spielfeld im Screen Editor:

Die Startpositionen der Puzzlehintergründe
Die Startpositionen der Puzzlehintergründe

Der Grafik könnt ihr nun entnehmen, wo (Zeile & Spalte) jeweils die obere/linke Ecke eines Feldes liegt. Dass hier alles Symetrisch ist, ist reiner Zufall (bzw. meinem Symetrie-Wahn geschuldet). Wir werden nun wieder die Tabelle  tileorder:  von hinten nach vorne abklappern. Dadurch beginnen wir im 9. Feld, setzen dann die 5*5 Zeichen und kommen dann zu Feld 8. Ich habe bewußt auf jegliche Optimierung verzichtet und hoffe das ich euch nun im Source das genaue Vorgehen erklären kann. Die obige Grafik werde ich für meine Ausführungen gleich noch häufiger bemühen.
 

Fügt die Routine am Besten hinter dem rts von spritessetposition:  ein.
Achtung: Durch eine Änderung ab Version 2.8.0 des CBM prg Studios ist es möglich in den Optionen festzulegen, wie  lda #<SCREENRAMADR+$267 ausgewertet werden soll! Fügt daher zur Sicherheit die Direktive  Operator Calc ;wird erst ab CBM prg Studio 2.8.0 benötigt! am Anfang des Quellcodes ein!

Hinter tiledraw:  beginnen wir zunächst damit die Adresse der linken oberen Ecke des neunten Feldes zu ermitteln und auf der Zero-Page zu speichern. Die Variablen sollten euch aus der Funktion drawscreen: bekannt vorkommen. Um die Adresse zu berechnen, werft noch mal einen Blick auf die Grafik. Wie ihr seht, beginnt das 9. Feld in der 16. Zeile, also müssen wir 15 komplette Zeilen, zu je 40 Zeichen (15 * 40 = 600 Zeichen / BYTES) überspringen. Danach stehen wir auf dem ersten Zeichen, der 16. Zeile. Da das Feld in der 16. Spalte beginnt, müssen wir noch 15 weitere BYTES überspringen (denkt dran, wir standen bereits auf dem 1. Feld), somit landen wir also bei 600 + 15 = 615 oder $267. Da wir auch die Farbe setzten müssen addieren wir nicht nur zur Startadresse des Bildschimspeichers, sondern auch zu der des COLOR-RAM unsere eben errechneten $267 BYTES.

Zunächst benötigen wir eine neue Konstante ZP_LOOPHELPER, die wir für alle möglichen Schleifen-Operationen verwenden können. Für eine etwas bessere Performance verwenden wir die Zero-Page, wir reservieren uns mal die nächsten 8-BYTES ab der Adresse, auf die die Konstante verweist, sprich die letzten acht BYTES der Zero-Page.

Also einfach die Konstante oben hinzufügen:

 

Als nächstes laden wir unsere Schleifenvariable für die Felder (X-Register), da wir das X-Register aber gleich für etwas Anderes benötigen, sichern wir es hinter dem ‚cheap label‚  @loop: erstmal auf dem Stack. Im Y-Register wollen wir uns die Farbe für das jeweilige Puzzleteil merken, wir gehen zu Beginn von grau für die ungeraden Puzzleteile aus. Dann holen wir uns das Teil, dass auf dem letzten Feld liegt (wir schauen uns ja gerade den ersten Durchlauf der Schleife an und beginnen beim letzten Feld) in den Akku. Ist der Wert negativ, handelt es sich um das leere Feld und wir springen zu @skip:. Dort laden wir das Zeichen für das ‚karrierte‚ Feld in den Akku und die Farbe dunkelgrau ins Y-Register. Ist der Wert nicht negativ, dann prüfen wir, ob es sich um ein ‚gerades‚ oder ‚ungerades‚ Puzzleteil handelt. Ist es ungerade springen wir direkt zu @skip1:, ist es gerade, ändern wir die Farbe im Y-Register auf hellgrau und landen dann auch bei @skip1:. Hier wird nun das invertiert Leerzeichen in den Akku geladen und wir springen zu @skip2:. Dort haben wir im Akku also unser Zeichen und im Y-Register die Farbe für das Puzzleteil. Da wir die beiden Register brauchen, speichern wir deren Werte auf der Zero-Page und beginnen mit dem Zeichnen.

Da wir unser X-Register für die Hauptschleife auf dem Stack gesichert haben, können wir es jetzt für eine weitere Schleife benutzten. Wir legen in X die Anzahl der Zeilen und im Y-Register die Anzahl der Zeichen je Zeile ab. Da unsere Puzzleteile 5×5 Zeichen groß sind, schreiben wir also jeweils eine 4 (wir prüfen mit bpl) ins Register. Dann holen wir das Zeichen in den Akku und schreiben es per Y-nach-indizierter Adressierung in den Bildschirmspeicher, das Gleiche machen wir danach mit der Farbe und dem COLOR-RAM. Dann verringern wir das Y-Register und vervollständigen die Zeile.

Sobald die Y-Schleife abgearbeitet wurde, haben wir die erste Zeile von rechts nach links gezeichnet. Jetzt müssen in der darunterliegenden Zeile 17 weitermachen. Dazu ist es wichtig, dass ihr euch erinnert, dass wir bei ZP_SCREENRAMADR die Adresse der linken oberen Ecke des 9. Feldes gespeichert haben ($0400 + $267).

Wir addieren jetzt auf das LSB unsere Adresse in  ZP_SCREENRAMADR die 40 Zeichen, für eine ganze Zeile. Wenn das Carry-Flag gelöscht ist, springen wir weiter, sonst  erhöhen wir das MSB um eins.

Auch beim Farb-RAM addieren wir 40. Zum Schluß verringern wir das X-Register, in dem wir hier ja unsere Zeilen zählen und zeichnen noch die nächsten vier Zeilen.

Jetzt ist ein komplettes Feld fertig, wir müssen also zum Beginn des nächsten wechseln. Wenn wir z. B. gerade das 9. Feld gezeichnet haben, dann befinden wir uns nun in der 21. Zeile (nach jeder Zeile haben wir 40 addiert) und in Spalte 16 (die Zeichen für eine Zeile werden absteigend von rechts nach links ausgegeben). Wir müssen nun also fünf Zeilen nach oben und dann noch 5 Zeichen nach links (also 5 * 40 + 5 = 205 BYTES abziehen)…

…und genau das hat dieser Abschnitt für den Bildschirmspeicher und das Farb-RAM gemacht.

 

Jetzt holen wir unseren Zähler für die Felder wieder vom Stack (s. oben) und kontrollieren dann, ob wir alle drei Felder in der unteren oder mittleren Reihe gezeichnet haben. Sollte dass der Fall sein, dann müssen wir zum Beginn des 6. oder 3. Feldes (s. Grafik ganz oben) springen. Zum Schluß zählen wir die Feld-Nr. im X-Register herunter und beginnen wieder weiter oben mit dem nächsten Feld oder sind fertig und verlassen die Routine.

Solltet ihr euch jetzt fragen, warum @rowup:  hinter dem  rts  folgt, dann könnt ihr den Block ja gerne mal vors @skip7:  verschieben und euch ggf. nochmal die Branch-Befehle anschauen.

 

Haben wir z. B. die untere Reihe (Feld 9, 8 und 7) vollständig gezeichnet, dann befinden wir uns in Zeile 16 in der ersten Spalte. Wie ihr euch erinnert, haben wir nach jedem Feld den Beginn des links davon liegenden berechnet, das wurde auch nach Feld 7 gemacht und wir sind dann im ‚Niemandsland‚ gelandet. Um jetzt zur linken oberen Ecke von Feld 6 zu gelangen müssen wir vier ganze Zeilen und 25 Zeichen, also (4 * 40 + 25 = 185 BYTES)  abziehen. Das machen wir natürlich, wie jedesmal, für den Bildschirmspeicher und das Farb-RAM. Von hier müssen wir fürs nächste Feld per jmp @skip7:  zurück zur Hauptroutine springen.

Damit wir die Tiles auch sehen, fehlt natürlich noch der Aufruf von tiledraw:. Fügt in die Funktion loadnextsprite: direkt hinter jsr spritesetposition: die folgende Zeile ein:

 

Damit wäre dies auch erledigt. Wer nun fürchtet, dass das alles zu langsam ist, es sieht ja schließlich sehr aufwendig aus, den kann ich beruhigen: Es mag nicht sonderlich schnell sein, für diesen Zweck ist es aber mehr als ausreichend. Wer sich das Projekt herunterlädt, der findet im Source sogar eine Funktion slowdown:, mit der ihr die Ausgabe verlangsamen könnt, damit ihr nochmal genau seht, wie die Felder gezeichnet werden. Das Innenleben der Routine ist außer dem  rts auskommentiert, ihr müsst also nur den Rest wieder aktivieren und das Programm starten oder vom Diskettenimage „LOVE SLOW„ laden.

Da wir die Felder jetzt selbst zeichnen, habe ich sie aus unserem Bildschirm-Entwurf im Screen Designer (puzzle.sdd) wieder gelöscht.

 


Da sind wir auch schon wieder am Ende angelangt, als nächstes sollten wir das Puzzle endlich mal vom Programm automatisch ‚durchwürfeln‚ lassen.

 

 

Start im Java Emulator: normale oder ‘slow‚ Version

 


Schrott!!Naja...Geht so...Ganz gut...SUPER! (4 Bewertungen | Ø 5,00 von 5 | 100,00%)

Loading...


 

<<< zurück | weiter >>>

 

weitersagen ...
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

5 Gedanken zu „Puzzle 005“

  1. Der Build in dieser Phase geht schon wieder nicht mehr im CBM Prg Studio 3.0. Sachen wie „lda #<SCREENRAMADR+$267" werden als invalid operand angezeigt, und die cheap labels funktionieren hier auch nicht mehr.
    Ich dachte ursprünglich es läge an meinem Code, jedoch bekomme ich mit deiner Datei genau die selben fehler wenn ich einen Build machen will.

    1. Es macht die Sache zwar nicht besser, aber es ist kein Problem von 3.0.0.

      Die beschriebenen Fehler gehen auf Umstellungen zurück, die ab Version 2.8.0 Einzug ins CBM prg Studio hielten.
      Das meiste habe ich damals überarbeitet, aber anscheinend nicht alles. Sorry!

      Damit du schnell weiter kommst…
      Um das ‚lda #>SCREENRAMADR+$267‚-Problem zu beheben füge einfach die Zeile ‚Operator Calc‚ am Programmbeginn ein.

      Die Sichtbarkeit der Cheap-Label wurde ab 2.8.0 geändert. Daher führt

      @loop:
      ...
      beq neuesLabel:
      ...
      neuesLabel:
      ...
      bne @loop:

      zu einem Fehler. Cheap-Label sind nur bis zum nächsten ’normalen‘ Label sichtbar. Du kannst also einfach aus neuesLabel: ein CheapLabel @neuesLabel: machen.

      Auch hier ist es wieder interessant, wie viele die Seite in der Zwischenzeit gelesen und das ZIP heruntergeladen haben, ohne etwas zu sagen.
      Daher vielen Dank für die Rückmeldung! Ich schaue es mir demnächst nochmal an und korrigiere die entsprechenden Passagen und Downloads.

        1. Gern geschehen, die Beispiele sollen ja funktionieren, sonst macht das alles keinen Sinn.

          Ich habe jetzt auch den Rest des Puzzles überarbeitet (es betraf nur noch die Downloads).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Protected by WP Anti Spam