Landung 009

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 StudioEinen Sound abspielen und dann nichts wie raus

So, nun sind wir fast am Ende des zweiten Levels angelangt. Im abschließenden Beitrag wollen wir jetzt noch das Programm etwas aufpolieren. Um es wirklich ‚hübsch‚ zu machen, fehlt uns zwar noch einiges an Wissen, aber mit zwei kleinen Änderungen möchte ich mal zeigen, wo der Weg hinführen kann. Wie in ‚L.O.V.E. – Die Planung‚ unter Punkt 7 erwähnt, sollten / müssen wir ganz zum Schluß das komplette Projekt nochmal überarbeiten, um ein professionelles Ergebnis zu erhalten.

 

Sound für die Schubdüsen
Auch wenn ich immer noch nicht auf die Soundprogrammierung eingegangen bin, laßt uns, wie beim Puzzle, zumindest für ein Geräusch sorgen. Es wäre doch schön, wenn die Düsen auch hörbar sind. Da Rauschen dafür nahezu perfekt geeignet ist, baut doch diese neue Funktion ins Programm ein, z. B. vor init_Fuel:. Verwendet ggf. den Download aus dem letzten Beitrag als Ausgangspunkt.

Diese Routine entspricht eigentlich der, aus dem Puzzle. Wir setzen diesmal nur Sustain und Release, sowie die Lautstärke aufs Maximum. Der Rest bleibt unverändert. Jetzt müssen wir unseren Soundeffekt natürlich noch starten und beenden. Dies machen wir zunächst einfach in der Funktion checkinput:.

Ändert das Programm ab  checkinput_exit: wie folgt:

Wir holen uns hier die aktiven Sprites in den Akku und prüfen, ob eine der Düsen ‚unter Feuer steht‚. Ist das der Fall, dann springen wir nach thrustSound: um den Soundeffekt zu starten. Falls keine Düse aktiv ist, setzen wir bei @skip: die Lautstärke einfach auf 0. Da es sonst keine Effekte oder Musik gibt, können wir das einfach so machen.

Startet ihr das Spiel nun, dann vernehmt ihr hoffentlich ein wohliges Rauschen, sobald die Düsen sichtbar sind. Ein Problem fällt euch wahrscheinlich spätestens beim Ableben oder einer Landung auf. Der Sound bleibt bestehen! Daher sollten wir den, bei der Landung und beim ‚Gameover‚ noch abschalten.

Fügt dazu direkt hinter ;sonst -> gelandet die Zeilen

ein, um den Ton abzuschalten (wir setzen hier einfach wieder die Lautstärke auf 0).

Bei gameover: werden bereits die Sprites abgeschaltet, fügt hinter sta VICSPRITEACTIVE ;Sprites abschalten noch die Zeile sta SID_VOLUME ;Lautstärke auf 0 setzen ein.

Jetzt endet unser Düsensound auch bei einer Landung oder wenn wir scheitern.

 

Den Canyon verlassen
Da der Spieler in unserem nächstem Level ‚Die Fahrt zur Basis‚ eben genau dass machen muss – zur Basis fahren. Schaffen wir noch eine passende Überleitung, in dem wir nach der erfolgreichen Landung zeigen, wie das Fahrzeug den Canyon verläßt.

Also habe ich als 9. Sprite in ‚lander.spt‚ eine kleine Version des Space-Rovers entworfen.

Der 'Space-Rover'
Der ‚Space-Rover‚

 

Damit es nicht so aussieht, als sei der Space-Rover aus dem Landungsschiff gezaubert worden, habe ich noch ein 10. Sprite vorbereitet, dass die geöffnete Luke des Schiffes darstellen soll.

Die offene Luke.
Die offene Luke.

 

Um diese Sprites nun ins Programm einzubauen, müssen wir natürlich als erstes wieder den Assembler anweisen die neuen Sprites zu laden. Ändert dazu, ziemlich am Ende des Sourcecodes, das incbin für die Sprites in incbin "lander.spt",1,10,true.

Wir machen es uns nun auch wieder ganz einfach. Begebt euch zum gameloop: und führt die folgenden Änderungen direkt vor der Zeile lda #COLOR_LIGHTGREEN ;mit grün anzeigen, dass alles gut ist durch.

