Contexte et coupures de contenu

Lors du développement de Marathon Recompiled, les auteurs ont constaté que de nombreuses ressources graphiques de Sonic 06 restent présentes dans les fichiers du jeu mais sont désactivées dans la version finale. Des captures de la version bêta montrent des cartes de relief (bump maps) complètes dans Kingdom Valley, une géométrie plus riche et des plantes détaées dans Castle Town, ainsi qu’une disposition de bâtiments différente dans New City. La désactivation a été motivée par le besoin de maintenir le taux de rafraîchissement cible sur le matériel de l’époque, alors que le moteur peinait déjà à atteindre les 30 fps en configuration standard.

Architecture des shaders et variantes

Le rendu de Sonic 06 repose essentiellement sur deux familles de shaders : Terrain et Billboard. Chaque famille possède huit variantes numérotées de 00 à 07, le numéro indiquant le niveau de fonctionnalité. La variante la plus répandue, Billboard02, ne supporte que l’éclairage par sommet, aucune carte d’ombres en cascade (CSM) et aucune lumière ponctuelle. Cette limitation explique la plupart des surfaces planes et du manque de profondeur visuelle dans le jeu. Les variantes supérieures (par ex. Billboard07) intègrent le CSM et le support de textures normales, mais leur utilisation est marginale en raison du coût de calcul.

Gestion des ombres et des lumières

Le système d’ombres de Sonic 06 utilise des cascaded shadow maps (CSM) avec un maximum de quatre cascades. Les fonctions GenerateCSMLevels et GenerateCSMObjects définissent respectivement le nombre de cascades pour le terrain et les objets. La plupart des niveaux emploient les quatre cascades, mais les zones twn_a et quelques niveaux de test ne conservent que trois cascades pour le terrain et deux pour les objets, réduisant ainsi la portée des ombres. Cette réduction apparaît également dans le mode multijoueur, où le nombre de cascades est uniformément limité.

Les ombres souffrent d’un phénomène d’« acné », typique des techniques de rendu sans epsilon d’ajustement. L’absence de ce paramètre entraîne des artefacts visibles, comme l’acné sur l’oreille de Sonic. De plus, certains objets ne sont pas correctement marqués comme contributeurs aux cartes d’ombres, ce qui provoque l’absence d’ombres sur des éléments clés (ex. le snowboard de Sonic à Crisis City ou la jupe d’Elise dans une cinématique).

Le moteur prévoit également deux lumières ponctuelles par objet, déclarées dans la structure suivante :

shared struct
{
    float4 Position;
    float4 Color;
    float4 Attenuation;
} g_PointLights[2];

Cette contrainte de deux lumières par objet est suffisante pour les niveaux modestes comme Kingdom Valley, mais des zones telles que Flame Core ou Dusty Desert tentent d’allouer huit lumières ou plus, dépassant la capacité du shader. Le résultat est un conflit de priorité où les lumières s’affichent de façon aléatoire ou disparaissent complètement.

Limites et perspectives de recompilation

Les tentatives de remplacement des shaders de base par des variantes plus avancées se heurtent à deux obstacles majeurs : les différences de mise en page d’entrée/sortie entre les variantes, et le fait que les textures supplémentaires (normales, bump) sont parfois absentes des références .xno. Le code des shaders est largement inliné, rendant l’identification et la modification des sections de calcul d’éclairage difficile. Malgré ces difficultés, le projet de recompilation a déjà désactivé l’optimisation qui cassait les lumières ponctuelles, améliorant leur stabilité tout en conservant la limite de deux lumières. Une future analyse du bytecode pourrait permettre d’étendre ce plafond ou d’ajouter l’épsilon manquant pour corriger l’acné d’ombre.