Playstation Doom Polygone

Bild

Sony PlayStation



Die Geschichte der PlayStation begann 1988, als Nintendo und Sony gemeinsam an einem optionalen CD-ROM-Reader für die SNES-Konsole arbeiteten. Im Rahmen der Vereinbarung konnte Sony eigenständig Spiele für diese Plattform entwickeln und die Kontrolle über das Super Disc-Format behalten - zwei ungewöhnliche Zugeständnisse von Nintendo.

Das Projekt wurde vor der Ausstellung CES '91 entwickelt, bei der Sony eine Zusammenarbeit bei Play Station ankündigte. Am nächsten Tag gab Nintendo auf derselben Ausstellung zur Überraschung von Sony bekannt, dass es stattdessen eine Partnerschaftsvereinbarung mit Philips geschlossen hatte (zu viel günstigeren Konditionen). Die loyale und öffentlich gedemütigte Sony versuchte, sich an den Vorstand von Sega zu wenden, der die Idee sofort ablehnte. In einem Interview mit 2013 erinnerte SEGA-CEO Tom Kalinske an die Entscheidung des Rates.

„Das ist eine blöde Idee, Sony weiß nicht, wie man Geräte entwickelt. Sie wissen nicht, wie man Software schreibt. Warum spielen wir mit ihnen? " - SEGA-Verwaltungsrat

Und sie täuschten sich nicht, Sony hatte wirklich wenig Erfahrung in der Arbeit mit Spielen. Sie zeigte fast kein Interesse an ihnen, mit Ausnahme der Initiative einer Person - Ken Kutaragi. Von dem Moment an, als er seine Tochter beim Nintendo Famicom spielen sah, hat Ken Sony davon überzeugt, dass er in diesen Markt eintreten muss. Trotz der Empfehlungen der Vizepräsidenten von Sony entwickelte er für Nintendo sogar den in SNES verwendeten Audio-Chip (SPC700).

Die meisten Führungskräfte von Sony hielten dies für eine riskante Wette, aber Kutaragi fand Unterstützung in der Person von Norio Oga, CEO von Sony. Im Juni 1992 durfte Ken ein Spielesystem von Grund auf neu entwickeln. Um den Vorstand zu beruhigen, wurde der „Vater der PlayStation“, wie sie ihn später nannten, an die finanziell unabhängige Muttergesellschaft Sony Music übertragen, und er begann mit der Arbeit an der späteren „PlayStation“ (bereits ohne Leerzeichen im Namen).

Zunächst konnten Entwickler nicht entscheiden, ob sich die Architektur auf Sprite-2D-Grafiken oder Polygon-3D-Grafiken konzentrieren sollte. Der Erfolg des Virtua Fighter-Spiels, das Sega im Oktober 1993 auf japanischen Arcade-Automaten veröffentlichte, zerstörte jedoch alle Zweifel: Die PSX wird dem 3D-Pfad folgen.

Der Höhepunkt des Projekts war zwei Jahre später, als Sony Computer Entertainment am 3. Dezember 1994 gegründet und die Konsole in Japan veröffentlicht wurde. Es war sofort erfolgreich und wurde am ersten Tag mit einer Auflage von 100.000 Geräten, 2 Millionen Geräten nach sechs Monaten und 102 Millionen Geräten während ihres gesamten Lebens verkauft.


Sony PSX (PS1, PlayStation). Foto: Wikipedia

Die Architektur



Das Herzstück der Maschine ist der 32-Bit-RISC-R3000A-Prozessor MIPS mit einer Frequenz von 33,8688 MHz [3] in Kombination mit 2 MB DRAM. Es ist bemerkenswert, dass dieser Chip auch über einen Motion Decoder (MDEC) verfügt, der eine Videowiedergabe mit einer Auflösung von 320 x 240 bei einer Frequenz von 30 fps ermöglicht. Neben MDEC sehen wir den GTE-Coprozessor (Geometry Transform Engine), mit dem schnelle mathematische Festkommaoperationen an Vektoren und Matrizen ausgeführt werden. Das gesamte System kann nicht mit Gleitkommazahlen arbeiten.

Die GPU ist eine „Black Box“, die vom Zentralprozessor mithilfe von „Befehlen“ gesteuert wird. Es verfügt über 1 MB VRAM, das für die CPU nicht verfügbar ist. In vielerlei Hinsicht ähnelt seine Arbeit der Arbeit des wunderbaren Sofortmodus OpenGL: Er zeichnet strukturierte Polygone, die mithilfe von Scheitelpunktfarben „schattiert“ werden können. Die Grafikpipeline ist fest und kann nicht programmiert werden. Es gibt keinen Z-Puffer (Tiefenpuffer).