Außer dem Landungsschiff sind alle Sprites deaktiviert. Für unsere Schlußsequenz benötigten wir noch neue Spritefarben. Daher setzen wir die Farben für den Space-Rover (dieser wird gleich Sprite-0) und für die offene Luke (wird Sprite-1). Solltet ihr euch jetzt fragen, warum wir die offene Luke nicht, wie die bisher geschlossene, als Sprite-0 und den Rover als ‚1‚ anlegen, dann schaut euch nochmal an wie die Sprites gezeichnet werden. Wir wollen es ja ‚hübsch‚ machen ;-).

Jetzt müssen wir die entsprechende Nummer des 64-BYTE-Blocks für den VIC berechnen. Das könnten wir mit entsprechenden Befehlen zur Laufzeit machen oder wir weisen den Assember an, die Werte direkt bei der Erstellung zu ermitteln. Der Vorteil (weniger Speicher, schnellere Ausführung) ist hier zwar vollkommen egal, aber ich möchte es dennoch vom Assembler erledigen lassen. Um die Nr. des 64-BYTE-Blocks zu ermitteln, müssen wir eigentlich nur die Startadresse der Spritedaten sprite_spaceship: durch 64 teilen (wir verwenden ja den ersten 16KB-Block für den VIC) und dann die laufende Nr. des gewünschten Sprites minus 1 addieren (für den Rover also 9 – 1).

Probiert ihr jetzt etwas wie

dann springt euch beim CBM prg Studio die folgende Fehlermeldung an!!!

 

Das Problem ist, dass der Assembler des CBM prg Studios (wie schon an anderer Stelle erwähnt) nur einen Operator je Zeile erlaubt!
Daher gibt es auch keine Klammern, wozu auch, wenn nur ein Operator möglich ist. Andere Assembler (z. B. ACME oder der vom C64-Studio von Georg Rottensteiner) kommen dagegen mit komplexen Berechnungen klar. Leider plant Arthur bisher nicht, dies auch im CBM prg Studio zu ermöglichen. Einen Workaround, der zwar nicht schön ist, aber funktioniert, möchte ich euch jetzt zeigen. Ihr könnt überall im Source Konstanten festlegen und mit diesen je eine Berechnung ausführen. Daher kann der Assembler die Block-Nr. doch bei der Erstellung berechnen, wenn wir es so umsetzen:

Wie ihr seht, legen wir eine Konstante CALCDUMMY an und berechnen dort direkt die Nr. des ersten 64-BYTE-Blocks. Danach addieren wir auf diese Konstante den Wert 8 (da der Rover Sprite 9 ist und 1 abgezogen werden muss). Dazu können wir die bereits verwendete Konstante CALCDUMMY erneut verwenden und auch mit derem bisherigen Wert arbeiten. Die Berechnung für die Luke führen wir abschließen aus, in dem wir noch mal eins zu CALCDUMMY addieren. Hier wäre ein inx eigentlich besser (spart ein BYTE), aber es ging mir um die mehrfache Verwendung von Konstanten. Natürlich würde hier auch ein ldx #CALCDUMMY+1 funktionieren.

Nun haben wir dem VIC gezeigt, wo die Spritedaten liegen, jetzt müssen wir die Sprites noch positionieren und einige Register setzen.

Da die Landeposition variieren kann, müssen wir hier die X-Position für den Rover zur Laufzeit berechnen. Der Rest ist soweit bekannt.

Nun lassen wir den Rover nach rechts aus dem Canyon fahren.

Damit der Rover nicht zu schnell bewegt wird, bauen wir bei @loop: eine Verzögerung ein (bei Verwendung einer Super-CPU werden solche Warteschleifen natürlich viel schneller durchlaufen). Wenn diese zwei verschachtelten Schleifen abgearbeitet sind, erhöhen wir das X-Register (dort steht immer noch die X-Position drin) und beachten dabei, dass wir auch das BIT für die maximale X-Position in $D010 setzen müssen. Dies machen wir, wenn das BIT noch nicht gesetzt wurde und die X-Position 0 ist. Wird die X-Position 0 und das höchste BIT ist bereits gesetzt, dann verlassen wir die Schleife durch einen Sprung nach @skip1:. Dort schalten wir noch den Rover ab und das Programm läuft dann wie bisher (BS grün, auf Feuer warten) weiter.

