Préface du rédacteur en chef (Guillaume Verdin) : Même si j’aurais bien aimé que ma chronique consacrée à Yutaka Sugano reste encore plus longtemps sur l’accueil du Mag, il faut savoir passer la main et c’est moins difficile quand il s’agit d’un sujet qui me tient à cœur, la Saturn. Comme c’est la console de mon adolescence, la période des désillusions, sa rivalité avec la PlayStation a été particulièrement difficile à vivre, et l’on ne peut pas dire que la presse ait facilité les choses, car même ceux qui défendaient la console de SEGA faisaient preuve de mauvaise foi, ou du moins d’un manque de connaissances à une époque où Internet était balbutiant… On a tous entendu qu’elle était difficile à programmer, ce qui est vrai, mais aussi qu’elle n’avait pas été pensée pour la 3D, ce qui m’a toujours semblé bizarre de la part de la compagnie qui a été pionnière dans le domaine en arcade ! Alors que depuis la PlayStation, aucune console hormis certaines portables comme la GBA et la DS ne dispose de hardware dédié à la 2D et l’affiche donc de la même manière que la 3D avec des polygones sur un plan, j’avais entendu dire que la Saturn profitait de ses capacités 2D pour faire le contraire, afficher des polygones à l’aide de sprites. Ce qui n’est pas tout à fait faux, mais réducteur puisqu’il ne s’agit pas de 2D classique à base de tuiles… Mais c’est ce que vous allez voir dans cette chronique particulière, moins orientée histoire du jeu vidéo que d’habitude, et qui a le mérite de vulgariser la programmation 3D d’une manière qui me semble claire et accessible.
Oui, la Saturn a été pensée pour la 3D
Il existe une idée répandue selon laquelle la SEGA Saturn est une machine puissante pour la 2D, mais peu douée pour la 3D, car ces capacités auraient été ajoutées après coup et dans l’urgence. Cet article va essayer de démontrer qu’au contraire, SEGA prenait la 3D très au sérieux et que la Saturn a été conçue pour être compétente dans ce domaine. Des erreurs ont été commises, mais pas parce que les ingénieurs ont tout misé sur la 2D ou qu’ils étaient incompétents.
L’aube de la 3D
Les principes permettant d’afficher des images 3D sur un écran d’ordinateur étaient bien connus dès la fin des années 70. Deux grandes approches sont possibles :
- Le raytracing, qui simule les propriétés physiques de la lumière et ses interactions avec la matière. Les algorithmes sont relativement simples, mais la puissance de calcul nécessaire pour produire des images en temps réel est restée hors de portée jusqu’à récemment. Elle ne sera pas abordée ici.
- La rastérisation, un ensemble d’astuces pour approximer une couleur réaliste pour les pixels affichés à l’écran. La qualité dépend de la puissance de calcul disponible et de la complexité des algorithmes utilisés.
Avant la 5ème génération de consoles
La « 5ème génération » de consoles (NdR : celle de la PlayStation et la Saturn) a été la première à généraliser le matériel dédié au rendu 3D par rastérisation. Auparavant, tout était calculé de façon logicielle. Les algorithmes devenant de plus en plus complexes et « réalistes » au fur et à mesure de l’augmentation de la puissance des machines.
Les ordinateurs personnels étaient adaptés au rendu 3D grâce à leur framebuffer, une mémoire accessible en lecture par le circuit vidéo dans laquelle le CPU écrit l’intégralité de l’image à afficher.
À l’inverse des micros, les consoles 8 et 16 bits ne possédaient pas de framebuffer afin d’économiser de la mémoire, très onéreuse. Conçues pour afficher des jeux 2D à scrolling de la manière la plus efficace possible, elles utilisaient un système de tuiles afin de générer une image de façon synchronisée avec le balayage de l’écran cathodique.
Mais le rendu 3D ne fonctionne pas ainsi : les images calculées ne peuvent être affichées à l’aide d’un jeu de tuiles restreint. La seule possibilité est de calculer l’image dans une zone mémoire, d’en générer dynamiquement des tuiles, et de les utiliser de la façon attendue par la machine. Un processus lourd qui nécessitait généralement l’ajout de hardware dédié dans les cartouches.
Comment calculer une image 3D ?
La « fausse » 3D
Il y aurait donc une « vraie » 3D et une « fausse » 3D ?
On parlera ici de fausse 3D quand des astuces visuelles simulent une perspective à partir d’un monde fondamentalement 2D. Les limitations sont donc nombreuses. Out Run (1986) et After Burner (1987) sont des exemples évidents. Le jeu se déroule dans un monde en pseudo-3D dans lequel il est par exemple impossible de faire demi-tour.
Wolfenstein 3D (1992) et DOOM (1993) sont moins évidents. Wolfenstein 3D utilise une technique appelée raycasting afin de donner l’impression de se trouver au sein du niveau. Mais l’intégralité du niveau s’étend sur un seul plan, et les murs sont tous disposés de façon perpendiculaire. En réalité les niveaux de Wolfenstein 3D ont été édités à l’aide d’une simple évolution de l’éditeur de niveaux de Commander Keen (1990), un jeu de plateforme 2D ! DOOM est allé beaucoup plus loin pour donner l’impression de se déplacer dans un monde en trois dimensions. Mais il y a encore quelques limitations. Par exemple, deux pièces ne peuvent se trouver l’une au-dessus de l’autre (NdR : au fond le moteur ajoute juste un nivelé comme dans la version arcade d’Out Run).
Ultima Underworld (1992) et Quake (1996) étaient, eux, de véritables jeux en 3D, ne souffrant d’aucune de ces limitations. Même si, pour le premier, les objets et monstres étaient encore représentés sous forme de sprites.
Techniques de rendu 3D
Un véritable moteur 3D n’impose pas de contraintes sur les formes, les objets ou le point de vue. Évidemment la fidélité du rendu sera dépendante de la puissance de la machine, mais le temps passant, un rendu de plus en plus fidèle est devenu possible.
Tout commence avec le vertex. Il s’agit d’un point dans l’espace. Tout objet d’une scène 3D peut être représenté par une collection de vertex (NdR : ses sommets). Problème : comment calculer la position de ces points sur l’écran, comme s’ils étaient filmés par une caméra dont la position est connue ?
On réalise une projection de l’espace 3D vers le plan 2D de l’écran.
Cela demande, pour chaque point, de nombreux calculs trigonométriques qui peuvent être effectués efficacement à l’aide de matrices. Les premiers ordinateurs n’étaient pas assez puissants pour cela ou pour proposer autre chose que des représentations simplistes avec un frame rate très réduit.
Une fois que la position des vertex à l’écran est connue, on peut ajouter de la complexité. La première chose est de relier les vertex par des lignes afin de dessiner les contours des objets. Cela donne une représentation dite fil-de-fer (wireframe).
Pour les scènes plus complexes, nous devons regrouper les sommets afin de former les composants de base d’objets 3D : les faces. La manière la plus courante de regrouper les sommets est de former des triangles.
En combinant des faces triangulaires, on peut en effet approximer n’importe quelle forme. Les triangles ont aussi l’avantage que tous leurs sommets se trouvent sur un même plan.
Mais on peut aussi former des faces à partir de quatre sommets, formant des quadrilatères ou quads. Eux aussi permettent d’approximer toutes les formes… sauf les triangles (NdR : à moins que deux vertex du quad se confondent, ce qui occasionne donc des calculs redondants) ! Ils ont l’avantage de nécessiter moins d’éléments pour représenter des surfaces courbes.
Un ordinateur plus puissant permettra de supprimer les arêtes cachées du modèle filaire. Il pourra également remplir les faces visibles avec une couleur uniforme, ce qui donne ce que l’on appelle aujourd’hui de la 3D en flat shading. On peut ensuite ajouter une lumière directionnelle qui modifiera la couleur des surfaces.
Calculer la couleur correcte, qui tient compte de l’éclairage, demande une puissance de calcul importante. Tandis que remplir tous les pixels des faces nécessite une bande passante mémoire suffisante.
L’étape suivante consiste à calculer un ombrage plus réaliste des faces. On peut obtenir un résultat intéressant en calculant la couleur de chaque vertex d’une face, puis en interpolant ces couleurs afin que chaque pixel de la face ait une couleur différente. Cela adoucit les surfaces et permet une première approximation des reflets spéculaires sur les surfaces courbes.
L’un des algorithmes les plus utilisés pour cela est appelé Gouraud shading.
Enfin, on peut ajouter des détails à chaque surface en la remplissant avec une texture. Une texture est une image bitmap utilisée pour remplir une ou plusieurs faces. Elle peut être combinée avec le Gouraud shading, qui modifie alors la couleur de la texture en fonction de la position du pixel sur au sein d’une face. Utiliser une texture pour « colorer » un objet se nomme texture mapping.
Pour mapper correctement la texture, il faut retrouver les bons pixels de la texture, appelés texels, qui permettent d’obtenir la bonne couleur pour le pixel correspondant affiché à l’écran. Cela nécessite encore une fois beaucoup de ressources.
Nous y voilà : en 1994, lorsque la Saturn est sortie sur le marché japonais, un PC puissant pouvait rendre un jeu en 3D utilisant tous ces traitements, sans accélération matérielle et à une vitesse raisonnable. Mais un PC puissant coûtait très cher, et il était impensable d’intégrer un Pentium — ou même un 486 — dans une console de salon à un prix raisonnable.
Comme vous pouvez le constater avec la vidéo ci-dessus, même sur un PC puissant et coûteux de 1993, le jeu n’affiche ni beaucoup de faces, ni beaucoup de textures. C’est même un peu décevant. C’est dire à quel point le rendu 3D en pur logiciel est coûteux.
C’est la raison pour laquelle les consoles de cinquième génération ont été conçues avec des fonctionnalités matérielles pour accélérer le rendu 3D. Oui, même la Saturn !…
L’architecture de la Saturn
La Saturn est équipée d’un lecteur CD-ROM, de capacités audio avancées et d’autres nouveautés propres à sa génération. Ici, je vais seulement parler des composants qui entrent en jeu lors de la génération des images.
CPU
La SEGA Saturn repose sur deux processeurs SH-2 de Hitachi, chacun cadencé à 28,6 MHz. Cela engendre des difficultés de programmation qui seront détaillées plus loin.
Le SH-2 était un processeur relativement performant pour son époque. Il s’agit d’une évolution du SH-1, que Hitachi n’était pas encore parvenu à vendre à un client d’importance. Lorsque SEGA a exprimé son besoin, avec la perspective à la clef de fournir des dizaines de millions d’unités, Hitachi était conscient qu’il ne fallait pas manquer cette opportunité. La firme a convaincu SEGA que le SH-1 pouvait répondre à ses exigences, mais ce dernier s’est finalement révélé un peu faible pour effectuer des multiplications sur des nombres 32 bits. Son architecture a donc été modifiée pour améliorer cette partie, et cette nouvelle version fut baptisée SH-2.
Deux remarques ici :
- Les multiplications 32 bits sont assez peu utiles pour les jeux en 2D. SEGA avait donc clairement la 3D en tête.
- Certains affirment que le SH-2 était un processeur médiocre. Ce n’est pas le cas, comme le montre l’illustration ci-dessous.
Pour référence, le processeur de la PlayStation est un R3000 cadencé à 33,8 MHz. Il est plus rapide qu’un SH-2 de la Saturn, mais les deux sont tout de même dans la même catégorie. Cela dit, il est vrai que lorsque Sony a dévoilé sa console, SEGA a ajouté un second SH-2. Sur le papier, la Saturn disposait alors de plus de puissance CPU que la PlayStation.
Les deux SH-2 ne sont toutefois pas tout à fait équivalents.
L’un est le processeur principal, que l’on appellera Main. Il est chargé d’envoyer des programmes à l’autre, le Secondary, qui fonctionne davantage comme un coprocesseur. Comme ces deux CPUs partagent l’accès à certaines ressources, notamment la mémoire, il est difficile de les faire travailler ensemble sans que l’un gêne l’autre.
Nous en reparlerons.
DSP
Comme exposé précédemment, de nombreux traitements 3D reposent souvent sur des opérations matricielles. Ce qui implique de nombreuses multiplications et additions. Même avec ses deux SH-2, la Saturn n’aurait pas été assez puissante pour les graphismes 3D que SEGA avait en tête sans son DSP.
Un DSP est un type de puce qui n’est pas très performant pour exécuter du code généraliste, mais qui excelle lorsqu’il s’agit d’additionner et de multiplier des nombres dans des boucles très courtes. Exactement le genre d’opérations nécessaires pour manipuler des vertex dans l’espace et projeter des sommets de l’espace 3D. Comme nous l’avons vu plus tôt, le traitement 3D repose principalement sur des opérations matricielles. Cela implique de nombreuses multiplications et additions.
Le DSP est utilisé à la manière d’un coprocesseur, tout comme le second SH-2.
VDPs
Enfin, la Saturn est équipée de deux composants dédiés à la composition d’image, appelés VDP1 et VDP2.
Le VDP1, comme les coprocesseurs graphiques de son époque (le terme GPU n’existait pas encore), est configuré via de nombreux registres et est conçu pour traiter une liste de commandes envoyées par le processeur principal.
Il repose sur le concept de « sprites déformés » (distorted sprites), un terme qui apparaît dans la documentation officielle de SEGA. Et cette dénomination est sans doute la principale cause d’un malentendu répandu à propos de la Saturn : que tout cela ne serait qu’un bricolage ajouté tardivement pour donner à la console des capacités pseudo-3D.
Un sprite déformé est un quadrilatère 2D pouvant avoir n’importe quelle taille ou forme. Il peut être rempli par une couleur unie ou par une image qui sera déformée pour s’y adapter. Nous avons déjà vu que les quads sont un moyen efficace pour réaliser une approximation de la surface des objets. Et comme le VDP1 peut en dessiner des milliers par image, cela suffit pour rivaliser avec les autres machines de l’époque.
Mais le VDP1 ne comprend et ne traite que des coordonnées 2D. Ainsi, les vertex 3D doivent être projetés sur le plan 2D de l’écran afin de définir les quadrilatères qu’il doit dessiner : un travail parfait pour le DSP ! Le VDP1 peut appliquer du Gouraud shading de manière optionnelle sur chaque quadrilatère. Pour rappel, c’était à l’époque une technique avancée permettant de modifier la couleur de chaque pixel du quadrilatère, en se basant sur les informations fournies par chacun des quatre sommets. C’est très utile pour simuler l’éclairage local sur la surface, et donc principalement dédié à la 3D.
En sortie, VDP1 écrit dans un véritable framebuffer utilisant une VRAM dédiée. Celle-ci est suffisamment grande pour que les jeux puissent utiliser la technique du « double buffering ». Cette méthode, encore utilisée de nos jours, permet au VDP1 d’écrire dans un buffer tandis que l’étage suivant lit dans l’autre buffer, qui a été écrit lors de la frame précédente. Grâce au double buffering, il n’y a aucun risque de présenter une image incomplète à l’utilisateur.
Il a souvent été dit que les quadrilatères sont très inférieurs au triangles, utilisés notamment par la PlayStation. Nous y reviendrons.
Le VDP2 fonctionne à l’aide de tuiles, à la manière des consoles de l’ère 16 bits. Mais évidemment en beaucoup plus capable. Basé sur les mêmes principes que le VDP de la Megadrive, il peut générer plusieurs plans, composés de tuiles individuelles, le tout en 16 millions de couleurs. Ces plans peuvent être zoomés, tournés ou déformés à volonté, et supportent la transparence.
Comme son prédécesseur 16-bit, le VDP2 produit les images en temps réel, de façon synchronisée avec le balayage de l’écran cathodique. Il lit le buffer d’image, mélange les pixels produits par le VDP1 avec ceux issus de ses plans, puis envoie le résultat à l’affichage.
Il serait trop restrictif de penser que le VDP2 a été conçu uniquement pour la génération d’images 2D. Le VDP2 peut gérer jusqu’à quatre plans 2D mais également deux plans 3D. Ces plans possèdent des informations de profondeur qui seront utilisées par le VDP2 pour les rendre correctement, en tenant compte de la perspective (NdR : à la manière du mode 7 en quelque sorte). Ce que ni le VDP1 ni la PlayStation, pourtant dédiée à la 3D, ne peuvent accomplir ! Ces plans sont donc exempts de certains défauts caractéristiques de leur équivalents sur PlayStation (NdR : typiquement l’apparition des jointures entre polygones et leurs déformations en bordure d’écran).
La manière dont le VDP2 génère ses images, ligne par ligne, le rend très économique. L’utiliser pour remplir de grandes surfaces est un bon moyen d’économiser de la bande passante mémoire.
La 3D sur la Saturn
Quads versus Triangles
Les quadrilatères et les triangles peuvent tous deux être utilisés comme éléments de base pour construire n’importe quelle forme en 3D. Mais ils ne sont pas équivalents.
Les triangles ont l’avantage que leurs trois sommets, ainsi que tous les points à l’intérieur, se trouvent toujours sur un unique plan 2D, ce qui facilite certains calculs, notamment d’interpolation.
Cependant, lorsqu’on gère les vertex d’un moteur 3D de manière simple et « primitive », les triangles nécessitent plus de données pour décrire une géométrie que les quadrilatères, ce qui impacte les performances. L’exemple le plus simple est… un quadrilatère ! Pour dessiner un quadrilatère avec des triangles, il en faut deux soit six vertex. Tandis qu’une description basée sur des quads n’en requiert bien entendu que quatre.
Un autre avantage des quadrilatères est lié à la manière dont la PlayStation et la Saturn effectuent le mapping des textures. Pour rappel, cela consiste à déterminer quel texel de la texture correspondra à un pixel à l’écran. En la matière, les capacités des deux consoles sont très limitées et ne proposent aucun filtrage. Cela donne lieu à ces textures très caractéristiques, à l’aspect pixelisé.
De plus, les deux consoles n’appliquent pas les textures aux géométries de manière conforme aux règles de la perspective. Cela nécessiterait de prendre en compte la distance des pixels par rapport au point de vue de l’écran. Mais la Saturn et la PlayStation n’ont plus cette information au moment d’effectuer le texture mapping (NdR : on a vu que le VDP1 récupère une image purement 2D). Elles se contentent donc de déformer la texture à l’aide d’une simple « transformation affine » en 2D, afin qu’elle corresponde à la surface à remplir telle qu’elle apparaît à l’écran. Cela entraîne des imprécisions, plus visibles avec des triangles qu’avec des quadrilatères.
On peut atténuer ces imprécisions en utilisant beaucoup de petits triangles plutôt que quelques grands. La contrepartie, c’est que multiplier le nombre de triangles a un coût élevé en ressources.
Forward texturing contre backward texturing
L’aspect du rendu de la Saturn qui peut peut être sembler le plus « exotique » n’est pas qu’elle produit des géométries à base de quadrilatères, mais la manière dont elle applique les textures.
Les GPU modernes, ainsi que la PlayStation, utilisent ce qu’on appelle du backward texturing. Pour chaque pixel à afficher à l’écran, le GPU détermine à quel triangle il appartient, puis la position du texel correspondant dans la texture. Chaque sommet possède une « coordonnée de texture », un texel lui correspondant. Pour chaque pixel affiché à l’écran, on pourra donc se servir de ces trois coordonnées pour calculer le bon texel. Ce système est très souple et les coordonnées de texture peuvent même se trouver à l’extérieur de la texture ! Cette dernière sera alors en quelque sorte dupliquée pour pouvoir remplir le triangle visible.
La Saturn procède de façon inverse, par forward texturing. Chaque quadrilatère est associé à une texture. Mais il n’y a pas de coordonnée associée à chaque sommet. La texture remplit intégralement le quad. Pour ce faire, la texture est « déformée » pour s’adapter à sa forme, tel qu’il est affiché.
Les avantages de cette méthode sont sa simplicité de mise en œuvre, et un accès linéaire à la texture, ce qui est très efficace. En revanche, si le quadrilatère apparaît petit à l’écran, tous les texels seront tout de même lus puis écrits dans le framebuffer, certains les uns sur les autres, gaspillant ainsi beaucoup de bande passante mémoire.
Le forward texturing de la Saturn est donc très simple et peu coûteux en silicium à mettre en œuvre, mais il comporte de nombreux inconvénients. Par exemple, si l’on souhaite répéter une texture pour donner une illusion de détail, il faut également répéter le nombre de quadrilatères. Ce n’est pas une opération gratuite en termes de puissance de calcul.
De plus, chaque texel entraînera systématiquement des opérations de lecture/écriture, même pour de petits quadrilatères. Cela signifie que si une scène est composée de nombreux petits quads, une grande partie de la bande passante mémoire sera sollicitée pour lire et écrire tous ces texels, ce qui réduit les performances.
À propos de la transparence
Le forward texturing présente un autre inconvénient : il empêche le VDP1 de gérer correctement la transparence. Le manuel utilisateur indique ainsi que « certains pixels peuvent être écrits deux fois, et par conséquent, les résultats des traitements en semi-transparence ainsi que d’autres opérations de calcul de couleur ne peuvent pas être garantis ».
De toute façon, la gestion de la transparence est compromise par la manière dont le VDP1 construit le framebuffer. Comme on l’a vu, si deux quads se superposent, le second dessiné écrasera les données du premier. C’est pourquoi le développeur doit soigneusement envoyer les commandes pour les quads de l’arrière vers l’avant : en cas de recouvrement, le plus proche cachera le plus éloigné, ce qui est plutôt logique.
Mais que se passe-t-il si le dernier quad dessiné est marqué comme transparent ? Ses données écraseront toutes les données précédentes, et la transparence révélera alors… l’arrière-plan produit par le VDP2 !
C’est pourquoi, bien souvent, les quads transparents sont principalement utilisés pour dessiner des ombres au sol, car cela n’amène pas de tels problèmes.
Mais le VDP2 est pour sa part capable de produire correctement des effets de transparence sur ses propres plans. De bons résultats pouvaient donc être obtenus en utilisant soigneusement les deux VDP. Mais cela restait complexe et dépasse le cadre de cet article.
Par conséquent, dans la plupart des jeux, de nombreux effets de transparence sont simulés par un dithering : un pixel sur deux est opaque, l’autre étant totalement transparent (NdR : les fameuses transparences en « grilles de pixel » si décriées sur Saturn, même si le rendu peut être très bon avec une texture en dégradé et une résolution élevée).
Programmer pour la Saturn est ardu
La Saturn a la réputation d’être une plateforme très difficile à programmer. Est-ce mérité ?
Oh que oui !
Pour commencer, afin de tirer le meilleur parti des performances CPU, il faut découper le code pour qu’il s’exécute sur les deux SH-2 en parallèle. Cela introduit de nombreuses complexités, notamment parce qu’ils partagent beaucoup de ressources, comme la mémoire ; bien qu’ils disposent chacun d’un petit cache interne, ils ne peuvent pas accéder à la mémoire en même temps. Si le CPU principal occupe trop longtemps le bus, le second CPU se retrouve bloqué. Aujourd’hui, les CPU multicœurs sont la norme, mais ce n’était pas le cas au début des années 1990. Le SH-2 manquait donc de nombreuses fonctionnalités facilitant la coopération entre les deux processeurs. Partager des données de l’un à l’autre nécessite la mise en place d’un système de messagerie complexe, utilisant des interruptions et une gestion manuelle des caches. C’est pourquoi de nombreux programmeurs ont cherché à découpler les opérations autant que possible, et ont souvent utilisé le second CPU comme un simple coprocesseur indépendant. Dans Sonic R (1997), par exemple, certains objets très réfléchissants étaient entièrement rendus en logiciel, car le VDP1 ne supportait pas la technique de l’environment mapping. C’était une tâche idéale pour le SH-2 secondaire, qui pouvait travailler sur ce sujet de façon presque autonome.
Le DSP quant à lui est parfaitement adapté aux opérations mathématiques rapides, nécessaires pour manipuler les vertex. Le problème : c’est au développeur d’écrire son propre programme. Ce DSP particulier est très puissant, mais au prix d’une grande complexité de programmation. En effet, il peut exécuter jusqu’à six instructions en parallèle, si les bonnes conditions sont réunies. Mais c’est au programmeur de spécifier explicitement quelles opérations doivent être parallélisées dans le code assembleur — et bien sûr, toutes les combinaisons ne sont pas possibles. De plus, il doit gérer manuellement la latence de chaque opération. Par exemple, si une instruction effectue une multiplication, le résultat ne sera pas nécessairement disponible immédiatement. Si l’instruction suivante essaie d’utiliser ce résultat avant qu’il ne soit prêt, la valeur sera incorrecte. Et il n’y aura ni erreur ni avertissement à l’assemblage du code : seulement un bug lors de l’exécution du programme.
Et puis il y a les VDP. Ils doivent être configurés manuellement via de nombreux registres, le VDP1 présente de nombreuses limitations, et les deux doivent être utilisés en parfaite coordination pour tirer le meilleur parti de la console. Cela ajoute de la complexité au logiciel qui leur envoie les commandes. Cette complexité représentait un vrai problème pour SEGA. Les studios avaient du mal à faire la transition de l’ère 2D vers l’ère 3D. Ce fut un changement radical, et beaucoup ne s’en sont pas remis.
Durant les générations 8 et 16 bits, les développeurs devaient être en mesure d’exploiter toutes les ressources des consoles. Mais désormais, ils devaient également être capables de concevoir des logiciels plus ambitieux et plus complexes, ce en utilisant des techniques et des langages que certains n’avaient jamais appris ni même utilisés auparavant. Ils devaient également avoir un minimum de bagage en mathématiques pour manipuler des objets dans un espace 3D, calculer des collisions, de la physique, etc.
Nombreux étaient des autodidactes qui n’avaient pas suivi de cours de mathématiques appliquées ou d’informatique à l’université, et peinaient à suivre. La dernière chose dont ils avaient besoin, c’était d’apprendre à programmer efficacement un matériel complexe.
Dans une interview, Hideki Sato, qui dirigeait le département R&D chez SEGA, a admis que la conception de la console visait principalement à satisfaire les équipes de développement internes. Le support des studios tiers n’était pas une priorité.
Sony n’a pas eu ce problème, car ils sont partis d’une feuille blanche et étaient conscients que les studios tiers seraient essentiels à leur succès. L’architecture de la PlayStation est plus simple et entièrement dédiée à une seule chose : afficher le plus de triangles texturés possible à l’écran. Son unique processeur MIPS est assisté par le GTE, Geometry Transform Engine, qui se charge des calculs liés à la géométrie et à l’éclairage. Contrairement au DSP de la Saturn, ce n’est pas une puce entièrement programmable : elle a été conçue « en dur » pour accomplir cette mission bien précise. Le CPU lui confie des tâches via des registres et des commandes chargées en mémoire, très étroitement liées au type de traitement à effectuer. Pour simplifier : sur la PlayStation, on utilise les commandes fournies pour indiquer au GTE ce qu’il doit faire, tandis que sur la Saturn, il faut programmer soi-même l’équivalent du traitement du même genre de commandes par le DSP…
Mais la plupart des programmeurs n’avaient même pas besoin de se préoccuper du GTE, car Sony fournissait dès le premier jour un SDK (kit de développement) complet. Il s’agissait d’une collection de fonctions utilisables depuis le code du jeu sur le CPU se chargeant de gérer les tâches de plus bas niveau. Un peu plus tard, SEGA proposa également un SDK. Appelé SGL, il était très orienté 3D et offrait enfin de nombreuses fonctions de haut niveau, permettant par exemple de s’affranchir de développer pour le DSP.
Autre difficulté, dès le début des années 1990, presque tous les logiciels 3D utilisaient déjà la technique du backward mapping ainsi que des triangles. Cela constituait un sérieux inconvénient pour la Saturn, car les données produites par les logiciels commerciaux devaient être converties en quadrilatères et textures adaptés. Pire encore, ce que l’artiste créait avec ces logiciels ne pouvait pas parfaitement correspondre à l’objet affiché par la Saturn. Tout cela ajoutait de la complexité et un coût au portage des jeux multi-plateforme sur la Saturn…
Conclusion
Il est vrai que la SEGA Saturn était une machine très complexe, difficile à programmer. Mais ce n’est pas le résultat d’une réflexion tardive concernant des capacités 3D, qui auraient été ajoutées à la hâte en réaction à la PlayStation. J’espère que cet article a montré que beaucoup de ses fonctionnalités ont été conçues avec pour objectif un bon rendu 3D. SEGA avait bien sûr constaté le succès de ses propres jeux d’arcade 3D, Virtua Racing (1992) et Virtua Fighter (1993), et savait que c’était l’avenir. Le principal problème était que l’équipe d’ingénierie travaillant sur les consoles ne bénéficiait pas de l’expérience en 3D accumulée par l’équipe arcade.
Les quadrilatères sont souvent considérés comme une preuve des impasses techniques de la console. Mais si les triangles se sont imposés depuis, ce n’était pas encore complètement le cas à l’époque. Les ingénieurs de SEGA ne sont pas les seuls à avoir choisi la voie des quadrilatères, ni du forward mapping. La 3DO ainsi que le tout premier GPU Nvidia, le NV1, ont fait le même choix. Et dix ans auparavant, les stations graphiques IRIS 2000 de Silicon Graphics, dont la réputation n’était pas à faire, manipulaient également des quads. Et leurs modèles ultérieurs utilisaient un composant programmable Weitek pour les calculs géométriques. Ce qui tend à montrer que le choix d’un DSP pour cette tâche au sein de la Saturn n’est pas un cas isolé. C’était en effet beaucoup plus simple et moins onéreux que de développer un matériel dédié comme l’a fait Sony.
La Saturn était évidemment loin d’être idéale, avec de véritables lacunes. À mon avis, plus que le rendu basé sur les quadrilatères, c’est la façon dont elle réalise le mapping des textures qui est son véritable talon d’Achille. L’absence de toute prise en compte de la profondeur lors de la manipulation des quadrilatères par VDP1 est un autre problème important.
Tous ces choix ont été le fruit de compromis et finalement ils correspondent assez bien à cette dénomination de « sprites déformés« , qui était certainement parlante pour des développeurs habitués à la 2D. SEGA a clairement sous-estimé la vitesse à laquelle tout passerait à la 3D. Tout comme d’autres, ils pensaient que la 2D aurait encore un bel avenir pendant quelques années.
Finalement, la SEGA Saturn est plus adaptée à la 3D que la plupart des autres consoles de cinquième génération. Tout le monde savait que la 3D allait survenir. Mais la puissance de calcul était à peine suffisante, et c’était une époque d’expérimentations. L’anomalie de cette génération, c’est en réalité Sony : la compagnie a tout misé sur la 3D et sur un bon soutien des éditeurs tiers. Sa PlayStation a été un succès total ! Elle a très peu de défauts techniques et est très proche du meilleur que l’on pouvait raisonnablement atteindre en 1994 (NdR : du reste, la PS2 était en revanche difficile à programmer, en tout cas bien plus que la Dreamcast, mais ça n’a pas freiné les éditeurs tiers d’emblée convaincus de son succès et que les efforts supplémentaires seraient rentables…).
Au Japon, la Saturn s’est mieux vendue que la PlayStation durant les premières années. Les joueurs hardcore étaient pleinement satisfaits des jeux d’arcade édités par SEGA. Mais Sony et sa légion de studios tiers ont réussi à élargir le marché à un nouveau public qui n’était pas forcément séduit par l’offre de SEGA. Et lorsque Final Fantasy VII (1997) est arrivé en magasin, il était clair que plus rien ne stopperait la montée en puissance de Sony…
Un grand merci à tous ceux qui nous soutiennent sur Tipeee