Die Sound Processing Unit Sound Processing Unit (SPU) ist wie die GPU eine Black Box. Es kann 24 Kanäle verarbeiten, verfügt über 512 KB SRAM zum Speichern von Audio (im ADPCM-Format) und kann CD-ROM-Audiospuren mit seinen Audiokanälen mischen. Die Abkürzung SRAM bedeutet nicht "Static RAM", sondern "Sound RAM".

Die gewagteste Entscheidung der Sony-Ingenieure war die Wahl des Datenträgers. Sie entschieden sich nicht für Kassetten, sondern für ein CD-ROM-Modul mit doppelter Geschwindigkeit, das die Kosten für Spiele senkte und das verfügbare Volumen erheblich erhöhte (bis zu etwa 650 MB). Die Nachteile sind die niedrige Übertragungsrate (300 KB / s) und die ungeheuer große Kopfinstallationszeit (300 ms).

In der Konsole befindet sich kein Blitter. Das Programmiermodell der Maschine war, dass die Entwickler das "bloße" Eisen nicht berührten. Es gibt jedoch einen DMA-Controller zum Übertragen von Daten von CD / DRAM zu VRAM / SRAM.

Videosystem


Trotz der Tatsache, dass das Videosystem 24-Bit-Farben unterstützt, haben es nur sehr wenige Spiele verwendet (mit Ausnahme von Heart Of Darkness-Hintergründen [4] ). In der Praxis kann mit gutem Gewissen gesagt werden, dass die meisten Spiele 16-Bit-Farben mit einer 1-Bit-Maske verwendeten.



PSX-Farbraum mit einer Tiefe von 15 Bit pro Pixel

Ein beeindruckendes Merkmal des Videosystems ist die Organisation des VRAM, die vollständig vom Entwickler abhängig ist. 1 MB VRAM wird als Array von 1024 x 512 x 16 Bit betrachtet, das frei verwendet werden kann. Die Anwendung der Doppel- oder Dreifachpufferung erfolgt auf triviale Weise, da der Bereich einfach ausreicht, um zu reservieren, zu zeichnen und an das Ausgabesystem zu übertragen. Texturen befinden sich auch im VRAM neben den Rahmenpuffern. Zum Schreiben in den Bildspeicher werden GPU-Befehle zum Rendern strukturierter Dreiecke / Vierecke gestartet.

Texturen können verschiedene Formate haben. Es gibt zwei direkte Quellen für 16-Bit- und 24-Bit-Farben sowie Quellen, die auf einer Palette basieren, die als Color Look Up Table (CLUT) bezeichnet wird. 8-Bit- und 4-Bit-CLUTs werden unterstützt.

In Bezug auf die Auflösung war die Konsole auf NTSC- und PAL-Fernsehstandards beschränkt. Für den US- und den japanischen Markt konnte der Entwickler eine horizontale Auflösung von 256, 320, 384, 512 oder 640 Pixel wählen. Die vertikale Auflösung betrug entweder 240 Pixel (beim Überspringen jeder zweiten Rasterzeile) oder 480 Pixel beim Abwechseln. Beide vertikalen Modi arbeiteten mit einer Frequenz von 60 Hz. Der einzige Unterschied zwischen NTSC und PAL war eine erhöhte vertikale Auflösung (256/512 statt 240/480) und eine niedrigere Bildwiederholfrequenz (50 Hz).

NTSC-Modus (60 Hz) PAL (50 Hz) Hinweis
================================================== ========

0 256 x 240 256 x 256 Nicht interlaced
1 320 x 240 320 x 256 Nicht interlaced
2 512 x 240 512 x 256 Nicht interlaced
3 640 x 240 640 x 256 Nicht interlaced
4 256 x 480 256 x 512 Interleaved
5 320 x 480 320 x 512 Interleaved
6 512 x 480 512 x 512 Interleaved
7 640 x 480 640 x 512 Interleaved
8 384 x 240 384 x 256 Nicht interlaced
9 384 x 480 384 x 512 Interleaved


Achten Sie auf die Modi mit einer horizontalen Auflösung von 384 Pixel (8 und 9), die nach ihrer ID später hinzugefügt wurden.

DOOM auf PSX


DOOM wurde von Williams Entertainment mit Unterstützung von id Software auf PSX portiert. Ein Team von fünf Personen brauchte etwas weniger als ein Jahr [5] [6] , um die Engine zu portieren, Ressourcen zu ändern und das Spiel so zu modifizieren, dass alles „nur“ mit 3,5 MB RAM funktionierte.

„Die Grafik wurde verschlechtert: Texturen werden verkleinert, Sprites, Monster und Waffen ebenfalls. [...] Manchmal schneiden wir Animationsrahmen. " - Harry Tisley

Das fertige Ergebnis wurde am 16. November 1995 veröffentlicht. Es gilt als der beste Konsolenport des Spiels, und einige Aspekte übertreffen die PC-Version aufgrund von Farboberteilen und Musik in CD-Qualität sogar.

