Landung 008

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 StudioWo ist die Tankstelle?

Heute geht es darum den Spritverbrauch hinzuzufügen. Jede Verwendung der Schubdüsen wird unsere Treibstoffreserve verringern. Sollte alles aufgebraucht sein, dann stürzt das Landungsschiff unweigerlich ab.

Bitte ggf. den Sourcecode aus dem letzten Beitrag herunterladen.

 

Wie darstellen?
Bisher war der Verbrauch als Text vorgesehen.  Ich möchte jetzt aber die Darstellung lieber als Balken am rechten Rand vornehmen. Diesmal allerdings nicht mit dem Zeichensatz, wie beim Zeitbalken fürs Puzzle, sondern mit Sprites. Immerhin haben wir noch drei unbenutzte Sprites zur Verfügung. Daher wurde der bisherige Text für den Verbrauch in  lander_canyon.sdd entfernt.

Zunächst habe ich die drei neuen Sprites im Sprite-Editor mit den Nr. 6, 7 und 8 ‚entworfen‚. Das Aussehen ist euch freigestellt, ihr solltet nur beachten, dass wir die volle Höhe von drei Sprites, also 63 Zeilen als gesamten Treibstoffvorrat betrachten. Das folgende Bild stellt einen Auszug des Scratchpads dar. Ihr erkennt die neuen Sprites und wie sie gleich zusammengefügt aussehen werden.

Die Treibstoffanzeige
Die Treibstoffanzeige

Damit die neuen Sprites bei der Programmerstellung überhaupt geladen werden und wir gleich unsere Treibstoffanzeige auf den Bildschirm bringen können, passt die  incbin-Anweisung beim Label sprite_Spaceship: bitte folgendermaßen an:
incbin "lander.spt",1,8,true, wir benötigen jetzt schließlich 8 statt 5 Sprites.

Fügt direkt dahinter noch die folgenden Anweisungen hinzu:

Wir werden den Treibstoffverbrauch durch das Löschen von Spritezeilen realisieren. Da wir aber für einen neuen Versuch, wieder die kompletten Sprites benötigen, kopieren wir gleich unsere Spritedaten hinter das Label sprite_Fuel:. Dort können wir die Daten dann problemlos löschen und bei Bedarf einfach unsere Musterdaten erneut kopieren. Natürlich würde auch eine BYTES $00*192-Anweisung reichen, aber so ist es leichter vorstellbar, wo welches Sprite landet. Das Label sprite_Fuel: befindet sich bereits durch die vorherigen Anweisungen an einer 64-Byte-Grenze, wir benötigen daher kein zusätzliches align.

Da wir gerade in der Nähe sind, fügt doch noch zwei neue Variablen (z. B. hinter Alive:) hinzu:

FuelCounter: steuert die Geschwindigkeit, mit der der Treibstoff verbraucht wird. In FuelClear: finden wir das nächste BYTE, dass gelöscht werden soll. Außerdem hilft es uns zu erkennen, wann der Treibstoff aufgebraucht ist.

Um unsere Treibstoffanzeige erstmal auf den Bildschirm zu bekommen, sollten wir jetzt die dazu gehörigen Sprites entsprechend einrichten. Dies machen wir in der Funktion init_sprites:, die  Änderungen sind farblich hervorgehoben.

Hier ist alles ‚alter Kaffee‚. Evtl. irritiert die Berechnung der Spritepointer den einen oder anderen. Mit der Zeile  ldx #sprite_Fuel:/64 berechnen wir direkt im Assembler die Nummer für unsere 64-BYTE-Blöcke. Wenn ihr möchtet, dann könnt ihr auch den kompletten Beginn der Funktion durch ein einfaches ldx #sprite_Spaceship:/64 ersetzen. Diese Art der Berechnung klappt, da wir den Grafikspeicher im ersten 16KB-Block belassen haben. Die restlichen Anweisungen setzen nur die Spritepointer, die Positionen und Farben, verdoppeln die Breite und Höhe und schalten die Sprites sichtbar.

