1 De l'art et des difficultés de la 3D sur PC
Ce qui fait le succès du développement de jeux vidéo sur consoles (au-delà de leur plus grande résistance au piratage) est la totale maîtrise matérielle que chaque développeur peut obtenir. En effet, sur une console définie, les ressources hardwares (mémoire, processeur central, graphique et sonore) sont entièrement maîtrisées dès le début de la conception du jeu. Les équipes de développement n'ont donc aucun besoin de prendre en compte la moindre disparité technologique, s'évitant en cela de lourds efforts de développement et de tests.
Malheureusement pour nous autres développeurs sur PC, il n'en est rien sous Windows. Il est toujours possible d'établir des pré-requis pour un jeu ou une application graphique mais il ne sera jamais réalisable de connaître parfaitement une machine cible.
Partant de ce constat complexe, deux optiques s'offrent à nous :
· Nous pouvons décider de développer un programme fonctionnant sur le plus petit matériel supporté et, comme dans ce cas celui qui peut fonctionner sur le moins puissant pourra tout aussi bien fonctionner sur le plus puissant, nous pourrons produire un programme portable. Cette approche est difficilement acceptable car nous nous priverons de toute possibilité d'utiliser les plus récentes technologies de rendu et nous nous condamnerons de ce fait à réaliser au mieux un clone de Doom (le premier du nom J).
· L'autre approche consiste à penser dès le début du développement à cette problématique afin de réaliser un système adaptatif. Il s'agira dès lors de considérer pour chaque option graphique la possibilité de pouvoir soit émuler la dite fonction, soit de pouvoir s'en passer le cas échéant. Nous allons donc développer un mécanisme qui pourra se déployer pleinement sur des cartes graphiques modernes mais qui pourra également se lancer sur des plateformes plus anciennes en dégradant la qualité et la vitesse du rendu.
2 Portabilité
DirectX Managed fournit en standard une classe qui va nous permettre d'évaluer à la volée les capacités de la carte graphique active. Ces capacités sont fournies par le fabricant de la carte graphique et peuvent être directement consultées en utilisant le CapsViewer qui est un utilitaire fourni en standard avec le SDK de DirectX.
Chaque fonctionnalité supportée par DirectX, et potentiellement prise en charge par la carte graphique, possède une entrée dans une structure appelée Caps. C'est le contenu de cette structure qui est affiché par le Caps Viewer. Sur la capture d'écran ci-dessus, il est par exemple possible de voir que la carte graphique installée supporte des textures avec des résolutions allant jusqu'à 4096 par 4096.
De la même manière, dans le code de notre application nous allons pouvoir, à chaque fois qu'une option graphique devra être activée, savoir si cette dernière est supportée ou non par le matériel.
Pour interroger le driver, nous allons faire appel à la classe Manager qui intègre toutes les méthodes nécessaires. Ainsi, lors du lancement de l'application, nous allons activer le traitement mathématique des objets par la carte graphique (TnL : Transform and Lighting) si cela est possible et sinon nous opterons pour une solution où les calculs seront faits par le processeur central :
Caps caps = Manager.GetDeviceCaps(0, DeviceType.Hardware);
if (caps.DeviceCaps.SupportsHardwareTransformAndLight)
device3D = new Device(0, DeviceType.Hardware, ctrl, CreateFlags.HardwareVertexProcessing, presentParams);
else
device3D = new Device(0, DeviceType.Hardware, ctrl, CreateFlags.SoftwareVertexProcessing, presentParams);
Comme nous pouvons le constater ici, le Manager nous retourne une structure de type Caps qui contient un ensemble de valeurs définissant la carte graphique et notamment sa capacité à faire les calculs de transformations géométriques.
De la même manière, il est possible de demander la validation de chacune des options supportées par DirectX. Il suffit pour cela d'aller chercher la valeur associée dans la structure Caps :
if (caps.MaxActiveLights < 2)
ErrorManage("Votre carte ne supporte pas assez de lumires...");
if (caps.MaxTextureBlendStages < 2)
ErrorManage("Votre carte ne supporte pas le multitexturing...");
if (caps.RasterCaps.SupportsAnisotropy)
ErrorManage("Votre carte ne supporte pas le filtrage anisotropique...");
Une bonne rigueur de programmation est nécessaire dans notre cas, car il ne faut pas laisser d'options actives sans avoir au préalable effectuer les vérifications opportunes.
Ainsi, un autre point clé de notre programme va devoir subir les foudres de la validation par le Manager. En effet, lors du lancement de notre application, nous avons pour le moment présumé du format de notre buffer de travail et de notre ZBuffer. Si dans la majorité des cas les valeurs sélectionnées ne poseront pas de problèmes, nous devons toutefois mettre en place un mécanisme plus robuste qui va à nouveau s'appuyer sur le Manager au travers de deux de ses méthodes : CheckDeviceType et CheckDepthStencilMatch :
private static DepthFormat GetDepthFormat(Format backbufferFormat)
{
if (Manager.CheckDepthStencilMatch(0,
DeviceType.Hardware,
Manager.Adapters[0].CurrentDisplayMode.Format,
backbufferFormat,
DepthFormat.D24X8))
return DepthFormat.D24S8;
return DepthFormat.D15S1;
}
private static Format GetBackBufferFormat()
{
if (Manager.CheckDeviceType(0,
DeviceType.Hardware,
Manager.Adapters[0].CurrentDisplayMode.Format,
Format.X8R8G8B8,
true))
return Format.X8R8G8B8;
if (Manager.CheckDeviceType(0,
DeviceType.Hardware,
Manager.Adapters[0].CurrentDisplayMode.Format,
Format.R5G6B5,
true))
return Format.R5G6B5;
return Format.Unknown;
}
public static void InitDXM(Control ctrl)
{
try
{
PresentParameters presentParams = new PresentParameters();
presentParams.Windowed = true;
presentParams.SwapEffect = SwapEffect.Discard;
presentParams.BackBufferFormat = GetBackBufferFormat();
presentParams.AutoDepthStencilFormat = GetDepthFormat(presentParams.BackBufferFormat);
presentParams.EnableAutoDepthStencil = true;
presentParams.BackBufferCount = 2;
En respectant cette petite contrainte de validation, nous pouvons donc nous garantir une portabilité maximale même vers du matériel à venir ou totalement dépassé.
3 DirectX SDK Updates
Au delà de l'adaptabilité de notre application, il est également important de souligner les constantes mises à jour disponibles sur le SDK de DirectX Managed.
Ces mises à jours s'enchaînent au rythme d’une par trimestre (Summer Update 2004 puis December Update 2004). Si elles ne changent pas le Runtime qui reste celui de DirectX 9.0c, elles permettent de découvrir de nouveaux samples et corrigent ou améliorent à chaque fois la qualité du SDK.
Pour télécharger ces updates :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anch_directx.asp.