"Bisher ist dies das beste DOOM!" - John Romero

Studienplan



Aufgrund der Art der Entwicklung basiert die DOOM-Struktur auf einem Kernel, der sechs Subsysteme für E / A verwendet. Die meiste Zeit habe ich die drei Teile studiert, die ich am interessantesten fand, nämlich das CD-ROM-basierte Dateisystem, SPU-basiertes Audio und GPU-basiertes Video, da sie für die PSX-Architektur einzigartig sind.

Der DOOM-Quellcode für die PSX wurde nie veröffentlicht, stellte sich jedoch als überhaupt kein Problem heraus. Verfügbare Informationen sind ausreichend.

Die erste Quelle ist das großartige PSY-Q SDK, das „offizielle“ Tool der damaligen PSX-Entwickler. Es gibt eine Menge Dokumentation, die als Satz von PDF-Dateien präsentiert wird. Eine solche Fülle an Informationen bestätigt nur all das Gute, das ich über die Freundlichkeit der PSX gegenüber Entwicklern gehört habe. Die von Psygnosis entwickelte Bibliothek (d. H. Libcd, libds) ist ebenfalls gut dokumentiert. Es war sehr schön, klare Erklärungen zu sehen, insbesondere im Vergleich zu dem fast vollständigen Mangel an Informationen über andere Konsolen (ja, ich spreche von SNES).

Eine weitere Informationsquelle sind die vielen heute verfügbaren externen Tools. Mit ISOBuster konnte ich den Inhalt der CD öffnen. PSound half beim Scannen von LCD-Dateien. Die beeindruckende Fähigkeit des No $ PSX-Emulators, GPU- und SPU-Befehle zu verfolgen, ist zu echtem Gold geworden.

Aber vielleicht war ich am meisten beeindruckt von der großen Liebe von DOOM zu PSX aus der Fan-Community. Ein komplettes Reverse Engineering des Spiels wurde durchgeführt. PSXDOOM-RE zeichnet sich insbesondere dadurch aus, dass es sich um eine C-Codebasis handelt, die mit dem PSY-Q SDK zu einem vollwertigen PSX-Spiel kompiliert werden kann. Der Code ist sehr zuverlässig, da er durch Umschreiben jeder Funktion des Maschinencodes in C erhalten wurde.

Die erstaunliche Welt der CDs


Bevor ich anfing, die Implementierung des Dateisystems zu studieren, machte ich einen kurzen Ausflug, um die wunderbare Welt der CDs besser zu verstehen.

Seit 20 Jahren, von 1980 bis 2000, wurden mehrere Bände mit Spezifikationen veröffentlicht, die dieses Thema offenbaren. Zusammen heißen sie "Regenbogenbücher". Das erste Buch der Reihe, „Red Book“, enthält Spezifikationen für eine Audio-CD (CD). Das „Gelbe Buch“ ist eine Ergänzung zum „Roten Buch“ und enthält Datenspezifikationen für CD-ROM und ISO-9600. Das Orange Book enthält Spezifikationen für CD-DA, CD-R (beschreibbar) und CR-WR (umschreibbar). Das White Book ist der Video-CD (VCD) gewidmet. Das Green Book spricht über CD-Interactive (CD-I). Das Blue Book enthält ECD-Daten (Enhanced-CD) für die Multimedia-Unterstützung. Das Scarlet Book ist Super Audio (SACD) gewidmet, das hochauflösendes Audio hinzufügt. Das Purple Book enthält die DDCD-Spezifikation (Double Density CD), mit der die Festplattenkapazität von 650 MB auf 1,3 GB erhöht wurde. Schließlich,Cyan Buchdetails 9660 Dateisystemspezifikationen[7] .


Rainbow Books enthält alles, was wir über die CD wissen.

Als absolutes Minimum müssen wir verstehen, dass PSX-CDs normalerweise aus Sektoren bestehen, von denen jeder 2048 Datenbytes enthält. Sektoren werden in Spuren gruppiert (die Daten oder Ton sein können). Die Tracks sind in einer Sitzung gruppiert. Informationen zu Datenspuren können mit dem Standard-Dateisystem ISO-9660 bestellt werden, das Spiel kann jedoch auch fest codierte Sektoradressen haben.

In der DOOM-Spiel-CD