Falls ihr das Programm nun starten wollt, denkt dran, dass die Sprites noch nicht kopiert wurden. Wir würden also nichts sehen. Daher schnell mal eine Kopierfunktion gebastelt. Ich habe diese vor checkCollision: eingefügt.

Wir setzen zu Beginn die Nr. für das nächste BYTE, dass gelöscht werden soll, auf 0. Dann initialisieren wir den Zähler für den Treibstoffverbrauch mit der neuen Konstanten FUELCOUNTINIT. Anschließend wird das X-Register als Schleifenzähler mit der Anzahl der zu kopierenden BYTEs gefüllt. Die drei Sprites haben je 21 Zeilen zu 3 BYTEs zzgl. einem Füll-BYTE, wir kommen also auf (21 * 3 + 1) * 3 = 192 ($C0) BYTEs. Bei @loop: kopieren wir dann die BYTEs. Die Quelle ergibt sich aus der Adresse sprite_spaceship:, da hat der Assembler unsere Sprites abgelegt, zzgl. 320 ($140) BYTEs, da wir die fünf Sprites für das Landungsschiff überspringen müssen. Wie ihr seht wird aber nur $13F addiert. Dass liegt daran, dass wir die X-indizierte-Adressierung verwenden, X hier aber nie 0 ist. Um wirklich alle BYTEs zu kopieren, verringern wir die Adressen von Quelle und Ziel einfach um 1.

Legt nun hinter  THRUST_Y die neue Konstante an FUELCOUNTINIT = $08 ;Warteschleife für Spritverbrauch.

Aufrufen müssen wir die eben erstellte Funktion natürlich auch noch, dass machen wir in init_lander: direkt hinter der Zeile jsr init_sprites: ;Sprites initialisieren mit einem weiteren Sprung jsr init_fuel: ;Treibstoffreserve zurücksetzen.

Nun ist es soweit, wir können das Programm zum Test einmal starten…

Die Treibstoffreserve wird angezeigt.
Die Treibstoffreserve wird angezeigt.

Da ist sie endlich, die riesen große 😉 Treibstoffanzeige. Natürlich geschieht noch nichts, wir müssen als nächstes dafür sorgen, dass der Treibstoff auch tatsächlich verbraucht wird. Dazu begeben wir uns in die Funktion checkinput:. Jedesmal wenn wir die Düsen anzeigen, werden wir den Treibstoffzähler FuelCounter: um eins verringern. Fügt dazu hinter jeder der drei bcc-Anweisungen die Zeile dec FuelCounter: ;Treibstoffzähler verringernein. Dadurch erreichen wir, dass der Verbrauch mit jeder aktivierten Schubdüse zunimmt.

Um jetzt den Verbrauch sichtbar zu machen, wollen wir jedes Mal, wenn FuelCounter: kleiner als Null ist, eine Zeile in der Treibstoffanzeige entfernen. Dies machen wir einfach in unserer Hauptschleife. Sucht also das Label  gameloop: und fügt die folgenden Zeilen direkt dahinter ein:

Gleich als Erstes holen wir FuelCounter: in den Akku und kontrollieren, ob dieser noch positiv ist, falls ja geht es direkt bei der Kollisions-Prüfung (nun hinter @skip:) weiter. Ist er aber negativ, dann müssen wir tätig werden. Wir sollten den Counter zurücksetzen, dazu addieren wir die Konstante FUELCOUNTINIT einfach zum Akku und speichern das Ergebnis wieder bei FuelCounter:. Um dann eine Zeile im Sprite zu löschen, füllen wir den Akku mit 0 und holen uns das zulöschende BYTE aus FuelClear: ins X-Register. Wir speichern als nächstes den Akku-Inhalt einfach an der Startadresse, der von uns kopierten Sprites zzgl. dem X-Register.  X wird anschließend um eins erhöht. Dies wiederholen wir noch zwei mal und speichern zum Schluß den Wert des X-Registers wieder bei FuelClear:.

Probiert ihr das Programm jetzt, dann sieht zunächst alles gut aus, aber erreicht ihr beim Verbrauch den gelben Abschnitt wird ein Versatz sichtbar.

Das sieht noch unschön aus...
Das sieht noch unschön aus…

