Landung 003

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 StudioDas Raumschiff ‚zusammenbauen‚

Diesmal geht es darum unser Raumschiff auf den Bildschirm zubringen, aber leider werden wir dann gleich wieder ausgebremst. Sollten Probleme auftreten, benutzt einfach den Download aus ‚Landung 002‚ als Ausgangspunkt.

 

Das Raumschiff anzeigen
Wie bereits bei ‚Landung 001‚ erklärt, besteht das Raumschiff aus zwei übereinanderliegenden Hi-Res-Sprites und drei MultiColor-Sprites. Zur Erinnerung, im Editor sollten die Sprites ungefähr so aussehen:

Die Sprites
Die Sprites

Wer mit dem Sprite-Editor noch auf ‚Kriegsfuß‚ steht, sollte evtl. nochmal bei ‚Sprites (ASM)‚ nachschlagen.

Benutzt ihr den herunterladbaren Source aus dem letzten Beitrag, dann findet ihr schon eine entsprechende ‚Region‚ und ein  align 64. Fügt dahinter das Label sprite_Spaceship:, gefolgt von  incbin "<Sprite-Datei>",1,5,true ein. Es ist klar, dass ihr <Sprite-Datei> durch den Namen eurer Datei ersetzen müsst. Außerdem benötigt ihr mindestens CBM prg Studio 2.7.0, erst ab der Version sorgt dass abschließende true dafür, dass die Sprites auf 64-BYTES aufgefüllt werden.

 

Dann gibt es wieder zwei Konstanten, die am Programmbeginn benötigt werden.

 

In der Funktion init_lander: fügen wir vor das jsr draw_canyon: folgende Zeilen ein.

Hier wird einfach die X- & Y-Startposition in die Variable SpaceshipPos: geschrieben, die z. B. hinter  LaserFlash: eingefügt werden kann.

 

Dann wird zur Initialisierung der Sprites, nach  init_sprites: gesprungen:

Zu Beginn wird wieder die Spriteposition berechnet (zur Abwechslung mal ohne Schleifen). Anschließend werden die Spritedaten auf die Sprite-Nr. verteilt. Hier ist es wichtig auf die korrekte Reihenfolge zu achten. Die ‚Details‚ (schwarzes Sprite) sollten die Nr. 0 begkommen, um alles Andere zu überdecken. Dann folgen ‚Feuer unten‚ (Nr. 1), ‚Feuer links‚ (Nr. 2), ‚Feuer rechts‚ (Nr. 3) und der ‚Schiffsrumpf‚ (großes graue Sprite) wird (Nr. 4). Die Feuerdüsen müssen in dieser Reihenfolgen abgelegt werden, damit das Einblenden nachher korrekt klappt. Der Rest sollte kein Problem sein, über updateSprites: werden einmal die Sprite-Positionen gesetzt, dann Farben, MultiColor, Doppeltebreite usw. gesetzt und schließlich Sprite 0 und 4 sichtbar geschaltet.

Die verwendetet Variable calc16Bit: muss noch (wie wäre es vor LaserFlash:) eingefügt werden.

Statt zweier BYTE-Anweisungen für den Assembler, habe ich mich diesmal für ein WORD entschieden, dass reserviert ebenfalls zwei BYTES, macht aber den Verwendungszweck noch etwas deutlicher.

Bevor wir das Programm wieder starten können, wird noch eine weitere Funktion benötigt.

Diese Funktion positioniert alle Sprites so, dass sie jederzeit an der richtigen Stelle stehen. Zu Beginn wird die X-Position aus SpaceshipPos: geholt. Für die Details, den Rumpf und ‚Feruer unten‚ passt dieser Wert. Die Feuerdüsen für links und rechts müssen aber etwas verschoben werden, bis sie an der richtigen Stelle erscheinen. Zum Schluß müssen noch alle Sprites auf die korrekte Y-Position gesetzt werden und schon kann die Funktion verlassen werden.

Endlich können wir uns das Ergebnis mal ansehen. Wie man direkt sieht, haben wir ein kleines Problem. Habt ihr das Programm bis hierher unverändert übernommen und auf einem PAL-System gestartet, dann sollte euch ein Flackern des Himmels auffallen. Aktiviert ihr auch nur ein Sprite mehr ist der Himmel fast dauerhaft braun statt blau, aktiviert ihr aber nur ein einziges Sprite sieht wieder alles gut aus.

Daher unterbrechen wir hier erstmal wieder, um im nächsten Beitrag zu klären, was da gerade schiefgeht.

 


 

Auch wenn das Flackern dort nicht auftritt, könnt ihr das Programm im Java Emulator starten. Dies ist ein schönes Beispiel dafür, dass man sich bei der Entwicklung unter Windows nie zu sicher sein sollte. Würden wir uns nur auf den Java-Emulator verlassen, gäbe es anscheinend überhaupt kein Problem. Auch wenn VICE und CCS64 echt super sind, ein Programm sollte zusätzlich immer auf einem echten C64 getestet werden. Um so trickreicher eure Effekte sind, um so wichtiger wird dies natürlich. Die Grenzbereiche der Hardware sind eher ein Problem für Emulatoren, als die ‚Hausmannskost‚.

 


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

2 Gedanken zu „Landung 003“

  1. Hi,
    Darf man hinter einem incbin keinen ;rem machen? Habe jetzt fast eine Stunde lang nach dem Bug gesucht. Ich hatte ganz unten incbin "lander.spt",1,5,true ;rem Kommentar, dann passen die Sprites nicht mehr. Komisch.
    Schönen Urlaub noch.

    1. Hallo,
      ja du hast recht (wieder mal 😉 ).
      Ein Kommentar hinter dem TRUE führt dazu, dass dieses nicht mehr korrekt ausgewertet wird. Die Sprites werden dann nicht auf 64-BYTEs aufgefüllt!

      Da dies auch bei meiner BETA 3.1 noch der Fall ist, habe ich Arthur das Problem mitgeteilt.

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