Wenn Sie mit ISOBuster in die CD-ROM schauen, können Sie sehen, dass DOOM aus einer Sitzung mit acht Titeln besteht [8] . Sieben davon sind Soundtracks in CD-Qualität, die zwischen den Missionen und in der letzten Szene gespielt werden. Der letzte Track (# 7) verwendet sogar digitalisierte Dämonenstimmen. Track Nummer 6 ist besonders bemerkenswert, weil er direkt von der Rave-Party übernommen worden zu sein scheint. Es stellt sich heraus, dass dies Musik ist, die auf der Super-Secret-Karte 59 „Club DOOM“ (einer Geheimkarte, auf die nur von einer Geheimkarte aus zugegriffen werden kann) gespielt wird [9] . Lass mich dich ihren Wahnsinn schätzen lassen. Überprüfen Sie vor dem Start die Lautstärke.


Der verbleibende Titel (Nummer 1) ist ISO-9660, der die Spiel-Engine und die meisten Ressourcen enthält. Nachdem ich die vielen DOOM-Ports erkundet hatte, erwartete ich naiv eine Engine namens DOOM.EXE, eine PSXDOOM.WAD-Ressourcendatei und möglicherweise ein Manifest. Ich habe mich sehr geirrt. Auf dem Track wurden 287 Dateien [10] [11] gefunden , darunter 60 .WAD, 120 .IMG und unzählige .LCD.

Die Daten sind nach Ebenen geordnet (fünf Dateien pro Karte).

Dateiname Beschreibung
================================================== =====

MAPDIR0 / MAP01.WAD Standardgeometrie (BSP / Reject / ...)
MAPDIR0 / MAPTEX01.IMG Texturen von Ebenen / Wänden
MAPDIR0 / MAPSPR01.IMG Alle von THINGS erstellten Sprites
MUSIC / MUSLEV1.LCD Abspielbare Musik
SNDMAPS1 / MAP01.LCD Alle von THINGS erzeugten Sounds

Auf die Frage, warum alles neu arrangiert wurde, antwortete Crash Bandicoot-Entwickler Andy Gavin teilweise in einem Interview mit Ars Technica. [ Übersetzung auf Habré]

"Es dauert ungefähr 1/3 Sekunde, um den Kopf an einen beliebigen Punkt auf der CD zu bewegen."

Aufgrund der Tatsache, dass die Kopfpositionierungsgeschwindigkeit nahe 300 ms lag (was durch die PSY-Q-Dokumentation bestätigt wird [12] ), konnten die Entwickler von Williams Entertainment die klare Architektur der DOOM-Engine, die alle Ressourcen in einer Datei speicherte (z. DOOM.WAD) und auf Anfrage heruntergeladen. Auf der PSX würde dies zu einer schrecklichen Bildrate führen.

Die Entwickler lösten das Problem, indem sie eine scheinbar endlose Anzahl von Bytes auf die CD warfen. Alle für das Level erforderlichen Ressourcen wurden in fünf Dateien gespeichert, die die Geometrie der Karte und die Textur enthielten. Sprites, Soundeffekte und Musik. Dies ist sehr teuer, macht jedoch den Zugriff auf die CD während des Spielvorgangs überflüssig.

Interessante Tatsache:In der Liste der Dateien auf der Datenspur befindet sich eine Datei mit dem Namen PSXDOOM.WAD (4 806 088 Byte), die jedoch nur zum Laden von Paletten und mehreren Menübildern verwendet wird. Wahrscheinlich aktiver im Entwicklungsprozess eingesetzt.

Nehmen Sie als Beispiel die erste Karte: Die Gesamtmenge der heruntergeladenen Daten wurde von 4 MB auf 900 KB reduziert.

Dateinamengröße (in Bytes)  
=====================================  	
MAPDIR0 / MAP01.WAD 28 196
MAPDIR0 / MAPTEX01.IMG 90 744
MAPDIR0 / MAPSPR01.IMG 590 344
MUSIC / MUSLEV1.LCD 61 232
SNDMAPS1 / MAP01.LCD 143 632
=====================================
Gesamt: 914.148

Wenn Sie wissen, dass Ressourcen 914 KB belegen, könnten Sie denken, dass noch viel unbenutzter DRAM übrig ist. Sie müssen sich jedoch daran erinnern, dass es auch eine ausführbare Datei mit 428 KB sowie einen Stapel enthalten muss, der sich zur Laufzeit ändert. Tatsächlich war zur Laufzeit nur etwa 1 MB DRAM verfügbar.

Eine interessante Tatsache: Bei der Untersuchung des Quellcodes von PSXDOOM-RE entdeckte ich die Funktion P_LoadBlocks, die bis zu vier Mal versucht, von CD zu lesen [13] und sich dann ergibt . Dies ist eine der Freuden beim Arbeiten mit leicht zerkratzbaren Medien.

Ich hatte nicht erwartet, dass die Installationszeit des CD-ROM-Kopfes die Spielarchitektur so stark beeinflusst. Einige Spiele, wie Crash Bandicoot, wurden von Grund auf mit einem Seitensystem zum Streamen von Daten von einer CD zur Laufzeit erstellt. Im Falle von DOOM war der Motor dazu nicht in der Lage. Die CD wird während des Spiels nicht verwendet, mit Ausnahme eines bestimmten Songs (ja, aus dem Club DOOM-Level).

Die Jungs von id Software waren noch nie ein Fan des Kompromisses zwischen Kapazität und Geschwindigkeit, den CD-ROMs bieten.

« - . , CD. - , Crash 'n Burn — ? . , CD , 3DO . - CD- DOOM, „ DOOM“. , . .

, CD. ». — (ATARI EXPLORER ONLINE, 22 1994 )

Eine interessante Tatsache: Ereignisse innerhalb des DOOM-Spiels wurden mit "Dehnungsstreifen" ausgelöst. Beim Überqueren einer Linie mit einer speziellen Eigenschaft wurde eine spezielle Funktion aufgerufen. In der "Legacy" -Version der Engine gab es keine Eigenschaft, mit der Sie Songs abspielen konnten. Um Club DOOM zu spielen, wurde eine spezielle Linedef-Aktion erstellt (Nummer 142) [14] . Es ist erstaunlich, wie viel zusätzlicher Aufwand erforderlich war, um dieses Level zu erstellen. Wahrscheinlich hatten die Entwickler wirklich Spaß an den Raves.

Der Fall des vermissten Archvile



Bei der Recherche für mein Game Engine Black Book konnte ich diesen Satz von Designer Harry Teesley nicht vollständig herausfinden:

„Archvile hatte doppelt so viele Animationsbilder wie jedes andere Monster, und wir konnten es nicht in die PSX packen. Weder sein Angriff noch der Auferstehungseffekt konnten verloren gehen. Er war zu groß. " - Harry Tisley (Designer) in einem Interview mit doomworld.com

Es war offensichtlich, dass das Problem nicht die 650-Megabyte-Kapazität der CD war, aber ich verstand nicht, was der begrenzende Faktor war - DRAM oder VRAM.

Nachdem ich die Einschränkungen der CD-ROM verstanden hatte, stellte ich fest, dass das Problem nicht darin bestand, das Sprite auf einer CD zu speichern oder es sogar vom DRAM zum VRAM zu übertragen. Das Problem ist, alles in DRAM zu passen.

Interessante Tatsache: ArchVile wurde vollständig aus dem Quellcode von PSXDOOM-RE entfernt. Sogar sein #DEFINE ist auskommentiert [15] .

#define CC_ZOMBIE  "Zombieman"
#define CC_SHOTGUN  "Shotgun Guy"
#define CC_HEAVY  "Heavy Weapon Dude"
...
#define CC_HELL   "Hell Knight"
//#define CC_ARCH "Arch-Vile"
#define CC_SPIDER "The Spider Mastermind"
#define CC_CYBER  "The Cyberdemon"
#define CC_HERO   "Our Hero"

SPU-Programmierung


Der SPU-Chip versteht nur ein Format, nämlich ADPCM. Es kann bis zu 24 Kanäle (einschließlich der CD-Audiospur) mischen und verfügt über leistungsstarke Audiomanipulationsfunktionen.

Um dieses Biest zu zähmen, verwendet das DOOM PSX die libWESS-Bibliothek (Williams Entertainment Sound System), die vom Toningenieur Scott Patterson geschrieben wurde. Die Bibliothek ist sehr leistungsfähig und kann das MiDI-System nachbilden, bei dem eine schwere Bank von Noten (Sound Font genannt) von einer Musikpartitur gesteuert wird, die wenig Platz beansprucht. Es kann auch Echtzeit-Soundattribute wie Lautstärke, Ton, Notengeschwindigkeit und ADSR-Funktionen (Attack, Decay, Sustain und Release) bearbeiten. Alle Musik, die während des Spiels gespielt wird, wird mit libWESS generiert. Mit einer Ausnahme, Sie haben es erraten, ist dies Club DOOM, das von CD-Titel Nummer 6 abgespielt wird.

WESS verwendet zwei proprietäre Dateiformate. Dies sind WMD-Dateien mit Musikpartituren und Soundeffekten sowie LCD-Dateien im PSX VAG-Format (ohne Titel) und mit ADPCM-Samples. Beim Start von DOOM lädt die libWESS-Bibliothek alle Soundeffekte (SFX, 89 Teile) und Partituren (19 Teile), die in einer kleinen Datei (55 KB) mit dem Namen DOOMSND.WMD gespeichert sind. Sie lädt auch in den SRAM "immer verwendete" Samples, die von der Figur, den Türen usw. veröffentlicht wurden.

MUSIC / DOOMSFX.LCD -> SRAM
MUSIC / DOOMSND.WMD -> DRAM

Nach dem Laden der Karte öffnet libWESS MUSIC / MUSLEV% .LCD, das die in der Musik dieser Karte verwendeten ADPCM-Samples enthält, und SNDMAPS% / MAP %%. LCD, das die ADPCM-Samples enthält, die für Feinde auf dieser Ebene benötigt werden. Alle ADPCM-Samples werden direkt in den SRAM geladen und belegen keinen Platz im DRAM.

DOOM unter PSX: GPU


Im Bereich der Videoerzeugung musste Williams Entertainment zwei Probleme lösen: eine kleine Menge VRAM (wir werden später darauf zurückkommen) und das Fehlen einer korrekten Texturabbildung unter Berücksichtigung der Perspektive.

„Aaron Siler und ich haben an Versionen für den Nintendo 64 (dieses Spiel war ganz anders) und für die Playstation gearbeitet. Dies waren die ersten Versionen, die nicht auf Bare-Metal geschrieben wurden, da sowohl Sony als auch Nintendo Entwickler (zumindest von Drittanbietern) gezwungen haben, APIs zu schreiben, und ihnen keine Dokumentation zu Hardwareregistern gaben. Anfangs beschränkte die SGI-Kultur die Entwickler besonders, doch nach und nach lockerte Nintendo seinen Griff.

Eine lustige Geschichte über die Entwicklung einer Version für die Playstation: Aaron und ich begannen mit einer anderen Engine-Architektur, die die Weltdreiecke renderte, weil die Konsole sie mit voller Hardwarebeschleunigung versorgte. Im Fall von N64 funktionierte dies perfekt, da es ein perspektivisch korrektes Rendering mit Subpixel-Genauigkeit hatte (das Ergebnis des Einflusses von SGI), aber auf der Playstation wurde eine affine Texturabbildung mit ganzzahligen Koordinaten durchgeführt, sodass die großen Wand- und Bodendreiecke FANTASTISCH aussahen. “ - John Carmack (Game Engine Black Book: DOOM)

Um zu verstehen, wie „schrecklich“ es aussah, zeigte ich unten drei Wände mit affiner und prospektiv korrekter Texturierung.


Perspektivische Texturierung


Affin (PSX)

Beachten Sie, dass es bei einer geraden Wand kein Problem gibt und mit zunehmendem Perspektivwinkel die Verzerrung stärker wahrgenommen wird.

Das gleiche Wahrnehmungsproblem hatten Rage Software-Entwickler bei der Portierung von DOOM auf SEGA Saturn.

« , id Software. , WAD Saturn, , 3D-. , , 3D- . , PC. , , : SH2 , PC, 68000 .

, » — ( DOOM Saturn) RetroGamer №134.

Da die PSX-Entwickler mehr Zeit hatten, konnten sie möglicherweise das Problem der prospektiv korrekten Texturabbildung lösen, indem sie den GPU-Polygon-Renderer in einen Linien-Renderer verwandelten.

"Ich sagte: Backup alles (damals gab es noch keine Versionskontrollsysteme!), Wir werden das Spiel komplett anders machen." Wir haben Geräte verwendet, die Dreiecke gerendert haben, die Spalten oder Zeilen mit einer Breite von einem Pixel darstellen, genau wie im Assembler-Code auf einem PC, und es hat hervorragend funktioniert. Es stellte sich heraus, dass die häufigste Lösung auf der Playstation die Tessellation der Geometrie entlang zweier Achsen war, aber ich fand es sehr gut, dass Doom weniger "nervös" wirkte als die meisten Spiele für die damalige Playstation. "- John Carmack (Game Engine Black Book: DOOM)

Dank des PSXDOOM-RE-Projekts [16] können wir herausfinden, wie es implementiert wurde. Die Rendering-Pipeline wurde komplett neu geschrieben und in zwei Phasen unterteilt. Dies wird nachstehend ausführlicher erläutert, aber wir können tatsächlich sehen, dass die Renderfunktion R_Render_Wall genau definierte Zeichenbefehle mit einer Breite von 1 Pixel überträgt.

void R_Render_Wall(...) {
  .
  int x1 = ... ; // Left end of wall.
  int x2 = ... ; // Right end of wall.
  .
  while(x1 < x2) {
    .
    setRGB0(wallpoly);

    setXY3(wallpoly,
      x1    , ypos1 - 1,
      x1 + 1, ypos2 + 1,
      x1    , ypos2 + 1);		

    setUV3(wallpoly,
         upos, v0,
         upos, v1,
         upos, v1);  
    .
    x1 += 1;
  }
}

Wände werden in ein Pixel breiten Spalten gerendert. Schauen Sie sich die API an, die dem Sofortmodus in OpenGL ähnelt.

Interessante Tatsache: Der Hardware-Designer von Sony behielt den i-Cache des MIPS-Prozessors bei, deaktivierte jedoch seinen d-Cache, um ihn in ein 1K-Hochgeschwindigkeits-Notizblock zu verwandeln. Beim Rendern von Wänden / Ebenen wurde dieses Notizbuch häufig verwendet.

VRAM-GPU-Verwaltung


Um zu erfahren, wie die VRAM-Steuerung ausgeführt wird, habe ich einen merkwürdigen Weg gewählt: Ich habe die Funktion zum Anzeigen des Echtzeit-VRAM-Emulators no $ PSX verwendet. Diese Funktion zeigt das gesamte Array von Pixeln mit 1024 x 512 x 16 Bit an (wenn auch in verzerrter Form). Die Ansichtsfunktion zeigt auch die gesamte Liste der GPU-Befehle an, die vom Zentralprozessor in jedem Rahmen übertragen werden.


No $ PSX - Gott hat uns einen Emulator geschickt, mit dem Sie in die GPU schauen können.

Durch sorgfältiges Studium des ersten VRAM-Frames können Sie viel lernen.


Das erste Bild des Spiels wird mit No $ PSX angezeigt.

Am offensichtlichsten sind zwei Bereiche mit 256 x 240 x 16 Bit in der oberen linken Ecke, die die Frame-Puffer darstellen (daher verwendet das Spiel doppelte Pufferung). Es ist erwähnenswert, dass 256x240 die niedrigste Auflösung ist, die auf einer PSX möglich ist.

Unter den Rahmenpuffern befindet sich ein bunter Satz von Pixeln - die CLUT-Palette. Beachten Sie die Rottöne. Wenn der Bildschirm rot wird, wenn der Spieler Schaden nimmt, werden vorberechnete Paletten verwendet.

In der oberen rechten Ecke sehen wir Texturen, die seltsamerweise horizontal komprimiert sind und „falsche“ Farben haben. Dies geschah, weil Texturen 8-Bit-Indizes der oben beschriebenen CLUT verwenden.

Lassen Sie uns noch einmal über Feuer in DOOM auf PS1 sprechen


2018 habe ich untersucht, wie die Wirkung von Feuer realisiert wurde [17] [ Übersetzung auf Habré]. Es war großartig, wieder zu ihm zurückzukehren, wenn ich die GPU-Befehle erkundete. Beachten Sie, dass kein $ PSX den Zielbereich jedes Befehls rot markiert.

Stufe 1: Die Flamme wird im RAM aktualisiert und in den VRAM geladen (Befehl CpuToVram).


Stufe 2: Die Flammenstruktur wird viermal entlang des Bildschirms gezeichnet (QuadTex-Befehl). Die Flammenstruktur hat eine Breite von 32 Texel, aber die GPU wird verwendet, um sie mit einer Breite von 64 Pixel zu zeichnen. Eine bilineare Filterung ist hier nicht möglich, die nächsten Texel werden abgetastet.


Stufe 3: Die endgültige DOOM-Platte (QuadTex-Befehl) wird über alles gezeichnet.


Vollbild, Team für Team


Eine Untersuchung der im Frame übertragenen Befehle ergab, dass sich die Engine vollständig von der PC-Version unterscheidet. Darin wurde die Welt aus kurzer Entfernung in die Ferne eingekreist. Zunächst werden alle Wände gerendert. Beim zweiten Durchgang wird eine vertikale Lücke zwischen ihnen (Visplane) (einschließlich des Himmels) gefüllt. In der dritten (letzten) Passage werden Sprites gerendert, beginnend mit der am weitesten entfernten. All dies wurde mit null neu gezeichneten Pixeln durchgeführt.

Unter PSX ist das Rendern etwas unhöflicher. Alles wird in einem Durchgang gerendert und von weitem ausgeführt. Das Visplane-System, mit dem der PC die Lücke zwischen den Wänden füllte, ist hier nicht vorhanden. Dank eines neuen Konzepts namens „Blätter“ werden die Ebene und die Wände in der Reihenfolge der Teilsektoren gerendert. Solche Operationen in „echtem 3D“ wurden durch die aktive Nutzung der GPE-Matrixprojektionsfunktionen möglich. Sprites werden auch gleichzeitig mit Wänden / Ebenen ohne Überlappungs- und Kürzungsprüfungen gerendert, was zu einer geringen Neuzeichnung führt.

void R_RenderPlayerView(void) {
  R_BSP();         // Phase 1
  R_RenderSKY();   // Phase 2
  for (all subsectors from phase 1) {
    R_RenderAll(subsector)
  }
  R_Render_Hud_Weapons();
}

Schauen wir uns jeden Schritt im Detail an, beginnend mit dem Himmel, der zuerst mit CopyRectRaw gerendert wird. Kein $ PSX zeigt VRAM zum Zeitpunkt der Fertigstellung des Frames an, ermöglicht es Ihnen jedoch, den Verlauf der Befehle durchzugehen. Himmelspixel sind nur sichtbar, weil kein $ PSX Probleme hat, diesen Hack mit Spalten mit einer Pixelbreite wahrzunehmen (andere Emulatoren wie ePSXe können dies nicht besser bewältigen [18] ), aber alle diese Pixel werden neu geschrieben. Beachten Sie, dass unter den Texturen des Himmels alle Markierungen der Schlüssel zu den Türen in einem Atlas gesammelt sind.


Dann wird das BSP in der Reihenfolge von weit nach nah durchlaufen. Für jeden Teilsektor werden alle Wände / Ebenen / Sprites gerendert. Wenn Sie mit DOOM BSP vertraut sind, denken Sie wahrscheinlich daran, dass der doombsp-Compiler nur feste Segmente von Teilsektoren beibehalten hat. Um das Rendern von Ebenen sicherzustellen, wurde der PSX-Version ein neues Konzept von „Blättern“ hinzugefügt, in dem BPS-Trennungssegmente (unsichtbar) gespeichert wurden. Diese Segmente werden in den Bildschirmbereich projiziert, um Ebenengrenzen zu erzeugen. Dies ist ein viel „saubererer“ Ansatz, da Sie damit Hacks mit Bildschirmplatz und Fehlern entfernen können, z. B. von der bekannten „Spur der Schnecke“.


In der nächsten VRAM-Aufnahme werden Flugzeuge aus demselben Teilsektor wie die Wand, die wir oben gesehen haben, als 1 Pixel hohe Dreiecke gerendert. Achten Sie auch auf die Textur der Wände / Ebenen, sie haben alle die gleiche Größe. Diese Funktion vereinfacht die Auswahl von VRAM-Texturen und vermeidet Fragmentierung.


Wir sind immer noch im selben Teilsektor. Jetzt werden Sprites als Vierecke (Quad) gerendert. Zu diesen Sprites gehören Feinde, Muscheln und teilweise transparente Wände.


Zum Spaß zeigen wir Plasmaschalen.


Wir nähern uns dem Ende der Rendering-Befehle. Hier wird durch Mischen des Rechtecks ​​die Waffe gerendert.


Letzter Schritt: Interface Rendering (HUD).


VRAM-Überlauf!



Die Arbeit mit der GPU war eine Übung zur Zuweisung von Speicherplatz in VRAM. Bei Frame-Puffern, CLUT, statischem Inhalt (Schnittstelle) und sogar Wänden / Ebenen ist die Aufgabe elementar, da sie alle dieselbe Größe haben. Aber mit Sprites sind die Dinge etwas komplizierter.

Aufgrund der Tatsache, dass Sprites unterschiedliche Größen haben, führen sie zur Fragmentierung. Darüber hinaus können Texturen große Bereiche des Bildschirms abdecken und sich wiederholen, und Sprites sind häufig einzigartig, und in jedem Frame kann eine unvorhersehbar große Anzahl von ihnen erforderlich sein. Im schlimmsten Fall erfordert ein Frame eine bestimmte Anzahl von Sprites, die nicht in VRAM platziert werden können. Dies wird als Textur-Cache-Überlauf bezeichnet, und dieses Problem kann nicht gelöst werden. In diesem Fall stürzt das Spiel ab und zeigt eine kryptische Fehlermeldung an [19].einige von uns an das ominöse „No more visplanes“ erinnern.


Je mehr Sprites gleichzeitig angezeigt werden, desto mehr VRAM wird verwendet.

Der Unterschied zwischen PAL und NTSC


Zum Abschluss des Videokapitels habe ich mich entschlossen zu sehen, wie NTSC in PAL konvertiert wird. Leider hat das DOOM PSX, wie in vielen anderen Spielen, die Erhöhung der vertikalen Auflösung nicht berücksichtigt. Beim Spielen von DOOM auf PS1 in Europa haben Sie ein vertikal komprimiertes Bild mit auffälligen schwarzen Rändern gesehen.

Nachdem ich die Prinzipien von VRAM kennengelernt habe, fällt es mir schwer, den Entwicklern die Schuld zu geben. Wenn Sie sich das VRAM-Schema in NTSC genau ansehen, werden Sie feststellen, dass das Erhöhen der vertikalen Auflösung des Bildpuffers die gesamte Datenzuordnungsstruktur verletzt. Es wäre unmöglich, Texturen darunter zu speichern. Oder Sie müssten CLUT an einen anderen Ort verschieben. Zu viel Kosten bei relativ geringem Nutzen, und trotz der Tatsache, dass die schwarzen Ränder das Spiel störten, stimme ich zu, dass es sich nicht gelohnt hat.

Danksagung


Vielen Dank an Eric Vazquez (Autor von PSXDOOM-RE), Samuel Villarreal (einer der Entwickler von PSXDOOM-RE) und Dan Leslie (professioneller Entwickler von Spielen für PlayStation 1) für den großzügigen Austausch ihres Wissens mit mir.


All Articles