Der Grund ist recht simpel, wir löschen das Sprite zeilenweise, aber ein Sprite hat nur 63 BYTEs. Wir müssen das Füll-BYTE beachten. Also passt die obige Funktion zwischen dem letzten  inx und dem  stx FuelClear: ;nächstes zulöschendes BYTE merken  noch etwas an:

Wir kopieren das X-Register in den Akku und kontrollieren einfach, ob bereits 63 BYTEs kopiert wurden. Falls ja erhöhen wir X nochmal um 1, bevor wir den Wert bei @skip2: speichern.

Jetzt sollte der Verbrauch ohne Umbruch angezeigt werden. Eine letzte Kleinigkeit fehlt aber noch, wenn der gesamte Treibstoff aufgebraucht ist, dann wollen wir die Steuerung unterbinden. Dies können wir durch drei kleine Zeilen in checkinput: erreichen. Fügt diese hinter dem tax am Funktionsbeginn ein.

Wir kontrollieren einfach ob bereits alle Zeilen der Treibstoffanzeige gelöscht wurden. Dass ist der Fall, wenn FuelClear: 192 oder größer ist. Sobald diese Grenze überschritten wurde springen wir einfach noch noFire:. Dies hat zur Folge, dass keine Joystickabfrage mehr stattfindet und das Schiff gnadenlos von der Gravitation ins Verderben gezogen wird.
Wobei es nicht ganz stimmt. Kommt der Spieler mit dem letzten Tropfen zur Landezone, dann kann immer noch eine saubere Landung gelingen. Er darf nur nicht zu schnell aufsetzen.

Jetzt könnt ihr euch an der Landung versuchen. Über  FUELCOUNTINIT beeinflusst ihr die Geschwindigkeit des Treibstoffverbrauchs und somit ebenfalls den Schwierigkeitsgrad. Mit meinen beschränkten Fähigkeiten empfinde ich den von mir verwendeten Wert 8 schon ziemlich hart.

Das fertige Ergebnis
Das Endergebnis

Wieder eine Etappe geschafft. ‚Level 2 – Die Landung‚ nähert sich nun langsam seinem Ende. Die spielerischen Herausforderungen wurden alle implementiert. Jetzt fehlt nur noch etwas ‚Kosmetik‚.

Das eben erstellte Programm läßt sich im Java-Emulator starten und den Source könnt ihr euch, wie gewohnt, über das Disketten-Symbol herunterladen.



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

Loading...


 

<<< zurück | weiter >>>

 

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

3 Gedanken zu „Landung 008“

  1. Wir werden leider auf ein Update von Arthur warten bis wir hiermit weitermachen können, da es manchmal reicht nur ein Zeichen zu ersetzen, und schon meldet CMB Prg Studio lauter invalid branches (zB beq doRasterIRQ_Laser: und beq doRasterIRQ_Laser1:), zB schon nur wenn man die Konstante FUELCOUNTINIT von $08 in $0F umwandelt.
    Die Cheap Labels scheint er nicht zu vertragen. 🙁
    Ps.: die gleichen Fehler erscheinen auch mit deiner Source Datei wenn man etwas editieren möchte.

    1. Hallo,
      auf erste Probleme mit den Cheap-Label bin ich am 27.05.14 schon mal eingegangen -> ‚CBM prg Studio 3.0.0: Probleme‚.
      Ich stehe heute schon den ganzen Tag mit Arthur in Kontakt und hoffe es wird in Kürze ein Update geben. Ich hatte auch auf eine zügigere Behebung gehofft, aber Arthur braucht auch eine kleine Auszeit.

      Mit der aktuellen Beta 3.1 kann ich jedenfalls FUELCOUNTINIT ändern, ohne dass es zu Problemen kommt.

Schreibe einen Kommentar


Beachtet bitte, dass ich eure Kommentare erst manuell freigegeben muß, bevor sie auf der Seite erscheinen! Da ich nicht pausenlos am Rechner sitze, kann es schon mal etwas dauern, bis ein Kommentar für alle sichtbar ist.

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

Protected by WP Anti Spam