Führt ihr jetzt eine erfolgreiche Landung aus, dann könnt ihr beobachten, wie der Space-Rover den Canyon verläßt. Nachdem er den sichtbaren Bereich bereits verlassen hat, dauert es etwas, bis der Bildschirm endlich grün wird. Dass könnt ihr ja noch anpassen.

Ein letztes Problem wollen wir aber noch gemeinsam lösen. Da wir unseren IRQ gestoppt haben, verschwindet auch des Lasernetz. Dadurch sieht es während der Rover-Fahrt so aus, als sei der Canyon eine Höhle, weil der Himmel verschwindet.

Der Rover fährt, aber der Himmel ist weg!
Der Rover fährt, aber ohne den Himmel sieht es blöd aus!

 

Wir sollten nun also unseren Raster-IRQ bei einer Landung aktviert lassen, aber natürlich gleichzeitig dafür sorgen, dass man nicht wieder ‚losfliegen‚ kann.

Löscht erstmal bei gameloop: die markierte Zeile mit dem sei-Befehl.

Damit bleibt der Interrupt weiterhin aktiv, egal ob das Schiff zerstört oder gelandet wurde.

Um nun zu verhindern, dass das Schiff weiterhin sinkt bzw. steuerbar ist, fügen wir noch zwei kleine Prüfungen in unseren Interrupt ein.
Bei lander_IRQ: begeben wir uns vor die Zeile jsr updatesprites: ;Sprites positionieren und fügen die Prüfung ein.

Hier kontrollieren wir, ob Alive: positiv ist. Denkt daran, wie wir die Variable verwenden: ;-1 = OK, 0 = zerstört, 1 = gelandet. Wir rufen updatesprites: also nur auf, solange Alive: den Wert -1 hat (nicht vergessen, 0 gilt auch als positiv!), anderenfalls wird der Funktionsaufruf übersprungen.

Der freie Fall ist somit gestoppt, nun müssen wir noch die Eingabe unterbinden. Sucht das Label doRasterIRQ_Exit: und fügt über die davor stehende Anweisung jsr checkinput: ;Joystick verarbeiten nochmal die Prüfung für Alive: ein.

Hier ginge statt bpl doRasterIRQ_Exit: natürlich auch ein bpl *+5 wie oben. Da es aber ein passendes Label gibt verwende ich das lieber.

Um ein unschönes Flackern zu verhindern, löscht abschließend noch hinter waitForFire: das setzen der Rahmenfarbe. Wir färben nun nur noch den Canyon-Hintergrund rot und grün ein.

 

Jetzt sieht es schon besser aus…

'Keep watching the sky.'
‚Keep watching the sky.‚

 

Wie ihr seht, kann das Feintuning einiges an Zeit kosten und dies war nur ein kleiner Vorgeschmack, was man zur Verbesserung machen kann. Natürlich gibt es noch viel mehr: hübschere Grafiken (besonders der Canyon), beim Ableben eine Explosion anzeigen und einen passenden Sound-Effekt abspielen, evtl. etwas Musik, eine Punkteanzeige, usw.

Ihr könnt nun das Programm wieder im Java-Emulator starten bzw. euch den Source inkl. .d64-Image herunterladen. Nach diesem Download läßt sich auch das Puzzle wieder erstellen.


Wir schließen die Landung nun aber ab und wenden uns dem 3. Level ‚Die Fahrt zur Basis‚ zu. Dort wollen wir endlich etwas entwickeln, dass man auch mal vorzeigen kann.

Beachtet die Treibstoffanzeige.
Beachtet die Treibstoffanzeige.

Noch eine Warnung: ‚Spielt‚ ihr mit dem Source etwas rum und fügt weitere Funktionen oder ein 11. Sprite hinzu, dann stoßt ihr ganz schnell auf ein neues Problem. Die Treibstoffanzeige sieht dann ‚komisch‚ aus.
Wir haben uns bisher überhaupt keine Gedanken darum gemacht, wo wir welche Daten im Speicher ablegen. Dies wird eins der ersten Themen beim nächsten Level.

Bis dahin, gutes Gelingen,
Jörn

 


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

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