<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>3. Bibliothèques</title>
<link rel="stylesheet" href="style.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.64.1">
<link rel="home" href="index.html" title="Guide pratique du jeu sous Linux">
<link rel="up" href="index.html" title="Guide pratique du jeu sous Linux">
<link rel="previous" href="ar01s02.html" title="2. Définitions : types de jeux">
<link rel="next" href="ar01s04.html" title="4. XFree86 et vous">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">3. Bibliothèques</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="ar01s02.html">Précédent</a> </td>
<th width="60%" align="center"> </th>
<td width="20%" align="right"> <a accesskey="n" href="ar01s04.html">Suivant</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1" lang="fr">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2513054"></a>3. Bibliothèques</h2></div></div>
<div></div>
</div>
<p>Voici différentes bibliothèques consacrées au jeu que l'on peut
trouver sous Linux.</p>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="glide2"></a>3.1. Glide2</h3></div></div>
<div></div>
</div>
<p>Glide2 est une API et un pilote graphiques de bas niveau qui
accèdent aux fonctions 3D accélérées par matériel des cartes Voodoo
I, II et III de 3dfx sous <span class="application">XFree86</span>
3.x.</p>
<p>Un programme ne peut utiliser les fonctionnalités spéciales
accélérées matériellement de ces cartes qu'en utilisant la
bibliothèque Glide2 d'une des deux façons suivantes :</p>
<div class="itemizedlist"><ul type="disc">
<li><p>directement en utilisant Glide2
(<span class="productname"><span class="foreignphrase"><i class="foreignphrase">Myth II</i></span></span>™,
<span class="productname"><span class="foreignphrase"><i class="foreignphrase">Descent
III</i></span></span>™)</p></li>
<li><p>indirectement en utilisant Mesa construit avec un
dorsal Glide2 pour simuler OpenGL
(<span class="productname"><span class="foreignphrase"><i class="foreignphrase">Rune</i></span></span>™,
<span class="productname"><span class="foreignphrase"><i class="foreignphrase">Unreal
Tournament</i></span></span>™)</p></li>
</ul></div>
<p>3dfx a ouvert les spécifications et le code source à la
communauté <span class="foreignphrase"><i class="foreignphrase">open source</i></span>. Cela a permis
à <span class="firstname">Daryll</span> <span class="surname">
Strauss</span> de porter Glide2 sous Linux,
autorisant les utilisateurs de <span class="application">XFree86</span> 3.x
à utiliser les cartes Voodoo I, II et III sous Linux.</p>
<p>Puisque Glide2 accède directement à la carte vidéo, les
applications Glide2 doivent soit être exécutées par root, soit être
setuid-root. Une façon d'éviter cela était de créer le module noyau
3dfx. Ce module (et son fichier de périphérique <tt class="filename">/dev/3dfx</tt>) permet l'accélération
graphique matérielle Glide2 pour les utilisateurs non-root
d'applications non-setuid.</p>
<p>Malheureusement, Glide2 n'est pas une solution d'avenir. Elle
n'est utilisée que pour les cartes Voodoo I, II et III (qui
deviennent obsolètes), sous <span class="application">XFree86</span> 3.x
(la majorité utilise <span class="application">XFree86</span> 4.x). Et
étant donné que 3dfx est maintenant une société défunte, il est
certain qu'aucun développement n'aura désormais lieu sur Glide2 et
qu'aucun nouveau jeu ne sera écrit en utilisant Glide2.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="glide3"></a>3.2. Glide3</h3></div></div>
<div></div>
</div>
<p>À la différence de Glide2, Glide3 n'est pas une API utilisée
pour la programmation de jeux. Elle n'existe que pour gérer le DRI
pour les cartes Voodoo III, IV et V sous
<span class="application">XFree86</span> 4.x. Aucun des jeux utilisant
Glide2 ne fonctionnera avec Glide3. Cela ne devrait pas être
surprenant dans la mesure où Glide2 et Glide3 prennent en charge des
cartes vidéo différentes et des versions de
<span class="application">XFree86</span> différentes. La seule carte vidéo
pouvant utiliser à la fois Glide2 (sous
<span class="application">XFree86</span> 3.x) et Glide3 (sous
<span class="application">XFree86</span> 4.x) est la Voodoo III. On
rapporte qu'une Voodoo III utilisant Glide2 surpasse une Voodoo III
utilisant Glide3.</p>
<p>Quand vous utilisez une Voodoo III, IV ou V sous
<span class="application">XFree86</span> 4.x, vous devez utiliser une
version de <a href="ar01s03.html#mesa" title="3.4. Mesa">Mesa</a> qui a été compilée pour
utiliser Glide3 comme dorsal afin de pouvoir utiliser l'accélération
matérielle OpenGL sur votre système.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="opengl"></a>3.3. OpenGL</h3></div></div>
<div></div>
</div>
<p>OpenGL est une interface de programmation graphique de haut
niveau développée à l'origine par SGI, et qui est devenue un standard
industriel pour la programmation 2D et 3D. Elle est définie et
soutenue par le Architectural Revision Board
(<span class="acronym">ARB</span>), une organisation qui inclut des
représentants de SGI, IBM, DEC et Microsoft. OpenGL fournit un jeu de
fonctionnalités puissant, complet et générique pour les opérations
graphiques 2D et 3D.</p>
<p>OpenGL est constitué de 3 parties :</p>
<div class="itemizedlist"><ul type="disc">
<li><p>GL : les appels OpenGL de
base</p></li>
<li><p>GLU : les appels utilitaires</p></li>
<li><p>GLUT : le traitement des événements de
fenêtre indépendants du système (événements de souris, du clavier,
et cætera).</p></li>
</ul></div>
<p>OpenGL n'est pas seulement une API, c'est aussi une
implémentation, écrite par SGI. Elle essaie d'utiliser l'accélération
matérielle pour diverses opérations graphiques quand elle est
disponible, en fonction de de la carte vidéo dont vous disposez. Si
l'accélération matérielle n'est pas possible pour une tâche
particulière, OpenGL retombe sur le rendu logiciel. Cela signifie que
si vous vous procurez OpenGL chez SGI, et que vous voulez disposer
d'une accélération matérielle quelconque, elle doit être écrite en
OpenGL et compilée spécifiquement pour une certaine carte graphique.
Sinon, vous retomberez sur le rendu logiciel. Cela s'applique
également aux clones d'OpenGL, comme Mesa.</p>
<p>OpenGL est l'équivalent <span class="foreignphrase"><i class="foreignphrase">open
source</i></span> de Direct3D, un composant de <a href="ar01s03.html#directx" title="3.14. DirectX">DirectX</a>. Une différence importante est que
puisque OpenGL est ouvert (et DirectX fermé), les jeux écrits en
OpenGL sont beaucoup plus faciles à porter et à co-développer sous
Linux que ne le sont les jeux utilisant DirectX.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="mesa"></a>3.4. Mesa</h3></div></div>
<div></div>
</div>
<p>Mesa <<a href="http://www.mesa3d.org" target="_top">http://www.mesa3d.org</a>> est
une implémentation libre de l'API OpenGL, conçue et écrite par Brian
Paul. Bien qu'elle ne soit pas officiellement certifiée (cela
nécessiterait plus d'argent que n'en dispose un projet
<span class="foreignphrase"><i class="foreignphrase">open source</i></span>), elle constitue une
implémentation d'OpenGL presque totalement conforme aux
spécifications de l'ARB. On rapporte que Mesa est même plus rapide
que la propre implémentation OpenGL de SGI.</p>
<p>Tout comme OpenGL, Mesa utilise l'accélération matérielle quand
c'est possible. Quand une tâche graphique particulière ne peut être
accélérée matériellement par la carte vidéo, elle est rendue en
logiciel ; la tâche est alors accomplie par votre processeur.
Cela signifie qu'il existe différentes moutures de Mesa en fonction
du type de carte vidéo dont vous disposez. Chaque mouture utilise une
bibliothèque différente comme moteur de rendu. Par exemple, si vous
avez une Voodoo I, II ou III sous <span class="application">XFree86</span>
3.x, vous devriez utiliser mesa+glide2 (écrit par <span class="firstname">David</span> <span class="surname">
Bucciarelli</span>) qui est l'implémentation Mesa de
OpenGL qui utilise Glide2 comme dorsal pour rendre les opérations
graphiques.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2513489"></a>3.5. DRI</h3></div></div>
<div></div>
</div>
<p>Le rendu des graphiques comporte 3 protagonistes :
l'application cliente (comme <span class="productname"><span class="foreignphrase"><i class="foreignphrase">Quake
3</i></span></span>™), le serveur X et le matériel (la
carte graphique). Auparavant, les applications clientes ne pouvaient
pas écrire directement sur le matériel, et il y avait une bonne
raison à cela : un programme à qui l'on permet un accès en
écriture direct sur le matériel peut faire planter le système de
plusieurs façons. Plutôt que de faire confiance aux programmeurs pour
écrire des programmes (accédant au matériel) totalement exempts de
bogues et coopératifs, Linux l'a tout simplement interdit. Néanmoins,
cela a changé sous <span class="application">XFree</span> 4.x avec
l'infrastructure de rendu direct (<a href="http://www.dri.sourceforge.net" target="_top">Direct Rendering
Infrastructure</a>, <span class="acronym">DRI</span>). La DRI autorise les
clients X à écrire des informations de rendu 3D directement sur la
carte vidéo d'une manière sûre et coopérative.</p>
<p>DRI fait abstraction du serveur X afin que le pilote 3D (Mesa
ou OpenGL) puisse parler directement au matériel. Cela améliore les
performances. Les informations de rendu 3D ne doivent même pas subir
d'accélération matérielle. D'un point de vue technique, cela a
plusieurs avantages :</p>
<div class="itemizedlist"><ul type="disc">
<li><p>Les données associées aux sommets de polygones ne
doivent pas être codées/décodées via GLX.</p></li>
<li><p>Les données graphiques ne sont pas envoyées via une
socket au serveur X.</p></li>
<li><p>Sur les machines mono-processeur, le CPU ne doit
pas changer de contexte entre XFree86 et son client pour rendre les
graphiques.</p></li>
</ul></div>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2513579"></a>3.6. GLX</h3></div></div>
<div></div>
</div>
<p>GLX est l'extension X utilisée par les programmes OpenGL ;
c'est le liant entre l'OpenGL indépendant de la plate-forme, et X
dépendant de la plate-forme.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2513594"></a>3.7. Utah GLX</h3></div></div>
<div></div>
</div>
<p>Utah-GLX est le précurseur de DRI. Certaines décisions de
conception sont différentes en ce qui concerne la séparation des
données et des méthodes d'accès à la carte vidéo, comme le repos sur
l'accès root plutôt que la création de l'infrastructure noyau
permettant un accès sécurisé. Il prend en charge quelques cartes qui
ne sont pas bien gérées par le DRI comme la famille ATI Rage Pro, la
S3 Virge (bien que quiconque l'utilise pour jouer est pour ainsi dire
cinglé), et un pilote TNT/TNT2 <span class="foreignphrase"><i class="foreignphrase">open
source</i></span> (très incomplet). Le pilote TNT/TNT2 est basé
sur la rétro-ingénierie de la publication du code source obscurci des
pilotes X 3.3 par nVidia. Néanmoins, ils sont très incomplets et,
pour tout dire, inutilisables.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="xlib"></a>3.8. xlib</h3></div></div>
<div></div>
</div>
<p>De temps à autre, vous verrez quelques malades (dit avec
respect) qui écrivent un jeu en xlib. C'est un groupe de
bibliothèques C qui comportent l'interface de programmation du plus
bas niveau pour <span class="application">XFree86</span>. Toute
programmation graphique sous X fait <span class="emphasis"><em>in fine</em></span>
usage de la bibliothèque xlib.</p>
<p>Il n'est pas exagéré de dire que xlib est volumineux,
mystérieux et compliqué. De ce fait, il existe des tas de
bibliothèques comme <a href="ar01s03.html#sdl" title="3.10. SDL (Simple DirectMedia Layer)">SDL</a> pour les
graphiques 2D, et <a href="ar01s03.html#opengl" title="3.3. OpenGL">OpenGL</a> pour les
graphiques 3D et les jeux d'éléments graphiques (<a href="ar01s03.html#widgetset" title="3.9. Widgets"><span class="foreignphrase"><i class="foreignphrase">widgets</i></span></a>)
pour les éléments graphiques à l'intérieur des fenêtres qui cachent
les détails de différents aspects de la programmation xlib.</p>
<p>Bien que quelques jeux soient écrits avec xlib, comme l'éditeur
Doom Yadex, xlib en lui-même ne peut pas raisonnablement servir de
bibliothèque d'écriture de jeux. La plupart des jeux n'ont pas besoin
de l'interface de bas niveau fournie par xlib. De plus, en utilisant
les bibliothèques de plus haut niveau, un programmeur de jeux peut
développer son jeu sur plusieurs plates-formes, même celles qui
n'utilisent pas <span class="application">XFree86</span>.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="widgetset"></a>3.9. <span class="foreignphrase"><i class="foreignphrase">Widgets</i></span></h3></div></div>
<div></div>
</div>
<p>Les éléments graphiques (widgets) sont des objets qui
constituent l'interface d'une application graphique. Ils incluent des
choses comme les boîtes d'entrée de texte, les menus déroulants, les
barres de défilement, les boutons radio et bien d'autres choses. Un
jeu d'éléments graphiques (widget set) est une collection d'éléments
graphiques apparentés qui sont conçus pour avoir une interface
commune et un aspect cohérent. Gtk est le jeu d'éléments graphiques
canonique sous Linux, mais il y en a beaucoup d'autres comme fltk (de
petite taille, écrit en C++), Xaw, Qt (le jeu d'éléments graphiques
de KDE) et Motif (celui utilisé par Netscape). Motif régnait dans le
monde Unix, mais sa licence d'utilisation était très coûteuse. L'Open
Group a finalement ouvert la licence de Motif pour les systèmes
d'exploitation <span class="foreignphrase"><i class="foreignphrase">open source</i></span>, mais
c'était trop tard. Il y a beaucoup de jeux d'éléments graphiques
complètement <span class="foreignphrase"><i class="foreignphrase">open source</i></span> qui sont plus
complets et plus beaux que Motif, y compris Lesstif, un clone
totalement gratuit de Motif.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="sdl"></a>3.10. SDL (Simple DirectMedia Layer)</h3></div></div>
<div></div>
</div>
<p><a href="http://www.libsdl.org" target="_top">SDL</a> est une
bibliothèque de <span class="firstname">Sam</span> <span class="surname">
Lantiga</span> (diplômé de l'UCD !). C'est en
fait une méta-bibliothèque, c.-à-d. que ce n'est pas seulement une
bibliothèque graphique qui cache les détails de la programmation
xlib, mais c'est aussi une interface simple d'utilisation pour le
traitement du son, de la musique et des événements. Sa licence est la
LGPL et elle prend également en charge les joysticks et OpenGL. À la
différence de <a href="ar01s03.html#xlib" title="3.8. xlib">xlib</a>, SDL convient fort
bien à la programmation de jeux.</p>
<p>Le plus impressionnant dans SDL est son caractère
multi-plates-formes. Mis à part quelques détails, un programme écrit
en SDL compilera sous Linux, MS Windows, BeOS, MacOS, MacOS X,
Solaris, IRIX, FreeBSD, QNX et OSF. Il existe diverses extensions
permettant de manipuler à peu près tous les formats graphiques, lire
des vidéos MPEG, afficher des polices
<span class="foreignphrase"><i class="foreignphrase">truetype</i></span>, gérer les acteurs
(<span class="foreignphrase"><i class="foreignphrase">sprites</i></span>) et à peu près tout ce qui
est imaginable. SDL est un exemple de ce à quoi toutes les
bibliothèques graphiques devraient aspirer. </p>
<p>Sam avait une motivation cachée pour l'écriture d'une si
chouette bibliothèque : il était le programmeur en chef de Loki
Software (il code maintenant pour Blizzard Software), qui utilisait
SDL dans tous ses jeux sauf
<span class="productname"><span class="foreignphrase"><i class="foreignphrase">Quake3</i></span></span>™.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="ggi"></a>3.11. GGI</h3></div></div>
<div></div>
</div>
<p><a href="http://www.ggi-project.org" target="_top">GGI</a> est un
projet qui vise à implémenter une couche d'abstraction graphique dans
du code de bas niveau, de placer la prise en charge du matériel
graphique dans une base de code commune, et d'apporter une plus
grande stabilité et portabilité aux applications graphiques. Les
applications LibGGI tournent entre autres sous SVGAlib, fb et X. Si
l'on en juge à leurs captures d'écran, c'est une bibliothèque assez
puissante.</p>
<p>Les applications qui utilisent LibGGI directement comportent
<span class="productname"><span class="foreignphrase"><i class="foreignphrase">Heroes</i></span></span>™,
<span class="productname"><span class="foreignphrase"><i class="foreignphrase">Ultrapoint</i></span></span>™,
<span class="productname"><span class="foreignphrase"><i class="foreignphrase">Quake</i></span></span>™ et
<span class="productname"><span class="foreignphrase"><i class="foreignphrase">Berlin</i></span></span>™. La
plupart des applications qui utilisent SVGALib peuvent être exécutées
sous X ou sous n'importe quel autre dorsal LibGGI en utilisant une
bibliothèque enveloppe qui réimplémente <a href="ar01s03.html#svgalib" title="3.12. SVGAlib, framebuffer et console">SVGALib</a> en utilisant LibGGI. Les
applications <a href="ar01s03.html#sdl" title="3.10. SDL (Simple DirectMedia Layer)">SDL</a> et <a href="ar01s03.html#clanlib" title="3.15. Clanlib">clanlib</a> peuvent s'afficher avec LibGGI mais
les pilotes natifs de ces bibliothèques sont généralement plus
rapides ; néanmoins, c'est un bon moyen pour que des
applications SDL, clanlib et SVGALib s'exécutent là où elles
n'auraient pas pu le faire auparavant.</p>
<p>GGI a un projet sœur, KGI, qui développe une alternative
de niveau noyau aux systèmes du type
<span class="foreignphrase"><i class="foreignphrase">framebuffer</i></span> linux et DRI. Ce projet
est beaucoup moins avancé que LibGGI lui-même, mais promet de
combiner les vitesses de niveau DRI à la stabilité et à la sécurité
auxquelles aspirent les utilisateurs UNIX.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="svgalib"></a>3.12. SVGAlib, framebuffer et console</h3></div></div>
<div></div>
</div>
<p>La console est l'écran noir non graphique que vous voyez
lorsque votre ordinateur démarre pour la première fois (et qu'aucune
application du genre <span class="application">xdm</span> ou
<span class="application">gdm</span> ne tourne). C'est différent de
l'environnement X qui comporte toutes sortes d'éléments graphiques
comme les <span class="application">xterm</span>. Une idée fausse fort
répandue est de croire que X signifie
« <span class="quote">graphique</span> » et que console signifie
« <span class="quote">non graphique</span> ». Il peut assurément y avoir
des graphiques en mode console ; nous discuterons des deux
manières les plus habituelles de procéder.</p>
<p>SVGAlib est une bibliothèque graphique qui vous permet de
dessiner des graphiques sur la console. Il existe beaucoup
d'applications graphiques et de jeux utilisant SVGAlib comme
<span class="application">zgv</span> (un visualisateur d'images en mode
console), <span class="application">prboom</span> et
<span class="application">hhexen</span>. J'apprécie cette bibliothèque et
les jeux graphiques en mode console en général : ils sont
extrêmement rapides, plein écran et captivants. SVGAlib souffre de
trois défauts. Primo, les exécutables SVGAlib doivent être lancés par
root ou être setuid-root (néanmoins, la bibliothèque abandonne les
privilèges root immédiatement après le début de l'exécution).
Secundo, SVGAlib est dépendant de la carte vidéo : si votre
carte vidéo n'est pas prise en charge par SVGAlib, c'est pas de
chance. Tertio, SVGAlib est spécifique à Linux : les jeux
écrits en SVGAlib ne fonctionneront <span class="emphasis"><em>que</em></span> sous
Linux.</p>
<p>Les <span class="foreignphrase"><i class="foreignphrase">framebuffers</i></span> sont des
consoles implémentées par un mode graphique plutôt qu'un mode texte
du BIOS. Pourquoi simuler un mode texte dans un environnement
graphique ? Cela permet d'exécuter des applications graphiques
en console, comme p.ex. de choisir la police affichée en console (qui
est normalement fixée par le BIOS). On peut trouver un bon
« <span class="quote">Guide pratique du frame-buffer</span> » (<a href="http://www.traduc.org/docs/howto/lecture/Framebuffer-HOWTO.html" target="_top"><span class="foreignphrase"><i class="foreignphrase">Framebuffer-HOWTO</i></span></a>)
sur le LDP. Les jeux en console graphique écrits en utilisant le
framebuffer souffrent des mêmes problèmes que ceux utilisant
SVGAlib : le support matériel est limité, et le code ne
fonctionnera que sous Linux.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="openal"></a>3.13. OpenAL</h3></div></div>
<div></div>
</div>
<p><a href="http://www.openal.org" target="_top">OpenAL</a> a pour
objectif d'être au son ce que OpenGL est aux graphiques. Développé
conjointement par Loki Software et Creative Labs, elle a pour but
d'être une API neutre et multi-plates-formes pour le son. Sa licence
est la LGPL et les spécifications peuvent être obtenues gratuitement
depuis le site web de OpenAL. OpenAL est entièrement fonctionnel,
mais depuis que Loki Software n'existe plus, son développement futur
est incertain.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="directx"></a>3.14. DirectX</h3></div></div>
<div></div>
</div>
<p>DirectX est une collection d'API multimédia propriétaires,
développée à l'origine par Microsoft en 1995, pour ses différents
systèmes d'exploitation Windows. C'est une erreur de prétendre que
« <span class="quote">DirectX est similaire à OpenGL</span> » ou
« <span class="quote">DirectX est similaire à SDL</span> », comme il est
souvent dit dans les didacticiels DirectX. Les API multimédia sont
plus centralisées sous Windows qu'elles ne le sont sous Linux. Une
formulation plus précise serait : « <span class="quote">DirectX est
similaire à DRI, OpenGL et SDL combinés</span> ». En juin 2003,
la version la plus récente de DirectX était la 9.0. Les composants de
DirectX sont : </p>
<div class="variablelist"><dl>
<dt><span class="term">DirectDraw</span></dt>
<dd><p>DirectDraw
fournit un accès direct à la mémoire vidéo, comme DRI, de sorte
que les graphiques 2D peuvent être placés directement sur la
carte vidéo. DirectDraw est similaire au composant graphique de
SDL, mais l'accès direct à la carte vidéo est effectué par DRI
plutôt que par SDL. C'est pourquoi un jeu peut facilement faire
tomber un système Windows mais ne devrait pas le faire avec un
système Linux.</p></dd>
<dt><span class="term">Direct3D (D3D)</span></dt>
<dd><p>Direct3D,
comme OpenGL, fournit une API graphique 3D. Alors qu'OpenGL est
<span class="foreignphrase"><i class="foreignphrase">open source</i></span>, de plus bas niveau et
compile sous une multitude de systèmes d'exploitation, D3D est
propriétaire, de plus haut niveau et ne compile que sous Windows.
D3D est d'abord apparu dans DirectX 2, en
1996.</p></dd>
<dt><span class="term">DirectXAudio</span></dt>
<dd><p>Direct Audio est une combinaison de deux API
audio, DirectSound et DirectMusic, qui offrent un accès direct à
la carte son pour jouer du son et de la
musique.</p></dd>
<dt><span class="term">DirectInput</span></dt>
<dd><p>DirectInput permet l'utilisation de périphériques
d'entrée de jeu comme les
joysticks.</p></dd>
<dt><span class="term">DirectPlay</span></dt>
<dd><p>DirectPlay offre une gestion réseau
simplifiée pour les jeux multi-joueurs.</p></dd>
<dt><span class="term">DirectShow</span></dt>
<dd><p>DirectShow prend en charge les fichiers vidéo
comme <tt class="filename">AVI</tt> et <tt class="filename">MPG</tt>. C'était une API distincte de
DirectX, mais elle a été intégrée dans DirectX
8.</p></dd>
<dt><span class="term">DirectSetup</span></dt>
<dd><p>Cette API
facilite l'installation de DirectX à partir d'une application
pour simplifier l'installation des
jeux.</p></dd>
</dl></div>
<p>DirectX est un peu pris en charge par <a href="ar01s10.html#winex" title="10.5.3. winex"><span class="application">winex</span></a>, l'est mal
par <a href="ar01s10.html#wine" title="10.5.1. wine"><span class="application">wine</span></a>,
l'est à peine par <a href="ar01s10.html#vmware" title="10.5.5. VMWare"><span class="application">vmware</span></a> et ne l'est
pas du tout par <a href="ar01s10.html#win4lin" title="10.5.4. Win4Lin"><span class="application">Win4Lin</span></a>.</p>
<p>Remarque sur la portabilité : pour chaque composant de DirectX,
on peut trouver plusieurs bibliothèques correspondantes sous Linux.
Mieux encore, un programmeur de jeux qui utilise des bibliothèques
comme OpenGL, GGI ou SDL écrira un jeu qui compilera trivialement
sous Windows, Linux et une multitude d'autres systèmes
d'exploitation. Pourtant, les sociétés productrices de jeux
persistent à utiliser DirectX et limitent de ce fait leur public aux
seuls utilisateurs Windows. Si vous écrivez des jeux, veuillez
envisager l'utilisation de bibliothèques multi-plates-formes et
rester éloigné de DirectX.</p>
<p>Une société nommée realtechVR a démarré un projet
<span class="foreignphrase"><i class="foreignphrase">open source</i></span>, <a href="http://www.v3x.net/directx" target="_top">DirectX Port</a> qui, comme
<span class="application">wine</span>, fournit une couche d'émulation de
Direct3D qui implémente les appels Direct3D. Le projet se concentrait
sur la plate-forme BeOS, mais l'est maintenant sur MacOS et Linux.
Vous pouvez récupérer la toute dernière mouture depuis leur
référentiel CVS sur <<a href="http://sourceforge.net/projects/dxglwrap" target="_top">http://sourceforge.net/projects/dxglwrap</a>>.</p>
</div>
<div class="sect2" lang="fr">
<div class="titlepage">
<div><div><h3 class="title">
<a name="clanlib"></a>3.15. Clanlib</h3></div></div>
<div></div>
</div>
<p>ClanLib est un kit d'outils de développement de niveau
intermédiaire. Au plus bas niveau, il fournit des outils indépendants
de la plate-forme (dans la limite du possible en C++) de gestion de
l'affichage, du son, des entrées, du réseau, des fichiers, des
threads, et cætera. ClanLib construit un cadre générique de développement
de jeu, vous offrant une gestion aisée des ressources, une
réplication des objets sur le réseau, des interfaces utilisateur
graphiques (GUI) autorisant les thèmes, les langages de scripts dans
les jeux et plus encore.</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="ar01s02.html">Précédent</a> </td>
<td width="20%" align="center"><a accesskey="u" href="index.html">Niveau supérieur</a></td>
<td width="40%" align="right"> <a accesskey="n" href="ar01s04.html">Suivant</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">2. Définitions : types de jeux </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Sommaire</a></td>
<td width="40%" align="right" valign="top"> 4. XFree86 et vous</td>
</tr>
</table>
</div>
</body>
</html>
