Sony PlayStation
L'histoire de la PlayStation a commencé en 1988 lorsque Nintendo et Sony ont commencé à travailler ensemble sur un lecteur de CD-ROM en option pour la console SNES. Aux termes de l'accord, Sony a pu développer indépendamment des jeux pour cette plate-forme et a conservé le contrôle du format Super Disc - deux concessions inhabituelles de Nintendo.Le projet s'est développé avant l'exposition CES '91, au cours de laquelle Sony a annoncé une collaboration sur Play Station. Le lendemain, lors de la même exposition, Nintendo, à la surprise de Sony, a annoncé qu'il avait plutôt conclu un accord de partenariat avec Philips (à des conditions beaucoup plus favorables). Sony, fidèle et humilié publiquement, a tenté de faire appel au conseil d'administration de Sega, qui a immédiatement rejeté l'idée. Dans une interview accordée à 2013, le PDG de SEGA, Tom Kalinske, a rappelé la décision du conseil.«C'est une idée stupide, Sony ne sait pas comment développer des équipements. Ils ne savent pas écrire de logiciels. Pourquoi jouons-nous avec eux? " - Conseil d'administration de SEGA
Et ils ne se sont pas trompés, Sony avait vraiment peu d'expérience avec les jeux. Elle n'a presque pas manifesté d'intérêt pour eux, à l'exception de l'initiative d'une personne - Ken Kutaragi. Depuis le moment où il a vu sa fille jouer à la Nintendo Famicom, Ken a convaincu Sony qu'il devait pénétrer ce marché. Malgré les recommandations des vice-présidents de Sony, il a même développé pour Nintendo la puce audio (SPC700) utilisée dans SNES.La plupart des dirigeants de Sony considéraient cela comme un pari risqué, mais Kutaragi a trouvé un soutien en la personne du PDG de Sony, Norio Oga. En juin 1992, Ken a été autorisé à commencer à créer un système de jeu à partir de zéro. Pour calmer le conseil d'administration, le «père de la PlayStation», comme ils l'appelèrent plus tard, a été transféré à la société mère financièrement indépendante Sony Music, et il a commencé à travailler sur ce qui allait devenir la «PlayStation» (déjà sans espace au nom).Initialement, les développeurs ne pouvaient pas décider si l'architecture devait se concentrer sur les graphiques sprite 2D ou les graphiques polygonaux 3D. Cependant, le succès du jeu Virtua Fighter sorti en octobre 1993 par Sega sur des machines d'arcade japonaises a détruit tous les doutes: la PSX suivra la voie 3D.Le point culminant du projet est survenu deux ans plus tard, lorsque Sony Computer Entertainment a été créé le 3 décembre 1994 et que la console a été lancée au Japon. Il a connu un succès instantané et a été vendu le premier jour avec une circulation de 100 000 appareils, 2 millions d'appareils au bout de six mois et 102 millions d'appareils tout au long de leur vie.Sony PSX (PS1, PlayStation). Photo: WikipediaArchitecture
Le cœur de la machine est le processeur MIPS 32 bits RISC R3000A avec une fréquence de 33,8688 MHz [3] en combinaison avec 2 Mo de DRAM. Il est à noter que cette puce possède également un décodeur de mouvement (MDEC), qui fournit une lecture vidéo avec une résolution de 320x240 à une fréquence de 30 ips. À côté de MDEC, nous voyons le coprocesseur Geometry Transform Engine (GTE), utilisé pour effectuer des opérations mathématiques à virgule fixe rapides sur des vecteurs et des matrices. Le système dans son ensemble est incapable de travailler avec des nombres à virgule flottante.Le GPU est une «boîte noire» contrôlée par le processeur central à l'aide de «commandes». Il dispose de 1 Mo de VRAM, non disponible pour le processeur. À bien des égards, son travail ressemble à celui du merveilleux mode Immédiat OpenGL: il dessine des polygones texturés qui peuvent être «ombrés» en utilisant des couleurs de vertex. Le pipeline graphique est fixe et ne peut pas être programmé. Il n'y a pas de tampon Z (tampon de profondeur).L'unité de traitement du son, l'unité de traitement du son (SPU), comme le GPU, est une boîte noire. Il peut traiter 24 canaux, dispose de 512 Ko de SRAM pour le stockage audio (au format ADPCM) et est capable de mélanger des pistes audio de CD-ROM avec ses canaux audio. L'abréviation SRAM ne signifie pas «RAM statique», mais «RAM sonore».La décision la plus audacieuse des ingénieurs Sony a été le choix du support de données. Ils ont choisi non pas des cartouches, mais un module CD-ROM à double vitesse, ce qui a réduit le coût des jeux et augmenté considérablement le volume disponible (jusqu'à environ 650 Mo). Les inconvénients sont le faible taux de transfert (300 Ko / s) et le temps d'installation monstrueusement important de la tête (300 ms).Il n'y a aucun blitter dans la console. Le modèle de programmation de la machine était que les développeurs n'avaient pas touché le fer "nu". Cependant, il existe un contrôleur DMA pour transmettre des données de CD / DRAM à VRAM / SRAM.Système vidéo
Malgré le fait que le système vidéo supporte les couleurs 24 bits, très peu de jeux l'ont utilisé (à l'exception des arrière-plans de Heart Of Darkness [4] ). En pratique, on peut dire en toute conscience que la plupart des jeux utilisaient des couleurs 16 bits avec un masque 1 bit.Espace colorimétrique PSX avec une profondeur de 15 bits par pixelUne caractéristique étonnante du système vidéo est l'organisation de la VRAM, qui dépend complètement du développeur. 1 Mo de VRAM est considéré comme un tableau de 1024 x 512 x 16 bits pouvant être librement utilisé. L'application de la mise en mémoire tampon double ou triple est effectuée de manière triviale, car la zone est simplement suffisante pour réserver, dessiner et transférer vers le système de sortie. Les textures sont également en VRAM, à côté des tampons de trame. Pour écrire dans le tampon de trame, les commandes GPU pour le rendu des triangles / quadrangles texturés sont lancées.Les textures peuvent avoir différents formats. Il existe deux sources directes de couleurs 16 bits et 24 bits, ainsi que des sources basées sur une palette appelée Color Look Up Table (CLUT). Les CLUT 8 bits et 4 bits sont pris en charge.En termes de résolution, la console était limitée aux normes de télévision NTSC et PAL. Pour les marchés américain et japonais, le développeur peut choisir une résolution horizontale de 256, 320, 384, 512 ou 640 pixels. La résolution verticale était de 240 pixels (lors du saut d'une ligne raster sur deux) ou de 480 pixels en alternance. Les deux modes verticaux fonctionnaient à une fréquence de 60 Hz. La seule différence entre NTSC et PAL était une résolution verticale accrue (256/512 au lieu de 240/480) et une fréquence de rafraîchissement inférieure (50 Hz).Mode NTSC (60 Hz) PAL (50 Hz) Remarque
=================================================== ========
0 256 x 240 256 x 256 Non entrelacé
1320 x 240320 x 256 non entrelacé
2 512 x 240 512 x 256 non entrelacé
3 640 x 240 640 x 256 Non entrelacé
4 256 x 480 256 x 512 entrelacé
5320 x 480320 x 512 entrelacé
6 512 x 480 512 x 512 entrelacé
7640 x 480640 x 512 Entrelacé
8 384 x 240 384 x 256 non entrelacé
9 384 x 480 384 x 512 entrelacé
Faites attention aux modes avec une résolution horizontale de 384 pixels (8 et 9), qui, à en juger par leur identifiant, ont été ajoutés plus tard.DOOM sur PSX
DOOM a été porté sur PSX par Williams Entertainment avec le soutien d'id Software. Il a fallu une équipe de cinq personnes un peu moins d'un an [5] [6] pour porter le moteur, changer les ressources et modifier le jeu pour que tout fonctionne «seulement» sur 3,5 Mo de RAM.«Les graphismes ont été dégradés: les textures sont réduites en taille, les sprites, les monstres et les armes aussi. [...] Parfois, nous coupons des images d'animation. " - Harry Tisley
Le résultat final a été rendu public le 16 novembre 1995. Il est considéré comme le meilleur port console du jeu, et certains aspects dépassent même la version PC en raison des hauts de couleur et de la musique de qualité CD."Jusqu'à présent, c'est le meilleur DOOM!" - John Romero
Plan d'étude
En raison de la nature du développement, la structure DOOM est basée sur un noyau qui utilise six sous-systèmes pour les E / S. La plupart du temps, j'ai étudié les trois parties que j'ai trouvées les plus intéressantes, à savoir le système de fichiers sur CD-ROM, l'audio basé sur SPU et la vidéo basée sur GPU, car ils sont uniques à l'architecture PSX.Le code source DOOM pour la PSX n'a jamais été publié, mais il s'est avéré que cela ne posait aucun problème. Les informations disponibles suffisent.La première source est le superbe SDK PSY-Q, qui était l'outil «officiel» utilisé par les développeurs PSX de l'époque. Il y a beaucoup de documentation à ce sujet, présentée comme un ensemble de fichiers PDF. Une telle abondance d'informations ne fait que confirmer tout le bien que j'ai entendu à propos de la convivialité de la PSX envers les développeurs. La bibliothèque (c'est-à-dire libcd, libds) développée par Psygnosis est également bien documentée. C'était très agréable de voir des explications claires, surtout par rapport au manque presque complet d'informations sur les autres consoles (oui, je parle de SNES).Une autre source d'information est les nombreux outils externes disponibles aujourd'hui. ISOBuster m'a permis d'ouvrir le contenu du CD. PSound a aidé à analyser les fichiers LCD. La capacité étonnante de l'émulateur no $ PSX de suivre les commandes GPU et SPU est devenue un véritable atout.Mais j'ai peut-être été le plus impressionné par l'énorme amour de DOOM pour PSX de la part des fans. Une ingénierie inverse complète du jeu a été réalisée. PSXDOOM-RE se démarque surtout parce qu'il s'agit d'une base de code C qui peut être compilée à l'aide du SDK PSY-Q dans un jeu PSX à part entière. Le code est très fiable car il a été obtenu en réécrivant chaque fonction du code machine en C.Le monde étonnant des CD
Avant de commencer à étudier la mise en œuvre du système de fichiers, j'ai fait une petite excursion pour mieux comprendre le monde merveilleux des CD.Depuis 20 ans, de 1980 à 2000, plusieurs volumes de spécifications ont été publiés qui révèlent ce sujet. Ensemble, ils s'appellent «Rainbow Books». Le premier livre de la série, «Red Book», contient les spécifications d'un disque compact audio (CD). Le «Livre jaune» est un complément au «Livre rouge», il ajoute des spécifications de données pour CD-ROM et ISO-9600. L'Orange Book a ajouté des spécifications pour les CD-DA, CD-R (enregistrables) et CR-WR (réinscriptibles). Le livre blanc est dédié au CD vidéo (VCD). Le Livre vert parle de CD-Interactive (CD-I). Le Blue Book présente des données de CD amélioré (ECD) pour la prise en charge multimédia. Le Scarlet Book est dédié au Super Audio (SACD), qui ajoute un son haute définition. Le Purple Book répertorie la spécification Double Density CD (DDCD), qui a augmenté la capacité du disque de 650 Mo à 1,3 Go. Finalement,Cyan Book détails 9660 spécifications du système de fichiers[7] .Rainbow Books contient tout ce que nous savons sur le CD.Au minimum, nous devons comprendre que les CD PSX se composent généralement de secteurs, chacun contenant 2048 octets de données. Les secteurs sont regroupés en pistes (qui peuvent être des données ou du son). Les pistes sont regroupées en session. Les informations des pistes de données peuvent être organisées à l'aide du système de fichiers standard ISO-9660, cependant, le jeu peut également avoir des adresses de secteur codées en dur.À l'intérieur du CD de jeu DOOM
Si vous regardez à l'intérieur du CD-ROM en utilisant ISOBuster, vous pouvez voir que DOOM se compose d'une session contenant huit pistes [8] . Sept d'entre eux sont des pistes sonores de qualité CD jouées entre les missions et dans la scène finale. La piste finale (# 7) utilise même des voix démoniaques numérisées. La piste numéro 6 est particulièrement remarquable car elle semble avoir été prise directement de la rave party. Il s'avère qu'il s'agit de musique jouée sur la carte super secrète 59 «Club DOOM» (une carte secrète accessible uniquement à partir d'une carte secrète) [9] . Permettez-moi de vous laisser apprécier sa folie. Avant de commencer, vérifiez le volume sonore.La piste restante (numéro 1) est ISO-9660, qui contient le moteur de jeu et la plupart des ressources. Après avoir exploré les nombreux ports DOOM, je m'attendais naïvement à un moteur appelé DOOM.EXE, un fichier de ressources PSXDOOM.WAD et peut-être un manifeste. Je me trompais beaucoup. 287 fichiers [10] [11] ont été trouvés sur la piste , dont 60 .WAD, 120 .IMG et d'innombrables .LCD.Les données sont classées par niveau (cinq fichiers par carte).Nom du fichier Description
=================================================== =====
MAPDIR0 / MAP01.WAD Géométrie standard (BSP / Rejeter / ...)
MAPDIR0 / MAPTEX01.IMG Textures des plans / murs
MAPDIR0 / MAPSPR01.IMG Tous les sprites créés par THINGS
MUSIQUE / MUSLEV1.LCD Musique jouable
SNDMAPS1 / MAP01.LCD Tous les sons émis par THINGS
Lorsqu'on lui a demandé pourquoi tout avait été arrangé d'une nouvelle manière, le développeur de Crash Bandicoot Andy Gavin a partiellement répondu dans une interview avec Ars Technica. [ traduction sur Habré]"Il faut environ 1/3 de seconde pour déplacer la tête vers n'importe quel point du CD."
En raison du fait que la vitesse de positionnement de la tête était proche de 300 ms (ce qui est confirmé par la documentation PSY-Q [12] ), les développeurs de Williams Entertainment n'ont pas pu enregistrer l'architecture claire du moteur DOOM, qui stockait toutes les ressources dans un fichier (par exemple, DOOM.WAD) et les a téléchargés sur demande. Sur PSX, cela conduirait à un taux de trame terrible.Les développeurs ont résolu le problème en lançant une quantité apparemment infinie d'octets sur le CD. Toutes les ressources nécessaires au niveau ont été stockées dans cinq fichiers contenant la géométrie de la carte, la texture. sprites, effets sonores et musique. C'est très cher, mais cela a éliminé la nécessité d'accéder au CD pendant le processus de jeu.Fait intéressant:dans la liste des fichiers sur la piste de données, il y a un fichier appelé PSXDOOM.WAD (4 806 088 octets), mais il n'est utilisé que pour charger des palettes et plusieurs images de menu. Probablement plus activement utilisé dans le processus de développement.Prenons l'exemple de la première carte: la quantité totale de données téléchargées est passée de 4 Mo à 900 Ko.Taille du nom de fichier (en octets)
=====================================
MAPDIR0 / MAP01.WAD 28 196
MAPDIR0 / MAPTEX01.IMG 90 744
MAPDIR0 / MAPSPR01.IMG 590 344
MUSIQUE / MUSLEV1.LCD 61232
SNDMAPS1 / MAP01.LCD 143632
=====================================
Total: 914.148
Sachant que les ressources occupent 914 Ko, vous pourriez penser qu'il restait beaucoup de DRAM inutilisée. Mais vous devez vous rappeler qu'il devait également contenir un fichier exécutable de 428 Ko, ainsi qu'une pile qui change au moment de l'exécution. En fait, seulement environ 1 Mo de DRAM était disponible au moment de l'exécution.Un fait intéressant: en examinant le code source de PSXDOOM-RE, j'ai découvert la fonction P_LoadBlocks, qui essaie de lire un CD jusqu'à quatre fois [13] , après quoi elle se rend. C'est l'un des plaisirs de travailler avec des supports faciles à rayer.Je ne m'attendais pas à ce que le temps d'installation de la tête du CD-ROM affecte autant l'architecture du jeu. Certains jeux, comme Crash Bandicoot, ont été créés à partir de zéro avec un système de page pour diffuser des données à partir d'un CD lors de l'exécution. Dans le cas de DOOM, le moteur n'en était pas capable. Le CD n'est pas utilisé pendant le jeu, à l'exception d'une chanson particulière (oui, du niveau Club DOOM).Les gars d'id Software n'ont jamais été fan du compromis entre la capacité et la vitesse qu'offraient les CD-ROM.« - . , CD. - , Crash 'n Burn — ? . , CD , 3DO . - CD- DOOM, „ DOOM“. , . .
, CD. ». — (ATARI EXPLORER ONLINE, 22 1994 )
Un fait intéressant: les événements dans le jeu DOOM ont été déclenchés à l'aide de «vergetures». Lors du franchissement d'une ligne avec une propriété spéciale, une fonction spéciale a été appelée. Dans la version "héritée" du moteur, aucune propriété ne vous permettait de jouer des chansons. Pour jouer au Club DOOM, une action linedef spéciale a été créée (numéro 142) [14] . C'est incroyable combien d'efforts supplémentaires ont été nécessaires pour créer ce niveau. Probablement, les développeurs ont vraiment aimé s'amuser dans les raves.Le cas de l'archvile manquant
En effectuant des recherches pour mon livre noir Game Engine, je ne pouvais pas comprendre cette phrase du designer Harry Teesley:«Archvile avait deux fois plus d'images d'animation que n'importe quel autre monstre, et nous ne pouvions pas l'intégrer dans la PSX. Ni son attaque ni l'effet de résurrection ne pouvaient être perdus. Il était trop grand. " - Harry Tisley (designer) dans une interview avec doomworld.com
Il était évident que le problème n'était pas la capacité de 650 mégaoctets du CD, mais je ne comprenais pas quel était le facteur limitant - DRAM ou VRAM.Ayant compris les limites du CD-ROM, j'ai réalisé que le problème n'était pas de stocker le sprite sur un CD, ni même de le transférer de la DRAM vers la VRAM. Le problème est de tout intégrer dans la DRAM.Fait intéressant: ArchVile est complètement supprimé du code source de PSXDOOM-RE. Même son #DEFINE est commenté [15] .#define CC_ZOMBIE "Zombieman"
#define CC_SHOTGUN "Shotgun Guy"
#define CC_HEAVY "Heavy Weapon Dude"
...
#define CC_HELL "Hell Knight"
#define CC_SPIDER "The Spider Mastermind"
#define CC_CYBER "The Cyberdemon"
#define CC_HERO "Our Hero"
Programmation SPU
La puce SPU ne comprend qu'un seul format, à savoir ADPCM. Il est capable de mixer jusqu'à 24 canaux (y compris la piste audio CD) et possède de puissantes fonctions de manipulation audio.Pour apprivoiser cette bête, le DOOM PSX utilise la bibliothèque libWESS (Williams Entertainment Sound System), écrite par l'ingénieur du son Scott Patterson. La bibliothèque est assez puissante, elle est capable de recréer le système MiDI, dans lequel une lourde banque de notes (appelée police sonore) est contrôlée par une partition musicale qui prend peu de place. Il peut également manipuler des attributs sonores en temps réel tels que le volume, la tonalité, la vitesse de la note et les fonctions ADSR (Attack, Decay, Sustain et Release). Toute la musique jouée pendant le jeu est générée à l'aide de libWESS. À une exception près, vous l'aurez deviné, il s'agit du Club DOOM, qui est lu à partir du CD numéro 6.WESS utilise deux formats de fichiers propriétaires. Il s'agit de fichiers .WMD contenant des partitions musicales et des effets sonores, et des fichiers .LCD, qui sont au format PSX VAG (sans titre) et contiennent des échantillons ADPCM. Lorsque DOOM démarre, la bibliothèque libWESS charge tous les effets sonores (SFX, 89 pièces) et les partitions musicales (19 pièces) stockées dans un petit fichier (55 Ko) appelé DOOMSND.WMD. Elle charge également dans les échantillons SRAM «toujours utilisés» publiés par le personnage, les portes, etc.MUSIQUE / DOOMSFX.LCD -> SRAM
MUSIQUE / DOOMSND.WMD -> DRAM
Après avoir chargé la carte, libWESS ouvre MUSIC / MUSLEV% .LCD, qui contient les échantillons ADPCM utilisés dans la musique de cette carte, et SNDMAPS% / MAP %%. LCD, qui contient les échantillons ADPCM nécessaires pour les ennemis à ce niveau. Tous les échantillons ADPCM sont chargés directement dans SRAM et ne prennent pas d'espace dans la DRAM.DOOM sur PSX: GPU
Dans le domaine de la génération de vidéos, Williams Entertainment devait résoudre deux problèmes: une petite quantité de VRAM (nous y reviendrons plus tard) et le manque de mappage de texture correct en tenant compte de la perspective.«Aaron Siler et moi avons travaillé sur des versions pour la Nintendo 64 (ce jeu était assez différent) et pour la Playstation. Ce sont les premières versions qui n'ont pas été écrites sur du métal nu, car Sony et Nintendo ont forcé les développeurs (au moins des tiers) à écrire des API et ne leur ont pas fourni de documentation sur les registres matériels. Au début, la culture SGI a particulièrement limité les développeurs, mais progressivement Nintendo a desserré son emprise.
Une histoire amusante sur le développement d'une version pour la Playstation: Aaron et moi avons commencé avec une architecture de moteur différente, qui rendait les triangles du monde, car la console leur fournissait une accélération matérielle complète. Dans le cas de N64, cela fonctionnait parfaitement, car il avait un rendu correct en perspective avec une précision sous-pixel (le résultat de l'influence de SGI), mais sur la Playstation, le mappage de texture affine a été effectué avec des coordonnées entières, de sorte que les grands triangles de mur et de sol avaient l'air IMPRESSIONNANTS. » - John Carmack (Game Engine Black Book: DOOM)
Pour comprendre à quel point cela avait l'air «terrible», j'ai montré ci-dessous trois murs rendus avec une texture affine et prospectivement correcte.Texturation en perspectiveAffine (PSX)Notez qu'il n'y a aucun problème avec un mur droit et que l'angle de perspective augmente, la distorsion devient plus perceptible.Le même problème de perception s'est posé aux développeurs de Rage Software lors du portage de DOOM vers SEGA Saturn.« , id Software. , WAD Saturn, , 3D-. , , 3D- . , PC. , , : SH2 , PC, 68000 .
, » — ( DOOM Saturn) RetroGamer №134.
Peut-être, puisque les développeurs PSX ont eu plus de temps, ils ont pu résoudre le problème du mappage de texture prospectivement correct en transformant le rendu de polygone GPU en rendu de ligne."J'ai dit: tout sauvegarder (alors il n'y avait pas encore de système de contrôle de version!), Nous rendrons le jeu complètement différent." Nous avons utilisé un équipement qui rendait des triangles représentant des colonnes ou des lignes d'un pixel de large, tout comme dans le code assembleur sur un PC, et cela fonctionnait très bien. Il s'est avéré que la solution la plus courante sur la Playstation était la tessellation de la géométrie sur deux axes, mais j'ai vraiment aimé que Doom semblait moins "nerveux" que la plupart des jeux pour la Playstation de l'époque. "- John Carmack (Game Engine Black Book: DOOM)
Grâce au projet PSXDOOM-RE [16], nous pouvons découvrir comment il a été mis en œuvre. Le pipeline de rendu a été complètement réécrit et divisé en deux étapes. Ceci sera discuté plus en détail ci-dessous, mais nous pouvons réellement voir que la fonction de rendu R_Render_Wall transmet des commandes de dessin bien définies avec une largeur de 1 pixel.void R_Render_Wall(...) {
.
int x1 = ... ;
int x2 = ... ;
.
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;
}
}
Les murs sont rendus dans des colonnes d'un pixel de large. Découvrez l'API, qui ressemble au mode Immédiat dans OpenGL.Fait intéressant: le concepteur matériel de Sony a conservé l'i-cache du processeur MIPS, mais a désactivé son d-cache pour en faire un bloc-notes à grande vitesse 1K. Les procédures de rendu des murs / plans ont largement utilisé ce bloc-notes.Gestion GPU VRAM
Pour savoir comment le contrôle VRAM est effectué, j'ai choisi une méthode curieuse: j'ai utilisé la fonction de visualisation de l'émulateur VRAM en temps réel non $ PSX. Cette fonction affiche l'intégralité du tableau de pixels 1024 x 512 x 16 bits (bien que sous une forme déformée). La fonction de visualisation affiche également la liste complète des instructions GPU transmises par le processeur central dans chaque trame.No $ PSX - Dieu nous a envoyé un émulateur qui vous permet de regarder à l'intérieur du GPU.Une étude approfondie de la première image VRAM vous permet d'apprendre beaucoup.La première image du jeu s'affiche avec No $ PSX.Les plus évidents sont deux zones de 256 x 240 x 16 bits dans le coin supérieur gauche, qui sont les tampons de trame (par conséquent, le jeu utilise une double mise en mémoire tampon). Il convient de noter que 256x240 est la résolution la plus basse possible sur un PSX.Sous les tampons de cadre se trouve un ensemble coloré de pixels - la palette CLUT. Notez les nuances de rouge, cela signifie que lorsque l'écran devient rouge lorsque le joueur subit des dégâts, des palettes pré-calculées sont utilisées.Dans le coin supérieur droit, nous voyons des textures étrangement compressées horizontalement et qui ont de «mauvaises» couleurs. Cela s'est produit parce que les textures utilisent des indices 8 bits du CLUT décrits ci-dessus.Parlons à nouveau du feu dans DOOM sur PS1
En 2018, j'ai étudié comment l'effet du feu a été réalisé [17] [ traduction sur Habré]. C'était génial de lui revenir lors de l'exploration des commandes du GPU. Notez qu'aucun $ PSX ne marque la zone cible de chaque commande en rouge.Étape 1: la flamme est mise à jour en RAM et chargée en VRAM (commande CpuToVram).Étape 2: la texture de la flamme est dessinée quatre fois le long de l'écran (commande QuadTex). La texture de la flamme a une largeur de 32 texels, mais le GPU est utilisé pour la dessiner avec une largeur de 64 pixels. Le filtrage bilinéaire n'est pas possible ici, les texels les plus proches sont échantillonnés.Étape 3: la plaque finale DOOM (commande QuadTex) est dessinée au-dessus de tout.Plein cadre, équipe par équipe
Une étude des commandes transmises dans le cadre a montré que le moteur est complètement différent de la version PC. Dans ce document, le monde a été entouré d'une courte distance dans la distance. Tout d'abord, tous les murs sont rendus. Au deuxième passage, un espace vertical est comblé entre eux (visplane) (y compris le ciel). Dans le troisième (dernier) passage, les sprites sont rendus, en commençant par le plus éloigné. Tout cela a été fait avec zéro pixel de redessin.Sur PSX, le rendu est un peu plus grossier. Tout est rendu en un seul passage, exécuté à partir de loin. Le système de visplane utilisé par le PC pour combler le vide entre les murs n'est pas là. Grâce à un nouveau concept appelé «feuilles», le plan et les murs sont rendus dans l'ordre des sous-secteurs. De telles opérations en «vrai 3D» sont devenues possibles grâce à l'utilisation active des fonctions de projection matricielle GPE. Les sprites sont également rendus simultanément avec les murs / plans sans contrôles de chevauchement et de troncature, ce qui entraîne une petite quantité de redessin.void R_RenderPlayerView(void) {
R_BSP();
R_RenderSKY();
for (all subsectors from phase 1) {
R_RenderAll(subsector)
}
R_Render_Hud_Weapons();
}
Examinons chaque étape en détail, en commençant par le ciel, qui est d'abord rendu à l'aide de CopyRectRaw. aucun $ PSX ne montre VRAM à la fin de la trame, mais vous permet de revenir dans l'historique des commandes. Les pixels du ciel ne sont visibles que parce qu'aucun $ PSX n'a de problèmes à percevoir ce hack avec des colonnes d'une largeur de pixel (d'autres émulateurs, tels que ePSXe, ne peuvent pas mieux faire face [18] ), mais tous ces pixels seront réécrits. Notez que sous les textures du ciel tous les marqueurs des clés des portes sont rassemblés dans un atlas.Ensuite, le BSP est parcouru dans l'ordre de loin à près. Pour chaque sous-secteur, tous les murs / plans / sprites sont rendus. Si vous êtes familier avec DOOM BSP, alors souvenez-vous probablement que le compilateur doombsp ne gardait que des segments solides de sous-secteurs. Pour assurer le rendu des avions, un nouveau concept de «feuilles» a été ajouté à la version PSX, dans lequel les segments de séparation BPS (invisibles) étaient stockés. Ces segments sont projetés dans l'espace d'écran pour générer des limites planes. C'est une approche beaucoup plus «propre», car elle vous permet de vous débarrasser des hacks avec de l'espace d'écran et des bugs, par exemple, de la fameuse «piste de limace».
Débordement de VRAM!
Travailler avec le GPU était un exercice d'allocation d'espace dans la VRAM. Dans le cas des tampons de cadre, CLUT, du contenu statique (interface) et même des murs / plans, la tâche est élémentaire, car ils ont tous la même taille. Mais avec les sprites, les choses sont un peu plus compliquées.Du fait que les sprites ont des tailles différentes, ils conduisent à la fragmentation. De plus, les textures peuvent couvrir de grandes zones de l'écran et se répéter, et les sprites sont souvent uniques et un nombre imprévisible d'un grand nombre d'entre eux peut être requis dans chaque image. Dans le pire des cas, une trame nécessite un certain nombre de sprites qui ne peuvent pas être placés dans VRAM. Cela s'appelle un débordement de cache de texture et ce problème ne peut pas être résolu. Lorsque cela se produit, le jeu se bloque et affiche un message d'erreur cryptique [19]rappelant à certains d’entre nous le sinistre «Plus de visplans».Plus vous voyez de sprites en même temps, plus la VRAM est utilisée.La différence entre PAL et NTSC
En conclusion du chapitre vidéo, j'ai décidé de voir comment NTSC est converti en PAL. Malheureusement, comme dans beaucoup d'autres jeux, le DOOM PSX n'a pas pris en compte l'augmentation de la résolution verticale. Lors de la lecture de DOOM sur PS1 en Europe, vous avez vu une image compressée verticalement avec des bordures noires visibles.Après avoir appris les principes de la VRAM, il m'est difficile de blâmer les développeurs. Si vous regardez attentivement le schéma VRAM dans NTSC, vous remarquerez que l'augmentation de la résolution verticale du tampon de trame viole la structure d'allocation de données entière. Il serait impossible de stocker des textures en dessous. Ou vous devez déplacer CLUT vers un autre emplacement. Trop cher avec relativement peu d'avantages, et même en dépit du fait que les bordures noires interféraient avec le jeu, je conviens que cela n'en valait pas la peine.Remerciements
Merci à Eric Vazquez (auteur de PSXDOOM-RE), Samuel Villarreal (l'un des développeurs de PSXDOOM-RE) et Dan Leslie (développeur professionnel de jeux pour PlayStation 1) pour avoir généreusement partagé leurs connaissances avec moi.