Dies ist ein Dokument, das ich 1995 geschrieben habe, als ich am ersten Spiel des Neversoft-Studios arbeitete: Skeleton Warriors. Dies war das erste Spiel, in dem ich keine 68K-Assemblersprache verwendet habe.
Foto gemacht um die Zeit. Das Entwicklungskit („Small Box“ und ICE) befindet sich zu meiner Rechten.
Spielstatus
Das folgende Dokument beschreibt kurz den Status des Skeleton Warriors-Codes für Sega Saturn und erwähnt auch einige der vielen Aspekte, die noch erledigt werden mussten.
Das Dokument wurde benötigt, um Dan, Ken und James mit dem vorgefertigten Code vertraut zu machen und ihnen den Zweck jedes Moduls und die Interaktion zwischen ihnen zu erklären. Er erlaubte mir auch, den traurigen Zustand dieses Codes zu würdigen, und brachte mich hoffentlich dazu, mich zu entscheiden.
Ich spreche auch ein wenig über das Einbetten von Daten (.GOV- und .GOB-Dateien) in das Programm und darüber, was wir in Zukunft tun werden.
Entwicklungsausrüstung
Unsere Zielplattform ist Sega Saturn mit zwei SH2 Risc-Mikroprozessoren und einem 68000. Solange wir nur den Master-SH2-Hauptprozessor verwenden, wird der zusätzliche SH2-Slave verwendet, wenn wir herausfinden, wie dies zu tun ist. 68000 wird zur Steuerung des Soundchips verwendet, wir mussten keinen Code dafür schreiben, da die von Sega bereitgestellte Soundbibliothek verwendet wird.
Das Programm ist fast vollständig in reinem C geschrieben. Wir verwenden den GNU SH2-Compiler, um den SH2-Ausgabe-Assembler zu erhalten. Der Code enthält mehrere SH2-Module, die hauptsächlich ausschließlich Daten enthalten. Bisher habe ich nichts Sinnvolles über SH2 geschrieben.
Als Entwicklungssystem verwenden wir PsyQ. Dies ist kein Standard-Sega-Entwicklungssystem, aber jeder, der damit gearbeitet hat, hält es für das Beste. Eine Alternative dazu ist SNASM, das von Cross Products im Besitz von Sega entwickelt wurde. Die meisten von Sega bereitgestellten Codebeispiele sollten im SNASM-Entwicklungssystem funktionieren, können jedoch problemlos in PsyQ konvertiert werden.
Das PsyQ-System besteht aus einer SCSI-Schnittstellenkarte, die im PC installiert ist, einer Kassette, die an Saturn angeschlossen und das Kabel angeschlossen wird. Quellen werden auf einem PC kompiliert und auf Saturn heruntergeladen, wo das Programm startet. Code kann vom PC aus debuggt werden.
PsyQ-EntwicklungssystemDie Kommunikation wird von einem residenten Programm (PSYBIOS) gesteuert, das die Kommunikation zwischen Maschinen verarbeitet. Auf diese Weise kann die Saturn-Konsole Dateien von einem PC auf die gleiche Weise herunterladen wie von einer CD. Wir verwenden diese Funktion, um Dateien jeder Ebene herunterzuladen.
Ich habe ein paar große und laute Schubladen in meinem Zimmer und zwei weitere PCs. Die kleinere der beiden Boxen ist die E7000PC, ein eingebauter SH2-Emulator. Es hilft herauszufinden, wo das Programm abstürzt, wenn der PsyQ-Debugger es nicht stoppt. Es ist auch nützlich, um Schreibvorgänge im Speicher zu verfolgen, aber bisher habe ich diese Funktion kaum verwendet.
Die zweite der lauten Schubladen heißt „Small Box“ (die erste „Large Box“ hatte etwa die Größe eines kleinen Kühlschranks). Im Wesentlichen handelt es sich um Saturn mit zusätzlichen Schnittstellen für das E7000 und den CD-Emulator. Auf der Vorderseite befinden sich Länder-ID-Schalter und ein Schalter zwischen PAL und NTSC.
Im zweiten Computer befindet sich ein CD-Emulator - eine große Platine, dank der die Festplatte des Computers vorgibt, ein CD-Laufwerk zu sein. Sie können ein CD-Image darin sammeln und in Echtzeit emulieren, um zu sehen, wie das Spiel aussehen wird, wenn es auf eine echte CD gelangt. Der Emulator funktioniert mehr oder weniger, obwohl er einige Probleme hat, an denen wir zusammen mit Sega arbeiten.
Segas Entwicklungskit selbstKompilieren und Verknüpfen
Die Generalversammlung des fertigen Programms wird von einem Makefile gesteuert: MAKEFILE.MAK. Es enthält Abhängigkeiten und Ziele für das gesamte Projekt, einschließlich des Kompilierens von .GOB- und .GOV-Dateien.
Einzelne C-Quellcodemodule (.C-Dateien) werden von CCSH in SH2-Objektmodule (.OBJ) kompiliert. Es ruft zuerst den GNU C-Präprozessor CPPSH (in C: \ GNUSH2 \ BIN) auf, ruft dann CC1SH für seine Ausgabe auf, um den SH2-Assembler-Code zu erstellen, und ruft schließlich ASSH (in C: \ PSYQ) auf, um ihn zu erstellen in das fertige Objektformat.
Wir verwenden C ++ nicht, weil mir gesagt wurde, dass es riesige Objektdateien erstellt. Ich habe jedoch nicht mit ihm gearbeitet, man kann experimentieren.
Mehrere Dateien in der SH2-Assembler-Sprache (mit der Erweiterung .S) werden einfach mit ASMSH direkt in .OBJ-Dateien gesammelt (dies ist nicht dasselbe wie ASSH, sondern ein komplexerer Makro-Assembler). Derzeit werden sie nur zum Einbetten von Daten verwendet und enthalten keinen maschinenabhängigen Code.
Der Saturn-RAM, in den Code geladen werden kann, ist in zwei 1-MB-Blöcke unterteilt. Einer beginnt bei 06.000.000 USD und der andere bei 002.000.000 USD. Der Block mit 00.200.000 US-Dollar wird ausschließlich zum Speichern von Grafiken der Hauptfigur verwendet. Der Programmcode wird mit 06010000 USD geschrieben (die ersten 10.000 Byte werden für Systemspeicher, Stapel und dergleichen verwendet.)
Der Code ist positionsabhängig und wurde so kompiliert, dass er unter dieser bestimmten Adresse (06010000 USD) und sonst nichts ausgeführt wird.
Die OBJ-Dateien werden mithilfe des PSYLINK-Programms miteinander verknüpft, um die MAIN.CPE-Datei zu erstellen, ein ausführbares Programm mit einem kleinen Header, das mit dem Befehl RUN auf Saturn heruntergeladen werden kann. PSYLINK verwendet die Datei TEST.LNK, um anzugeben, welche OBJ-Dateien eingeschlossen werden sollen und wo sie abgelegt werden sollen.
Daten
Das Spiel ist in mehrere Level unterteilt, viele Level verwenden dieselben Daten, aber im Grunde sind sie für jedes Level unterschiedlich. Alle Daten für jede Ebene werden in zwei riesigen .GOV- und .GOB-Dateien gesammelt. (Im Fall einer Mine sind es MINE.GOV und MINE.GOB). Die GOV-Datei enthält einen kurzen Header und enthält dann alle Daten, die sich im Videospeicher befinden sollten. Die .GOB-Datei enthält alle Daten, die sich im RAM befinden müssen.
Die Ebene besteht aus einem Teil der unten gezeigten Datendateien.
.SSQ - Sprite-Sequenzer-Datei
.SBM - Bitmap-Datei für Bit-Hintergründe
.MAP - beide Karten für symbolreiche Hintergründe.
.TIL - Kachelsätze und Paletten für symbolreiche Hintergründe.
.PTH - Daten von Straßenpunkten und Auslösern.
.TEX - Texturen für die Straße.
Die .SSQ- und .SBM-Dateien wurden von meinem zunehmend unangenehmen SEQ-Sequenzer erstellt. Die Dateien .MAP, .TIL, .PTH und .TEX wurden von Dan erstellt, einem zunehmend beeindruckenden TULE-Karteneditor.
Diese Dateien werden mit dem ASMSH-Assembler zu den entsprechenden .GOV- und .GOB-Dateien zusammengesetzt. Informationen dazu finden Sie in den Dateien LEVEL.S und LEVEL1.S. Eine .GOV-Datei enthält auch einige Daten auf einer bestimmten Ebene.
Module
TEST.S - nichts Besonderes, setzt ein paar Etiketten.
MAIN.C ist die oberste Ebene des Programms. Es enthält die Initialisierung von Geräten, Ebeneneinstellungen, einen Code zum Übergeben von Ebenen und verschiedene andere kleine Elemente, die eigentlich in besser geeignete Module eingefügt werden sollten. Es ist viel Müll darin, weil es am einfachsten ist, diesem Modul etwas Neues für schnelle Tests hinzuzufügen. Enthält den Startcode von einer CD oder einem Dateiserver auf einem PC. Enthält ein Flag zum Aktivieren oder Deaktivieren der TIMING-Farbbalken.
GFXLIB.C - verschiedene Verfahren für den Zugriff auf Geräte und die Ausführung verschiedener
Grafikfunktionen . Fast alle von ihnen wurden von Dan von Grund auf neu geschrieben und sind oft sehr ineffizient. Wenn Sie das Verfahren von hier aus häufig verwenden, ist es hilfreich, einen Blick auf die Funktionsweise zu werfen und eine schnellere Version in Ihren Code zu schreiben.
Alle Funktionen funktionieren jedoch und bieten einen hervorragenden Rahmen für eine grobe Implementierung und Prüfung. Danke Dan, ohne ihn wäre es nicht möglich gewesen.
SMP_PAD.C - verschiedene Verfahren zum Lesen vom Saturn-Joystick, sehr abhängig von der Ausrüstung.
GLOBALS.C - alle globalen Variablen und mehrere gemeinsame Funktionen. Die Verwendung globaler Variablen ist eine akzeptable Programmierpraxis. Aus verschiedenen Gründen ist die Implementierung globaler Variablen in SH2 jedoch eher langsam, sodass ich den Teil im Laufe der Zeit wahrscheinlich bei Bedarf in globale Strukturen konvertieren werde. Enthält Variablen, die den Status von
MAN und
PATH beschreiben .
MAN.C - übernimmt die Bewegung und Anzeige einer Person (Prince Lightstar, Talyn, Guardian oder Grimskull - der vom Spieler kontrollierte Charakter). Bisher ist dies hauptsächlich die Logik von Bewegung und Kollisionen mit der Straße. Darüber hinaus bietet es für jede Aktion die entsprechende Animation. Es gibt noch viel zu tun.
OB.C - übernimmt die Bewegung und Anzeige von Objekten im Spiel, insbesondere von Objekten von Feinden, z. B. Skelettkriegern und kleinen Außerirdischen. Der Hauptteil des Spiels ist hier programmiert: feindliche KI, Grundbewegungen und Auslösen von Auslösern. Die Datenstruktur ist noch nicht fertig, insbesondere Probleme mit Kollisionen und Animationen sind nicht vollständig gelöst. Es gibt noch viel zu tun.
DATA.S - verschiedene Tabellen, derzeit hauptsächlich Animationen der Hauptfiguren des Spielers.
LAYER.C - Scrollen von Hintergründen mit Parallaxe. Aktualisiert Symbolhintergründe und scrollende Bitmaps. Auch Bildlauflinien (Welleneffekt) in der Nebelebene. Bisher werden Tabellen für Symbolzuordnungsebenen ohne Komprimierung gespeichert. Sie müssen auf das RLE-Format komprimiert werden, das ich für die Genesis-Version verwendet habe. Diese Aufgabe kann an Ken gehen, wenn wir früher als für Sony ein Entwicklungssystem für Saturn bekommen.
PAL.C - Palette. Sie können aus 2048 Farben wählen. Jedes Pixel auf dem Bildschirm kann eine dieser Farben sein. Ich habe die Palette logisch in acht Paletten mit 256 Farben unterteilt. PAL.C enthält Code für ihre Initialisierung, Vorbereitung und Code für ihre zyklische Änderung. Sie benötigen außerdem ein Dimmen und eine komplexere zyklische Verschiebung sowie Helligkeitsblitze usw.
BUL.C ist ein primitives System zum Verarbeiten von Muscheln (Schwert werfen, Hand schlagen, Raketen aus den Armen schießen usw.) als separate Objekte. Für den komplexeren Einsatz von Muscheln ist noch viel Arbeit erforderlich. Sie benötigen außerdem den richtigen Kollisions- und Animationscode.
PAD.C ist ein einfaches Modul zum Speichern des Status des Joysticks in einem bequemeren Format. Speichert, ob die Taste kürzlich gedrückt wurde und ob sie jetzt gedrückt wird.
START.C - Eine Zeile, die
angibt , welche Ebene die erste sein wird, um das Ändern in der Batchdatei zu vereinfachen.
PANEL.C - einfache Verfahren zum Zurückziehen eines
Kraftstreifens .
PATH.C - monströse Verfahren zum Zeichnen der Straße sowie zum Umgang mit Kollisionen mit der Straße.
MATH.C - einfacher Sinus, Cosinus und Drehung eines Punktes um einen Winkel.
[Update] Hier ist ein Beispielcode von MAN.C. Alles ist starr im Code geschrieben und bezieht sich auf die globale Datenstruktur Man. Eine Reihe von Zahlen, die im Code geschrieben sind.
Man_JumpTrigger() { if ( Man.JumpFudge ) { Man.JumpFudge--; } if ( Man.Mode != M_Crouch || Man_StandingRoom() )
OB.C hat sich zu einer monströsen Datei mit 9.000 Zeilen entwickelt, die alle Verhaltensmuster einzelner Objekte im Spiel enthält. Es gibt auch eine große Anzahl von Zahlen im Code, zum Beispiel:
Drop_Arac(S_Ob *pOb) { int t; if (pOb->Jump==1) { pOb->yv.f+=0x7fff; pOb->y.f+=pOb->yv.f; t=Path_GetYZ(pOb->xi,pOb->yi,pOb)-15; if ((t>pOb->yi)&&(t<pOb->y.i+20)) { pOb->Jump=0; pOb->y.i+=15; Turn_Around(pOb); pOb->SeqFile=Sprites[SpriteMap[34]]; Object_TriggerSeq(Arac_JumpLand,pOb); } } else { if (pOb->Frame==16) pOb->Jump=1; if (pOb->AnimStat==AnimDone) { pOb->t1=0; pOb->Mode=&Pattern_Arac; } } Command_Arac(pOb); }
Ein unangenehmer Anblick. Dieser Codestil stammt aus einer Zeit, als die Spiele noch sehr klein waren und ich ihn bei der Arbeit mit 68K entwickelt habe.