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 XFree86 3.x.

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 :

3dfx a ouvert les spécifications et le code source à la communauté open source. Cela a permis à Daryll Strauss de porter Glide2 sous Linux, autorisant les utilisateurs de XFree86 3.x à utiliser les cartes Voodoo I, II et III sous Linux.

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 /dev/3dfx) permet l'accélération graphique matérielle Glide2 pour les utilisateurs non-root d'applications non-setuid.

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 XFree86 3.x (la majorité utilise XFree86 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.

À 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 XFree86 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 XFree86 différentes. La seule carte vidéo pouvant utiliser à la fois Glide2 (sous XFree86 3.x) et Glide3 (sous XFree86 4.x) est la Voodoo III. On rapporte qu'une Voodoo III utilisant Glide2 surpasse une Voodoo III utilisant Glide3.

Quand vous utilisez une Voodoo III, IV ou V sous XFree86 4.x, vous devez utiliser une version de Mesa 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.

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 (ARB), 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.

OpenGL est constitué de 3 parties :

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.

OpenGL est l'équivalent open source de Direct3D, un composant de DirectX. 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.

Mesa <http://www.mesa3d.org> 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 open source), 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.

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 XFree86 3.x, vous devriez utiliser mesa+glide2 (écrit par David Bucciarelli) qui est l'implémentation Mesa de OpenGL qui utilise Glide2 comme dorsal pour rendre les opérations graphiques.

Le rendu des graphiques comporte 3 protagonistes : l'application cliente (comme Quake 3™), 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 XFree 4.x avec l'infrastructure de rendu direct (Direct Rendering Infrastructure, DRI). 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.

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 :

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.

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 open source (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.

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 XFree86. Toute programmation graphique sous X fait in fine usage de la bibliothèque xlib.

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 SDL pour les graphiques 2D, et OpenGL pour les graphiques 3D et les jeux d'éléments graphiques (widgets) pour les éléments graphiques à l'intérieur des fenêtres qui cachent les détails de différents aspects de la programmation xlib.

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 XFree86.

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 open source, mais c'était trop tard. Il y a beaucoup de jeux d'éléments graphiques complètement open source qui sont plus complets et plus beaux que Motif, y compris Lesstif, un clone totalement gratuit de Motif.

SDL est une bibliothèque de Sam Lantiga (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 xlib, SDL convient fort bien à la programmation de jeux.

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 truetype, gérer les acteurs (sprites) et à peu près tout ce qui est imaginable. SDL est un exemple de ce à quoi toutes les bibliothèques graphiques devraient aspirer.

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 Quake3™.

GGI 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.

Les applications qui utilisent LibGGI directement comportent Heroes™, Ultrapoint™, Quake™ et Berlin™. 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 SVGALib en utilisant LibGGI. Les applications SDL et clanlib 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.

GGI a un projet sœur, KGI, qui développe une alternative de niveau noyau aux systèmes du type framebuffer 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.

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 xdm ou gdm ne tourne). C'est différent de l'environnement X qui comporte toutes sortes d'éléments graphiques comme les xterm. Une idée fausse fort répandue est de croire que X signifie « graphique » et que console signifie « non graphique ». Il peut assurément y avoir des graphiques en mode console ; nous discuterons des deux manières les plus habituelles de procéder.

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 zgv (un visualisateur d'images en mode console), prboom et hhexen. 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 que sous Linux.

Les framebuffers 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 « Guide pratique du frame-buffer » (Framebuffer-HOWTO) 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.

OpenAL 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.

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 « DirectX est similaire à OpenGL » ou « DirectX est similaire à SDL », 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 : « DirectX est similaire à DRI, OpenGL et SDL combinés ». En juin 2003, la version la plus récente de DirectX était la 9.0. Les composants de DirectX sont :

DirectX est un peu pris en charge par winex, l'est mal par wine, l'est à peine par vmware et ne l'est pas du tout par Win4Lin.

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.

Une société nommée realtechVR a démarré un projet open source, DirectX Port qui, comme wine, 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 <http://sourceforge.net/projects/dxglwrap>.

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.