Guide pratique du jeu sous Linux

La version originale de ce document a été réalisée par Peter Jay Salzman <p CHEZ dirac POINT org> pour les années 2001-2002, et à Peter Jay Salzman et Frédéric Delanoy pour les années 2003-2004.

Vous avez le droit de copier, distribuer et modifier la version originale de ce document selon les termes de la Open Software License (OSL), version 1.1, complétés par les dispositions présentées dans le paragraphe suivant. Je déteste les guides qui incluent la licence : des arbres meurent…

Si vous voulez créer un travail dérivé ou publier ce guide à des fins commerciales, je souhaiterais être contacté au préalable. Cela me donnera l'occasion de vous fournir la version la plus récente. J'apprécierais également soit une copie de votre travail, soit une pizza aux épinards, à l'ail, aux champignons, à la feta et aux cœurs d'artichauts.

La version française de ce document a été réalisée par Frédéric Delanoy. Elle est publiée en accord avec les termes de la Open Software License.

This document is copyright (c) 2001-2002 Peter Jay Salzman, <p(at)dirac(dot)org>; 2003-2004 Peter Jay Salzman and Frédéric Delanoy. Permission is granted to copy, distribute and/or modify this document under the terms of the Open Software License, Version 1.1, except for the provisions I list in the next paragraph. I hate HOWTO's that include the license; it's a tree killer. You can read the OSL at http://opensource.org/licenses/osl-1.1.txt.

If you want to create a derivative work or publish this HOWTO for commercial purposes, I would appreciate it if you contact me first. This will give me a chance to give you the most recent version. I'd also appreciate either a copy of whatever it is you're doing or a spinach, garlic, mushroom, feta cheese and artichoke heart pizza.

La version française de ce document a été réalisée par Frédéric Delanoy. Elle est publiée en accord avec les termes de la Open Software License.

Merci à Mike Phillips qui a énormément commenté ce guide. Merci à Dmitry Samoyloff, <dsamoyloff CHEZ yandex POINT ru>, qui a traduit ce document en russe. Cela m'a fait chaud au cœur quand il m'a raconté qu'il traduisait mes mots en russe. D'autres remerciements reviennent à :

Je voudrais également remercier Michael Mc Donnell pour m'avoir envoyé des commentaires et des corrections.

La version la plus récente peut être trouvée sur http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/lgh/LG-HOWTO ou http://www.dirac.org/linux/writing, mais c'est ma copie de travail personnelle. La version présente sur mon site web personnel pourrait être corrompue si je travaille sur le guide. La version sur sourceforge est la plus récente mais est garantie non corrompue, même si elle peut comporter quelques petits problèmes, comme des paragraphes non terminés. :)

La version stable la plus récente peut être trouvée sur http://www.tldp.org.

Dmitry Samoyloff, <dsamoyloff CHEZ yandex POINT ru>, est responsable de la traduction russe de ce guide. La version la plus récente peut être trouvée sur http://www.dirac.org/linux/writing.

Bien que les jeux d'arcade ont connu leur heure de gloire dans les années 80, ils restent néanmoins très populaires. Rien ne remplacera jamais une promenade dans une galerie d'arcade sombre, bondée et bruyante, y glissant une pièce dans votre machine préférée et jouant à un vieux jeu du genre Space Invaders™. Les jeux de style arcade essaient de simuler les jeux d'arcade eux-mêmes. Il y en a tellement qu'il est quasi impossible de tous les énumérer, mais on peut citer les clones de Asteroids™, Space Invaders™, Pac-Man™, Missile Command™ et Galaxian™.

Les jeux de cartes simulent des jeux comme le poker ou le solitaire. Le programme peut simuler votre ou vos adversaire(s).

Les jeux de logique simulent habituellement quelque casse-tête logique bien connu comme Master Mind™ ou le taquin.

Les jeux de plateau simulent les jeux que vous pourriez jouer sur une table avec des amis, comme le Monopoly™, les échecs, et cætera. Le programme peut simuler votre adversaire.

Il était une fois, quand Apple ][, Commodore et Atari dominaient le monde, les aventures en mode texte étaient le jeu dans le vent des « gens éduqués ». On vous fournit un scénario et vous pouvez interagir avec le monde dans lequel vous vous trouvez :

You are in a room.  It is pitch dark and you're likely
to be eaten by a grue.
> Light lantern with match.
You light the lantern.  This room appears to be a kitchen. 
There's a table with a book in the center.  You
also see an oven, refrigerator and a door leading east.
> Open the oven.
In the oven you see a brown paper bag.
> Take the bag.  Open the bag.  Close the oven.
Inside the bag is a clove of garlic and a cheese sandwich.
The oven door is now closed.

À cette époque, les aventures en mode texte étaient des exécutables autonomes tenant entièrement sur une disquette ou une cassette. Il y avait souvent un fichier de données et un interpréteur. L'interpréteur lit les fichiers de données et fournit l'interface de jeu. Les fichiers de données constituent le jeu en lui-même, à la manière de la relation entre les jeux de combat à la première personne et les fichiers wad.

Le premier jeu d'aventure était Adventure™ (en fait « ADVENT™ », écrit sur un PDP-1 en 1972). Vous pouvez toujours jouer à Adventure (en fait, à un descendant) : il est fourni avec les « jeux bsd » sur la plupart des distributions Linux. Les aventures en mode texte ont été popularisées par Scott Adams et ont atteint leur pic de popularité à la fin des années 80 avec les jeux de Infocom auxquels on peut également jouer sous Linux.

Comme les modes graphiques se sont développés et sont devenus plus puissants, les aventures en mode texte ont cédé la place aux aventures en mode graphique. La mort de la fiction interactive a plus ou moins coïncidé avec la faillite de Infocom.

Les aventures graphiques sont, en fin de compte, des aventures en mode texte traitées aux anabolisants. Leur degré d'utilisation des graphiques varie fortement. Dans les années 80, ils n'étaient qu'un peu plus que des aventures en mode texte et affichaient un écran rempli de graphiques statiques. Quand vous ramassiez un objet, l'arrière-plan était repeint et l'objet disparaissait. L'exemple type pourrait être les prétendues « aventures en haute résolution » comme The Wizard And The Princess™. Plus tard, les aventures graphiques sophistiquées faisaient déambuler votre personnage à l'écran, et vous pouviez même utiliser une souris, mais l'interface restait purement textuelle.

Ensuite, il y eut les « aventures pilotées à la souris » qui n'avaient plus d'interface textuelle, et disposaient souvent de graphiques dynamiques, comme un chat se baladant dans la pièce pendant que vous décidiez de la prochaine action à effectuer. Dans ce type de jeux, vous pointez un objet (p.ex. un livre) et vous pouvez choisir une action à partir d'une liste déroulante de fonctions. Un genre d'aventure orientée objet. :) Il n'y a pas beaucoup d'aventures graphiques écrites nativement pour Linux. La seule dont je me rappelle est Hopkins FBI™ (qui est mon jeu préféré sous Linux).

Les simulations s'efforcent d'immerger le joueur dans un milieu auquel il n'aurait normalement pas accès. Cela peut être quelque chose comme un avion de chasse ou quelque chose d'imaginaire comme une unité de combat mécanisée. Dans tous les cas, les simulations recherchent le réalisme.

Certaines simulations ne comportent que peu ou pas de stratégie. Elles vous placent simplement dans un cockpit pour vous donner la sensation de piloter un avion. Certaines sont extrêmement complexes, et la frontière est souvent ténue entre les simulations et les jeux de stratégie. Un bon exemple serait Heavy Gear III™ ou Flight Gear™. De nos jours, les jeux de simulation et de stratégie sont pratiquement indissociables mais, il y a longtemps, les simulations se déroulaient en temps réel alors que les jeux de stratégie se jouaient au tour à tour. Cette dénomination est maladroite de nos jours, car un jeu comme Warcraft™, que tout le monde considère être un jeu de stratégie, serait une simulation par définition.

Les jeux de stratégie descendent des vieux jeux de plateau de type Avalon™ comme Panzer Leader™ et des vieux jeux de stratégie militaire publiés par SSI. Généralement, ils simulent quelque type de scénario. Il peut être pacifique, comme la gestion réussie d'une ville (SimCity™), ou pas, comme la vente illégale de drogue (DrugWars™) ou un jeu de stratégie militaire acharné comme Myth II™. Ce type de jeux a habituellement une longue durée de vie et requiert beaucoup de réflexion.

Les jeux de stratégie peuvent être à leur tour subdivisés en deux classes : le temps réel et le tour à tour. Les jeux de stratégie en temps réel sont basés sur le principe « un petit moment d'inattention, et c'est perdu ». Par exemple, vous gérez une ville et un incendie se déclenche quelque part. Au plus il vous faut du temps pour mobiliser les pompiers, au plus l'incendie fera du dégât. Les jeux de stratégie au tour à tour sont similaires aux échecs : l'ordinateur joue, puis c'est au tour du joueur, et cætera.

Quelle est cette lumière au loin ? Cela doit être l'éclair du fusil de chasse à double canon ! L'histoire des jeux FPS est longue et tortueuse et a commencé quand id Software a ouvert le code source de Doom™. Ce code a été repris (par d'autres équipes) et fusionné à de nombreuses reprises. D'autres moteurs précédemment fermés se sont ouverts, beaucoup de moteurs sont jouables via des émulateurs, beaucoup de jeux FPS commerciaux ont été publiés pour Linux et nombre de moteurs FPS étaient des projets open source à l'origine. Bien qu'il se peut que vous ne puissiez pas jouer à votre jeu FPS préféré sous Linux (Half-Life™ marche très bien sous winex), Linux ne présente certainement aucune lacune dans ce domaine !

Les FPS sont caractérisés par deux choses. Primo, vous tirez à peu près sur tout ce qui bouge. Secundo, l'action a lieu à la première personne, c.-à-d. au travers des yeux du personnage que vous interprétez. Vous pouvez même voir vos mains ou votre arme en bas de l'écran. Ils peuvent être du type fantastique (Hexen™), science-fiction (Quake II™), réaliste (Soldier Of Fortune™) parmi bien d'autres possibilités.

Tout comme les aventures en mode texte, les FPS obéissent au format moteur/fichier de données. Le moteur représente le jeu en lui-même (Doom™, Quake™, Heretic2™) et utilise les niveaux et les méchants décrits par les fichiers de données (doom2.wad, pak0.pak, etc). Beaucoup de jeux FPS permettent de créer ses propres fichiers de données non commerciaux. Il y a des centaines, si pas des milliers, de fichiers de données pour Doom™ que vous pouvez télécharger gratuitement depuis Internet. Souvent, les sociétés libèrent leurs moteurs afin que la communauté open source puisse les améliorer. Néanmoins, les fichiers de données originaux restent propriétaires. À ce jour, vous devez toujours acheter doom.wad.

Les jeux à défilement horizontal sont similaires aux FPS mais vous voyez votre personnage comme une figure 2D qui court sur plusieurs écrans en tirant ou en effectuant d'autres tâches. Par exemple, il y a Abuse™ pour Linux et le Duke Nukem™ original. Ils ne sont pas nécessairement violents, comme xscavenger™, un clone du vieux jeu 8 bits Lode Runner™.

Similaires aux FPS, mais vous voyez votre personnage à la troisième personne et en 3D. Dans les jeux de combat à la troisième personne modernes, vous pouvez en général réaliser des manœuvres dévastatrices comme les retournés acrobatiques et les roulades à la Jackie Chan. L'exemple type serait Tomb Raider™. Sous Linux, on dispose de Heretic 2™ et de Heavy Metal FAKK2™.

Quiconque a déjà joué à des jeux du style Dungeons & Dragons™ ou Call of Cthulhu™ sait exactement ce qu'est un RPG. Vous interprétez un personnage (parfois plusieurs) doté de certaines caractéristiques (p.ex. force, dextérité), d'aptitudes (p.ex. explosifs, confection de paniers, mécanique) et de propriétés (niveaux, argent liquide). Au fil du temps, le personnage devient plus puissant et le jeu s'adapte en conséquence : p.ex., au lieu de combattre des orcs, vous commencez à combattre des dragons noirs dans les plus hauts niveaux. Les récompenses augmentent en conséquence. Dans les bas niveaux, vous pourriez obtenir quelques pièces d'or comme récompense suite à la victoire dans une bataille ; plus loin, vous pourriez obtenir une épée magique ou un fusil d'assaut ravageur.

Les RPG proposent généralement une quête ayant un épilogue bien déterminé. Dans nethack™, vous devez retrouver l'amulette de Yendor pour votre dieu. Dans Ultima II™, vous détruisez la sorcière maléfique Minax. À un certain moment, votre personnage devient suffisamment puissant pour pouvoir vous lancer et essayer de terminer la quête.

Bien que la série immensément populaire des Ultima™, écrite par Richard Garriot (alias Lord British) pour Origin, n'était pas le premier RPG, elle a popularisé et propulsé le genre RPG sur le devant de la scène. Ultima I™ a été publié en 1987 et est le point de départ de 9 (en fonction du mode de comptage) suites très populaires, se terminant par Ultima IX: Ascension™. Vous pouvez jouer à Ultima VII™ sous Linux avec Exult.

Le jeu RPG type sous Linux est Rogue™ (la bibliothèque ncurses était à l'origine une routine de traitement d'écran pour Rogue™ !) et on en décline des tas de variantes comme Zangband™ et Nethack™ (qui a lui-même de nombreuses variantes). Certains RPG sont assez compliqués et constituent de véritables exploits de programmation. Il semble y avoir une carence en RPG commerciaux sous Linux. Si l'on ne compte pas les variantes de Rogue™, c'est également le cas des RPG open source.

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.

Que vous essayiez de diagnostiquer un problème X ou que vous requerriez de l'aide sur une liste de diffusion ou un groupe de discussion Usenet, vous devrez disposer d'un maximum d'informations. Voici quelques outils qui peuvent vous y aider :

    X -probeonly 2> X.out
          

    (--) probed              (**) from config file    (==) default setting
    (++) from command line   (!!) notice              (II) informational
    (WW) warning             (EE) error               (??) unknown.
          

    (**) TDFX(0): Depth 16, (--) framebuffer bpp 16
          

    (--) Chipset 3dfx Voodoo5 found
    (--) TDFX(0): VideoRAM: 32768 kByte Mapping 65536 kByte
          

Quand vous jouez à un jeu sous X, vous devriez envisager de ne pas utiliser de gestionnaire de fenêtres. Des « poids lourds » comme enlightenment produiront un ralentissement perceptible ; même des plus légers comme twm vous volent des cycles processeur (et dans le cas de twm, même les jeux plein écran auront un cadre autour de leur fenêtre). Pour exécuter un jeu sans gestionnaire de fenêtres, modifiez .xinitrc dans votre répertoire personnel. Voici à quoi ressemble mon .xinitrc :

        #quake3 +set r_gldriver libGR.so.1
        #exec ut
        #lsdldoom -server 2
        #exec tribes2
        exec /usr/bin/enlightenment
      

Vous y remarquerez généralement un gestionnaire de fenêtres et/ou de bureau (GNOME ou KDE). Commentez les lignes contenant un gestionnaire de fenêtres et/ou de bureau avec un signe dièse (#) et placez votre jeu sur une nouvelle ligne accompagné des arguments de ligne de commandes éventuels. Si votre jeu n'est pas situé dans votre $PATH, donnez le nom de chemin complet. Notez que ceci ne s'applique qu'aux personnes utilisant startx pour démarrer X.

Je n'utilise jamais des choses comme gdm ou le niveau d'exécution 5 (je ne suis donc pas sûr de mon fait), mais je suspecte que si vous le faites, vous devrez agir un peu différemment. Ma recommandation est d'aller en mode mono-utilisateur (niveau d'exécution 1) avec :

    # telinit 1
    

ensuite d'éditer .xinitrc, et de revenir au niveau 5 avec

      # telinit 5
      

Ensuite, quand vous arrêtez de jouer, allez au niveau 1, modifiez .xinitrc et revenez au niveau 5. Je n'ai jamais expérimenté cela, et je ne peut donc pas me prononcer avec certitude, mais vous pourriez devoir tuer gdm. J'apprécierai du retour à ce sujet.

À partir des processeurs de classe Pentium (y compris Athlon, K6-2 et d'autres CPU), ces registres (Memory Type Range Registers, MTRR) contrôlent la façon dont le processeur accède aux intervalles d'adresses mémoire. Pour résumer, ce mécanisme remplace plusieurs petites écritures séparées sur la carte vidéo par une seule écriture (une rafale). Cela améliore l'efficacité des écritures sur la carte vidéo et peut accélérer le rendu graphique de 250 % voire plus !

Voyez /usr/src/linux/Documentation/mtrr.txt pour les détails. Notez que, depuis que ce fichier a été écrit, XFree86 a été amélioré pour détecter automatiquement l'adresse de base et la taille de votre RAM vidéo et configurer les MTRR.

Un problème souvent rencontré est un fichier de bibliothèque non trouvé. Ils sont quelque peu mystérieux et ont des noms bizarres ; nous en parlerons donc un peu. Il y a deux types de bibliothèques, les statiques et les dynamiques. Quand vous compilez un programme, gcc utilise par défaut les bibliothèques dynamiques, mais vous pouvez lui faire utiliser des bibliothèques statiques en utilisant l'option -static. À moins que vous n'ayez l'intention de compiler des jeux à partir du code source, vous serez principalement intéressés par les bibliothèques dynamiques.

    /usr/lib/libSDL.so
    /lib/libm.so.3
      

    /usr/lib/libSDL.a
    /usr/lib/libm.a
      

    % nm /usr/lib/libm.a
    ...
    e_atan2.o:
    00000000 T __ieee754_atan2
    
    e_atanh.o:
    00000000 T __ieee754_atanh
    00000000 r half
    00000010 r limit
    00000018 r ln2_2
    ...
      

Relis ton fameux manuel. Le « manuel » peut revêtir plusieurs formes. Pour les jeux open source, on peut trouver les fichiers readme (« lisez-moi »). Les jeux commerciaux sont accompagnés d'un manuel imprimé et éventuellement de quelques fichiers readme sur le CD. N'oubliez pas d'explorer le CD de votre jeu pour obtenir des astuces et des conseils utiles.

N'oubliez pas le site web du jeu. Son auteur a probablement déjà eu affaire à maintes reprises à des personnes ayant exactement le même problème que vous, et il pourrait avoir placé des informations spécifiques à ce jeu sur son site web. Un bon exemple : les FAQ en ligne de Loki Software situées sur http://faqs.lokigames.com.

Si vous jouez à un jeu open source que vous avez compilé, assurez-vous de disposer de la version la plus récente en visitant le site web du jeu. Si votre jeu fait partie d'une distribution, assurez-vous qu'il n'y ait pas de paquet rpm/deb plus à jour pour le jeu.

Les sociétés produisant des jeux commerciaux comme Loki publient des correctifs pour leurs jeux (souvent nombreux, p.ex. pour Myth2™), et certains sont même injouables en leur absence (Heretic2™). Recherchez des correctifs sur le site web du jeu que vous ayez un problème avec le jeu ou pas ; il peut y avoir une mise à jour pour un problème de sécurité dont vous pourriez ne pas avoir eu connaissance.

À propos, Loki propose maintenant un utilitaire qui recherche les logiciels Loki sur votre disque dur et les met à jour automatiquement. Consultez http://updates.lokigames.com.

Si vous ne savez pas ce que sont les News (Usenet), alors ça vaut la peine de prendre 30 minutes pour vous y frotter. Installez un lecteur de News. Je préfère les outils en console, et j'utilise donc tin, mais slrn est également populaire. Netscape propose également un chouette lecteur de News graphique piloté à la souris.

Par exemple, je peux me promener sur le serveur de News de Loki Software avec tin -g news.lokigames.com. Vous pouvez également spécifier quel serveur de News utiliser grâce à la variable d'environnement $NNTP ou le fichier /etc/nntpserver.

Chaque soumission faite sur Usenet est archivée dans la base de données de Google sur http://groups.google.fr. Cette archive était située sur http://www.deja.com, mais a été rachetée par Google. Beaucoup de personnes parlent toujours de « deja ».

Il est presque sûr que quel que soit le problème que vous avez avec Linux, qu'il ait ou pas un rapport avec le jeu, il a déjà été reporté et solutionné sur Usenet, pas une, pas deux, mais de nombreuses fois. Si vous ne comprenez pas la première réponse que vous voyez (ou si elle ne fonctionne pas), essayez l'une des suivantes. Si la page n'est pas dans une langue que vous comprenez, il existe des tas de sites de traduction qui convertiront le texte dans la langue que vous préférez, comme http://www.freetranslation.com et http://translation.lycos.com. Mon navigateur web préféré, Opera™ (disponible sur http://www.opera.com) vous permet d'utiliser le bouton droit de la souris pour sélectionner un extrait de texte, et de cliquer avec le bouton gauche sur la sélection pour le traduire. Très utile quand une recherche sur Google Groupes renvoie une page en allemand qui semble utile et que ma petite amie (qui lit bien l'allemand) n'est pas disponible.

La recherche sur Google Groupes propose une page de recherche élémentaire et avancée. Ne perdez pas de temps avec la recherche simple. La recherche avancée est située sur http://groups.google.com/advanced_group_search.

C'est facile à utiliser. Par exemple, si mon problème est que Quake III™ plante à chaque fois que Lucy saute, j'entre « linux quake3 crash lucy saute » dans la boîte de texte « Retrouver les messages avec tous les mots suivants ».

Certains champs permettent de limiter la portée de votre recherche à un groupe de discussion. Prenez le temps de lire et de comprendre la signification de chaque champ. Je vous le promets : ce service ne vous décevra pas. Utilisez-le, et vous serez quelqu'un de beaucoup plus heureux. Notez bien que les groupes de discussion privés ne sont pas archivés, comme le serveur de News de Loki Software. Néanmoins, vu que beaucoup de personnes utilisent Usenet, cela n'a généralement que peu d'importance.

Ce n'est généralement pas quelque chose que vous ferez pour les jeux commerciaux. Pour les jeux open source, vous pouvez aider l'auteur en lui fournissant un fichier core ou une trace de la pile. En bref, un fichier core (dit « core dump ») est un fichier qui conserve l'état du programme au moment où il s'est crashé. Il contient des indices précieux pour le programmeur relatifs à la nature du crash : ce qui l'a causé et ce que le programme faisait quand il s'est produit. Si vous voulez en savoir plus sur les fichiers core, j'ai un super tutoriel gdb disponible sur http://www.dirac.org/linux.

En dernier recours, l'auteur sera intéressé par la pile d'appels au moment du plantage du jeu. Voici comment procéder :

Il arrive que les distributions configurent leur système d'exploitation en sorte que les fichiers core (qui sont principalement utiles aux programmeurs) ne sont pas générés. La première étape est d'autoriser votre système à générer des fichiers core de taille illimitée :

    ulimit -c unlimited
      

Vous devrez maintenant recompiler le programme et passer l'option -g à gcc (l'explication dépasse la portée de ce document). À présent, exécutez le jeu et répétez ce qui a fait planter le programme pour générer à nouveau un fichier core. Exécutez le débogueur avec le fichier core comme second argument :

    $ gdb ExécutableJeuChouette core
      

À l'invite, tapez backtrace. Vous verrez quelque chose comme :

    #0 printf (format=0x80484a4 "z is %d.\n") at printf.c:30
    #1 0x8048431 in display (z=5) at try1.c:11
    #2 0x8048406 in main () at try1.c:6
      

Cela peut être assez long, mais utilisez votre souris pour copier et coller ces informations dans un fichier. Envoyez-le par courriel à l'auteur et indiquez-lui :

Si vous avez une bonne bande passante, demandez à l'auteur s'il souhaite le fichier core généré par son programme. S'il est d'accord, envoyez-le lui. N'oubliez pas de lui demander au préalable, car les fichiers core peuvent être très, très gros.

Si votre jeu permet de sauvegarder des parties, alors l'envoi à l'auteur d'une copie de la partie sauvegardée est utile car cela lui permet de reproduire le dysfonctionnement. Pour les jeux commerciaux, cette possibilité est plus fructueuse que d'envoyer un fichier core ou une pile d'appels car les jeux commerciaux ne peuvent être recompilés de sorte à inclure des informations de débogage. Vous devriez impérativement demander avant d'envoyer une partie sauvegardée car ils ont tendance à être gros, mais une société comme Loki Software dispose de beaucoup de bande passante. Mike Phillips (un ancien de Loki Software) indique que l'envoi de sauvegardes de jeux à Loki est définitivement une bonne chose.

Évidemment, cela ne s'applique que si votre jeu plante de façon reproductible dans certaines circonstances. Si le jeu vous donne une erreur de segmentation (segmentation fault) à chaque fois que vous l'exécutez, ou est incroyablement lent, une sauvegarde de jeu n'aura que peu d'utilité.

Parfois, vous verrez des messages d'erreur indiquant qu'un fichier n'a pu être trouvé. Le fichier pourrait être une bibliothèque :

    % ./exult 
    ./exult: error while loading shared libraries: libSDL-1.2.so.0: cannot load shared object
    file: No such file or directory
      

ou un fichier de données, comme un fichier wad ou map :

    % qf-client-sdl  
    IP address 192.168.0.2:27001 UDP Initialized Error: W_LoadWadFile: couldn't load gfx.wad
      

Supposez que gfx.wad est déjà sur mon système, mais qu'il ne peut être trouvé étant donné qu'il n'est pas dans le bon répertoire. Mais alors, où est le bon répertoire ? Ne serait-il pas utile de savoir où ces programmes recherchent les fichiers manquants ?

C'est ici que strace brille. Il vous indique quels appels système sont effectués, avec quels arguments, et quelles sont les valeurs de retour. Dans mon « Guide de programmation de modules noyau » (à paraître bientôt sur le LDP), je souligne tout ce que vous devez savoir sur strace. Mais voici les grandes lignes : saisissez la commande

    strace -o ./LS_LOG /bin/ls
      

L'option -o envoie la sortie de strace dans un fichier, ici LS_LOG. Le dernier argument de strace est le programme à surveiller, ici ls. Regardez le contenu de LS_LOG. Assez impressionnant, n'est-ce pas ? Voici une ligne typique :

    open(".", O_RDONLY|O_NONBLOCK|0x18000)  = 4
      

Nous avons utilisé l'appel système open() pour ouvrir « . » avec divers arguments, et la valeur de retour de l'appel est 4. Quel est le rapport avec les fichiers non trouvés ?

Supposez que je veuille regarder la démo de StateOfMind™ car je ne m'en lasse pas. Un jour, j'essaie de l'exécuter et quelque chose se passe mal :

% ./mind.i86_linux.glibc2.1 
Loading & massaging...
Error:Can't open data file 'mind.dat'.

Utilisons strace pour détecter l'endroit où le programme recherchait le fichier de données.

    strace ./mind.i86_linux.glibc2.1 2> ./StateOfMind_LOG
      

Lançant vim et recherchant toutes les occurrences de mind.dat, je trouve les lignes suivantes :

    open("/usr/share/mind.dat",O_RDONLY) = -1 ENOENT (No such file)
    write(2, "Error:", 6Error:)   = 6
    write(2, "Can\'t open data file \'mind.dat\'."..., ) = 33
      

Je ne recherchais mind.dat que dans un seul répertoire. Il apparaît clairement que mind.dat n'est pas dans /usr/share. Nous pouvons maintenant essayer de localiser mind.dat et de le déplacer dans /usr/share ou, mieux, créer un lien symbolique.

Cette méthode fonctionne également pour les bibliothèques. Supposez que la bibliothèque libmp3.so.2 est située dans /usr/local/include mais que votre nouveau jeu Kill-Metallica™ ne le trouve pas. Vous pouvez utiliser strace pour déterminer où Kill-Metallica™ doit rechercher la bibliothèque et créer un lien symbolique de /usr/local/include/libmp3.so.2 vers l'endroit où Kill-Metallica™ recherchait le fichier de bibliothèque.

strace est un utilitaire très puissant. Quand vous essayez de savoir pourquoi quelque chose n'est pas trouvé, il est votre meilleur allié, et est même plus rapide que la consultation du code source. De plus, vous ne pouvez pas rechercher d'informations dans le code source des jeux commerciaux de Lokisoft ou Tribsoft. Mais vous pouvez toujours utiliser strace !

Parfois, un jeu se termine anormalement et votre console se retrouve alors dans un état bizarroïde : le texte à l'écran est du charabia, votre bel écran noir habituel ressemble à un écran semi-graphique, et cætera. Quand vous tapez sur Entrée, un retour à la ligne n'est pas reproduit à l'écran. Parfois, certaines touches du clavier ne répondent pas. La déconnexion suivie d'une reconnexion ne marche pas toujours, mais il y a d'autres possibilités :

Notez que si vous utilisez un système de fichiers journalisé comme ext3, reiserfs ou xfs, l'appui sur le bouton Power n'est pas aussi néfaste que cela. Vous êtes toujours supposé arrêter la machine d'une façon ordonnée, mais l'intégrité du système de fichiers sera préservée. Vous ne verrez normalement pas de fsck pour les partitions qui utilisent le système de fichiers journalisé.

Quand un ordinateur se bloque, le clavier et la souris ne répondent plus du tout. C'est une conséquence directe d'un bogue dans le noyau Linux. Bien que Linux soit réputé pour sa stabilité, de telles choses peuvent arriver, en particulier avec les jeux qui occasionnent des événements matériels extrêmement synchronisés se produisant très rapidement, même pour un ordinateur. Quand un ordinateur se bloque, cela peut être un « blocage total », signifiant que le noyau a complètement cessé de fonctionner. Cela indique souvent que le matériel est en cause. Le seul remède à ce type de blocage est d'appuyer sur le bouton Reset ou Power. Le blocage peut également être « léger », à savoir que le noyau fonctionne toujours dans une certaine mesure. Il est possible de se remettre gracieusement de cette situation.

Pour prendre en charge la touche magique SysRq, votre noyau doit avoir été compilé à cet effet. Vous trouverez cette option sous « Kernel Hacking | Kernel Debugging | Magic SysRq key ». Si la séquence magique SysRq n'éteint pas correctement votre système, votre noyau s'est réellement bien planté et le seul remède est d'utiliser le bouton Reset ou Power.

Il était une fois, une société de San Jose, en Californie, appelée 3dfx Interactive™ dominait le marché des cartes vidéo destinées au jeu. En octobre 1996, elle a mis sur le marché la Voodoo I, qui a connu un succès phénoménal. C'était la première carte proposant une accélération matérielle, mais elle n'effectuait que du rendu 3D ; il fallait une seconde carte vidéo 2D de haute qualité pour effectuer le rendu 2D (Matrox était immensément populaire à l'époque) alors que les informations 3D (voyez Glide2, à la Section 3.1, « Glide2 ») sont transmises à la Voodoo I et rendues, en utilisant le matériel rapide de la Voodoo pour effectuer les calculs graphiques nécessaires. La Voodoo Rush est sortie en avril 1996. Elle aurait dû être plus puissante, avec un GPU cadencé à 50 Mhz et 8 Mo de RAM. Mieux encore, elle constituait leur première carte combinée 2D/3D, libérant un port PCI précieux (la plupart des PC n'avaient que deux ports PCI à l'époque) mais la Rush n'a pas été aussi populaire. 3dfx a supprimé l'unité multi-textures de la Rush, qui a dès lors été surclassée par la Voodoo I. Pendant ce temps-là, ATI produisait sa série de Rage et nVidia celle de Riva 128, mais la Voodoo I dominait toujours largement.

C'était une belle époque pour Linux. id Software avait libéré le code source de Doom et porté Quake I sous Linux (décembre 1996). Nous goûtions pour la première fois au jeu commercial réel. Le choix était vite fait : vous achetiez une Voodoo. Et vous vous sentiez bien, car 3dfx avait ouvert ses pilotes. La reine des cartes vidéo fonctionnait grâce à des développeurs Linux. Non seulement nous disposions des meilleures cartes vidéo, mais de plus leurs pilotes étaient tous open source.

En mars 1998, 3dfx lançait la Voodoo II, avec sa bande passante mémoire de 3.6 Go/sec, 12 Mo de mémoire vidéo et un cœur fonctionnant à 90 MHz. Elle permettait des résolutions allant jusqu'à 1024x768. C'était 3dfx à son apogée. Comme la Voodoo I, la Voodoo II était une carte ne s'occupant que de la 3D, et se reposant sur une autre carte vidéo pour la 2D. La Voodoo Banshee est sortie en septembre 1998 comme une carte combinée 2D/3D, comme la Rush. Malgré un cœur plus rapide fonctionnant à 100 MHz, la Banshee était dépassée par la Voodoo II du fait de la suppression de l'unité multi-textures, comme pour la Rush. Et à nouveau, comme la Rush, elle n'était pas populaire. Mais 3dfx régnait en maître, et personne ne pouvait leur faire de l'ombre.

La Voodoo III est sortie en avril 1999. Il y en a eu plusieurs, au cœur variant de 143 à 183 MHz. Certaines versions disposaient d'une sortie TV. Il y avait des versions PCI et AGP (c'était la première carte vidéo AGP). C'était un autre succès, mais 3dfx commençait à perdre du terrain au profit de nVidia, qui produisait la TNT 2. Celle-ci surclassait la Voodoo II, et offrait une accélération 3D avec des couleurs 32 bits, alors que les Voodoo étaient limitées aux couleurs 16 bits. Mais la vie était toujours belle pour Linux. Nous disposions d'une carte qui était pratiquement au coude à coude avec nVidia, nos pilotes étaient open source et, en décembre 1999, id Software nous a fait un grand cadeau : ils ont ouvert le code source de Quake I.

Ensuite, la GeForce 256 de nVidia est apparue en octobre 1999. La Voodoo IV de 3dfx, son concurrent direct, avait à peu près une année de retard, ce qui est pour le moins ennuyeux quand on se bat sur un marché « de pointe ». Alors que les travaux en recherche et développement de nVidia étaient appliqués à ses cartes, 3dfx ne faisait qu'ajouter de la RAM plus rapide. Les Voodoo IV et V rendaient les couleurs 32 bits, prenaient très bien en charge l'anti-crénelage, proposaient un second GPU, plus de mémoire, et étaient pour ainsi dire supérieures aux autres cartes vidéo. Néanmoins, la sortie tardive des Voodoo IV et V couplée au fait qu'on pouvait obtenir la GeForce pour moitié moins explique le naufrage rapide de 3dfx. Pour Linux, les plus récentes Voodoo ne pouvaient accélérer que pour les couleurs 16 et 24 bits. Pire encore, le second GPU de la Voodoo V n'était pas exploité par le pilote Linux (et, à ce jour, la Voodoo V est fonctionnellement équivalente à la Voodoo IV sous Linux). La plupart des utilisateurs Windows sont passés à nVidia et, bien que les pilotes de cette dernière étaient propriétaires, même les utilisateurs Linux commençaient à la choisir. VA Linux, le plus grand vendeur des serveurs Linux, plaçait des nVidia dans ses machines.

Ensuite, en avril 2000, 3dfx a été attaqué sur un autre front : ATI commençait à produire sa première génération de Radeon. Auparavant, ATI avait toujours été un fabricant de puces graphiques innovant (leurs propres puces accélératrices 3D datent de 1996, à peu près au même moment que 3dfx), mais fort discret. Les Radeon étaient leur première carte accélératrice 3D à réellement intéresser les joueurs. Leurs Radeon écrasaient à la fois nVidia et 3dfx. Ils ont collaboré avec des développeurs Linux, ont ouvert le code source de tous leurs pilotes et ont été acclamés comme le grand espoir pour le jeu sous Linux. nVidia revint à la charge, et c'en était trop pour 3dfx. Entre la défaite dans les bancs d'essais contre la GeForce et la Radeon, leurs nouvelles cartes en retard et leurs prix élevés, 3dfx avait perdu sa part de marché et n'avait plus les fonds nécessaires pour continuer ses activités. Le 18 avril 2001, ils ont vendu la plupart des leurs avoirs et technologies à nVidia et, en octobre 2002, ont finalement fait aveu de faillite.

La disparition de 3dfx était très soudaine et une gifle pour la communauté open source. Je me souviens toujours de mon ami Gabe Rosa m'envoyant un courriel avec ces simples mots « Look at /. » (Va voir sur slashdot) et la vision de la nouvelle. C'était le 2e jour le plus sombre de l'histoire du jeu sous Linux (après la mort de Loki). Et c'était aussi vraiment dommage. 3dfx était sur le point de sortir une nouvelle Voodoo V avec 4 GPU qui aurait écrasé les offres de ATI et nVidia, ainsi qu'une nouvelle carte au nom de code « Rampage » qui les auraient ramené sur le devant de la scène. On raconte que la technologie de Rampage (qui a été vendue à nVidia) s'est retrouvée dans la GeForce 5900. Pas trop mal pour une technologie vieille de 3 ans !

Au début, tout était simple. Les joueurs Linux gardaient soit leurs Voodoo open source, acquéraient une Radeon open source ou une GeForce propriétaire. Néanmoins, les jeux grossissant et s'améliorant, ce n'était qu'une question de temps avant que les Voodoo ne soient plus viables pour les jeux modernes. Certains utilisaient toujours des Voodoo, mais ces personnes étaient pratiquement hors du coup en ce qui concerne le jeu.

ATI a produit un nombre incroyable de versions de chaque carte vidéo, et il devenait difficile de suivre l'évolution de leur terminologie. ATI et nVidia dominaient le marché. Leurs produits ont toujours été au coude à coude depuis lors, la GeForce prenant l'avantage un peu plus souvent que la Radeon. Mais les pilotes de la Radeon étaient open source, et de nombreux utilisateurs Linux lui restaient fidèles. Ensuite, cela s'est compliqué.

ATI a commencé à devenir de plus en plus réticent aux pilotes open source pour leurs nouvelles cartes et, soudainement, il n'était plus facile de savoir qui était le « bon ». L'excuse de nVidia était qu'une partie de leur code GL est sous licence d'une autre société, et ne peut par conséquent pas être « libérée ». Vraisemblablement, ATI ne veut pas collaborer afin de conserver ses secrets de fabrique. Et cela ne s'arrange pas. Les pilotes ATI Linux ont souffert de performances extrêmement faibles. Même quand une offre de ATI est meilleure que celle de la GeForce du moment pour Windows, la carte est toujours écrasée par la GeForce sous Linux. Du fait de pilotes ATI Linux calamiteux, les utilisateurs Linux ne peuvent se fier aux bancs d'essais ou aux tests de cartes prévus pour MS Windows. Ils ne sont tout simplement pas appropriés. Et c'est à peu près au point où nous en sommes pour le moment.

Finalement, le seul véritable banc d'essais des cartes vidéo sous Linux date malheureusement, à ma connaissance, de mars 2001, entre une Radeon 32 DDR et une GeForce 2. Vous pouvez le consulter vous-même sur http://www.linuxhardware.org/features/01/03/19/0357219.shtml, mais la conclusion est que la GeForce 2 domine de la tête et des épaules la Radeon 32 DDR.

La dernière offre de nVidia est la GeForce 5900, basée sur le jeu de composants NV35. Elle est bien prise en charge sous Linux par des pilotes de haute qualité mais propriétaires. Ils ne fournissent pas d'informations aux développeurs Linux, et vous ne pourrez donc utiliser que leurs pilotes binaires ; ils ne font pas partie de XFree86. nVidia utilise une architecture unifiée pratique : leurs pilotes prennent en charge de la TNT 2 à la GeForce 5900.

ATI a travaillé avec les développeurs Linux pour toutes les Radeon jusqu'à la Radeon 9200. Ces cartes font l'objet d'une prise en charge 2D et 3D dans XFree86. Je ne suis pas entièrement sûr de la qualité de ces pilotes open source ; néanmoins, Soldier of Fortune I™ et Heavy Metal™ ont toujours des problèmes de textures opaques avec la première génération de Radeon. Après la 9200, vous devez utiliser les pilotes binaires propriétaires, disponibles au format rpm, depuis le site web de ATI. Ces pilotes sont abominables : un de mes amis m'affirme que sa GeForce 4400 surclasse sa Radeon 9700 pro. C'est une honte !

Sur le papier, et selon les bancs d'essais pour Windows, la Radeon 9800 écrase la mal-conçue GeForce 5800 et dépasse légèrement la GeForce 5900. Sur le papier, elle est tout simplement la carte la plus impressionnante. Mais, à nouveau, le problème des pilotes ne nous permet pas d'en bénéficier. Si vous désirez acheter la meilleure carte pour Linux, vous devrez utiliser la GeForce 9800. Préparez-vous simplement à manger des nouilles pendant quelques mois : les deux cartes sont excessivement chères.

La réponse était très difficile l'an dernier, mais voici mon opinion :

En fin de compte, la plupart devrait acheter une GeForce pour le moment.

Parlons à présent de la terminologie des cartes vidéo et des graphiques 3D. Ce n'est pas primordial pour faire fonctionner un jeu en pratique, mais cela peut vous aider à décider quelles options matérielles et logicielles vous conviennent le mieux.

Par « meilleure », j'entends « meilleure pour le jeu ». Les joueurs demandent une haute qualité sonore sans trop de paramétrage à effectuer. Les musiciens ont par contre d'autres exigences : le concept de « meilleure carte son » sera probablement différent pour eux. Si vous êtes un musicien, vous devriez consulter le « Guide pratique de la qualité du son sous Linux » (Linux Audio Quality HOWTO).

Maintenant que Linux commence à mûrir, cette question a perdu de son importance. Auparavant, les cartes son sans puce MIDI intégrée (la plupart des cartes son PCI) ne pouvaient pas interpréter le MIDI. C'était principalement un problème pour les jeux comme xdoom™ ou lxdoom™ qui utilisent musserv. De nos jours, il existe des émulateurs MIDI comme Timidity et des bibliothèques comme SDL qui ne requièrent pas de support MIDI matériel. Franchement, j'ai eu beaucoup de cartes et je n'ai pas constaté de différences en ce qui concerne le jeu. Si vous voulez des choses comme la conversion d'un enregistrement LP en format numérique, alors votre choix de carte son se portera sur un convertisseur analogique/numérique de niveau professionnel. Dans ce guide, nous supposerons que vous êtes plus un joueur qu'un ingénieur du son.

Votre décision devrait se baser sur la facilité de configuration. Si vous avez déjà une carte qui fonctionne bien, c'est suffisant. Si vous explorez le marché pour acheter une carte son, prenez quelque chose qui ne prend qu'une seconde à configurer. Les cartes PCI sont beaucoup plus faciles à gérer que les cartes ISA car vous ne devez pas indiquer à leur pilote quelles ressources système (IRQ, DMA, adresses d'entrée-sortie) utiliser. Certaines cartes ISA sont plug-n-play, comme la Creative AWE-64, et le noyau Linux a beaucoup évolué pour les auto-configurer.

Ma recommandation personnelle est une carte à base de es1370 ou es1371, qui utilise les pilotes son es1370 et es1371 sous Linux. Ces cartes vont de la plus ancienne Ensoniq es1370 à la plus récente Creative PCI-128. Ces cartes sont très bon marché et triviales à faire fonctionner sous Linux.

J'étais un grand fan des cartes son Creative Soundblaster AWE 32, AWE 64 et AWE 64 gold. Ces cartes ISA PnP sont bien prises en charge à la fois par OSS et par Alsa. Elles utilisent toutes la même puce de synthèse sonore E-mu 8000 qui leur permet de jouer 32 voix simultanément (elles ont 32 « canaux »). Elles sont ISA, mais plug-n-play. Quelques remarques : primo, le Soundblaster AWE HOWTO est très dépassé. Secundo, la AWE 64 et la AWE 64 gold peuvent jouer jusqu'à 64 voix simultanément, mais cela est fait en logiciel. Creative n'a jamais publié de pilote Linux pour ces cartes (ni n'ont publié d'informations de programmation à ce sujet), et les utilisateurs Linux ne peuvent donc pas utiliser les 32 canaux supplémentaires de la AWE 64 et de la AWE 64 gold. Pour eux, ces trois cartes sont complètement identiques (bien que la AWE 64 gold ait des connecteurs plaqués or, qui offrent une meilleure qualité de son que les connecteurs en acier habituels).

La Creative Soundblaster Live! est une carte son PCI extrêmement populaire de nos jours. Je n'en ai jamais possédé, et je ne peut donc pas vous donner mes impressions. Néanmoins, on a reporté à de nombreuses reprises des problèmes sérieux avec la Live! et les cartes mères AMD qui utilisent le southbridge 686b. Une recherche sur Google devrait produire un tas d'informations sur ce problème.

Un élément plus pertinent est les haut-parleurs, mais même ici la différence n'est pas énorme. J'ai eu des haut-parleurs Altec Lansing coûteux qui ne fonctionnent que légèrement mieux que les haut-parleurs bon marché. Tout dépend du prix que vous êtes disposé(e) à mettre, mais ne vous attendez pas à de grosses différences. Vous devriez vous procurer quelque chose avec un caisson de basses séparé : les différences sont perceptibles au prix de câbles d'alimentation et de connecteurs supplémentaires.

Tout d'abord, votre jeu n'est probablement pas en cause ; il s'agit probablement de votre configuration. À ma connaissance, il y a 3 possibilités pour faire fonctionner une carte son configurée sous Linux : les pilotes son libres OSS accompagnant le noyau Linux, les pilotes Alsa et les pilotes son OSS commerciaux. Personnellement, je préfère les pilotes OSS, mais beaucoup ne jurent que par Alsa. Les pilotes commerciaux sont bons quand vous avez du mal à faire fonctionner votre carte son avec des méthodes libres. Ne crachez pas dessus : ils sont très bon marché (du genre 10 ou 20 $), supportent des cartes son du dernier cri et évitent beaucoup d'essai-erreur lors du processus de configuration.

Il y a 5 choses qui peuvent mal se passer avec votre système son :

    $ cat /proc/interrupts
               CPU0       CPU1
      0:   24185341          0          XT-PIC  timer
      1:     224714          0          XT-PIC  keyboard
      2:          0          0          XT-PIC  cascade
      5:    2478476          0          XT-PIC  soundblaster
      5:     325924          0          XT-PIC  eth0
     11:     131326          0          XT-PIC  aic7xxx
     12:    2457456          0          XT-PIC  PS/2 Mouse
     14:     556955          0          XT-PIC  ide0
    NMI:          0          0
    LOC:   24186046   24186026
    ERR:       1353
    

    # lsof /dev/dsp
    COMMAND    PID USER   FD   TYPE DEVICE SIZE   NODE NAME
    mp3blaste 1108    p    6w   CHR   14,3      662302 /dev/dsp
    

    # fuser -vk /dev/dsp
    
                         USER        PID ACCESS COMMAND
    /dev/dsp             root       1225 f....  mp3blaster
                         root       1282 f....  mp3blaster
    

    audio:x:29:toto,lulu
    

XFree86 4.x fournit une approche plus centralisée et plus autonome en ce qui concerne la vidéo. Beaucoup des joyeusetés comme les modules noyau pour un accès non root aux cartes vidéo ont, heureusement, disparu.

Un « véritable ordinateur » fournit beaucoup de choses à un système d'exploitation : CPU, canaux d'entrée-sortie, mémoire, un BIOS pour fournir un accès de bas niveau à la carte mère et aux ressources d'entrée-sortie, et cætera. Quand un système d'exploitation veut écrire sur un disque dur, il communique par l'intermédiaire d'un pilote de périphérique qui fait l'interface directe avec le matériel.

Néanmoins, il est possible de donner à un programme toutes les ressources matérielles dont il a besoin. Quand il veut accéder à un disque dur, donnons-lui de la mémoire où écrire. Quand il veut attribuer une IRQ, donnons-lui l'impression d'avoir attribué une IRQ. Si vous faites ceci correctement alors, en principe, la pauvre application est incapable de savoir si elle accède réellement au matériel ou si on la trompe en lui donnant des ressources qui simulent le matériel. Une machine virtuelle est l'environnement qui trompe les applications en leur faisant croire qu'elles tournent sur une machine réelle. Elle fournit tous les services offerts par un véritable ordinateur.

Les machines virtuelles ont été à l'origine utilisées dans les années 1960 pour émuler les systèmes d'exploitation à temps partagé. De nos jours, nous les utilisons pour exécuter des logiciels qui ont été conçus pour des systèmes d'exploitation différents, ou plus communément, pour émuler un système d'exploitation entier. Du fait de la nature des machines virtuelles, le système d'exploitation étranger ne peut faire la différence entre fonctionnement à l'intérieur d'une machine virtuelle et fonctionnement dans une « vraie » machine.

Tous les émulateurs Apple ][ 8 bits requièrent une copie de la ROM originale, quel que soit le système que vous voulez émuler, dans un fichier. Si vous cherchez suffisamment bien, vous pouvez trouver des copies des ROM pour les Apple ][, ][+, ][e, ][c et //gs. Ils sont toujours propriété de Apple, et vous ne pouvez les utiliser légalement que si vous possédez réellement un de ces ordinateurs.

Lucasarts a écrit un moteur pour les aventures pilotées à la souris nommé SCUMM (Script Creation Utility for Maniac Mansion). Ils ont écrit beaucoup d'aventures graphiques en utilisant SCUMM, comme leur célèbre série Monkey Island™ (tous les trois). Ludvig Strigeus <strigeus CHEZ users POINT sourceforge POINT net> a pu utiliser la rétro-ingénierie pour comprendre le format SCUMM et écrire un interpréteur pour les jeux l'utilisant qui compile sous Linux et Win32. Il s'agit de scummvm. Leur site web est très bon, et regorge d'informations sur SCUMM et l'utilisation de scummvm pour ce type de jeux.

Une page de compatibilité peut être trouvée sur le site web de scummvm. Ça vaut ce que ça vaut, mais j'ai pu finir beaucoup des jeux qui sont listés à 90 % sans le moindre problème. scummvm est très robuste, et vous permet d'acheter des jeux Lucas Arts utilisant le format SCUMM, copier les fichiers de données sur votre disque dur et les jouer sous Linux. En février 2002, j'ai suivi leur CVS, et ce projet subit un développement constant. Gloire à l'équipe de scummvm.

Les anciens jeux d'aventures graphiques DOS de Sierra utilisaient un langage de script appelé AGI (Adventure Gaming Interface). Quelques jeux écrits en AGI : Leisure Suit Larry I™ (EGA), Space Quest I™, Space Quest II™, King's Quest II™, Mixed-Up Mother Goose™, et cætera. On peut y jouer en utilisant sarien, un interpréteur open source pour les jeux AGI.

Sarien a été écrit en SDL, et devrait donc tourner sur toute plate-forme qui peut compiler des programmes SDL. De plus, il y a des versions pour DOS, les PDA utilisant Strong-Arm, QNX (mon dieu ! du jeu embarqué !), les systèmes à base de MIPS et les Pocket PC à base de SH3/4. Les développeurs ont clairement perdu la tête (d'une bonne façon !). Sarien propose de nombreuses améliorations non trouvées dans les jeux originaux, comme une console déroulante du genre de celle de Quake, un visualisateur d'images et de dictionnaire, un son amélioré et la prise en charge de AGDS, un clone russe de AGI. Sarien est en cours de développement et les développeurs ont très bien documenté la conception interne de Sarien si jamais quelqu'un veut s'impliquer dans son développement.

Les jeux d'aventures graphiques plus récents de Sierra (c.-à-d. de la fin des années 80) utilisaient un interpréteur appelé SCI. Il y a beaucoup de versions de SCI puisque Sierra a constamment amélioré son moteur. Les premiers jeux SCI s'exécutaient sous DOS, mais Sierra s'est finalement tourné vers Win32. Quelques exemples de jeux écrits avec SCI : Leisure Suit Larry 1™ (VGA), Leisure Suit Larry 2-7™, Space Quest 3-6™, King's Quest 4-6™, Quest For Glory 1-4™ et beaucoup d'autres. Comparées aux jeux AGI, les aventures SCI ont une meilleure prise en charge de la musique, un moteur plus complexe et des tas de fioritures.

Beaucoup de jeux utilisant SCI (écrits en SCI0) peuvent être joués en utilisant freesci, disponible sur http://freesci.linuxgames.com. Comme Sarien™, FreeSCI peut utiliser beaucoup de cibles graphiques incluant SDL, xlib et GGI, de sorte que ce programme peut compiler et s'exécuter sous un nombre incroyable de plates-formes. Les développeurs ont très bien documenté leur application.

La Z-machine est une machine virtuelle bien documentée conçue par Infocom pour exécuter leurs jeux de fiction interactive. Cela leur permet d'écrire des fichiers de données de jeu d'une façon multi-plates-formes, car seul le moteur lui-même, la Z-machine, est dépendant de la plate-forme. La Z-machine a subi différentes évolutions durant la vie de Infocom, et deux révisions supplémentaires (V7 et V8 créées par Graham Nelson) après la mort de Infocom. Les versions ultérieures disposaient même d'une prise en charge limitée du son et des graphiques !

Un des interpréteurs de Z-machine parmi les plus populaires est Frotz. Leur excellente page d'accueil regorge de liens sympas pour les amateurs de fiction interactive. Frotz est placé sous GPL, exécute toutes les versions de la Z-machine et compile sur la plupart des versions de Unix. Frotz est à l'origine de nombreuses variantes, comme une version pour PalmOS et les PDA à base de Linux.

jzip est un autre interpréteur de Z-machine très populaire qui exécute les fichiers de données des Z-machine V1-V5 et V8. jzip est très portable ; il compile sous tous les Unix, OS/2, Atari ST et DOS.

Il y a en fait beaucoup d'autres interpréteurs de Z-machine comme nitfol et rezrov (écrit en Perl !). Chaque interpréteur a ses points forts, et vous pouvez trouver des liens les référençant sur les pages d'accueil de Frotz et jzip.

On peut dire que Scott Adams est le père de la fiction interactive. Bien qu'il ait lui-même été inspiré par la première œuvre de fiction interactive, Adventure™, Scott a propulsé l'aventure au devant de la scène. Ses jeux étaient disponibles pour Atari, Apple 2, Commodore, Sorcerer, TI et CPM. Sa société, Adventure International, a publié quelques jeux très appréciés entre 1978 et 1984 avant d'arrêter. Elle a récemment publié un nouveau jeu (une version Linux n'est pas disponible) mais depuis le déclin du jeu d'aventure, elle s'est plutôt tenue à l'écart de l'industrie du jeu.

Alan Cox a écrit scottfree, un interpréteur de fichier de jeux d'aventure du type Scott Adams pour Unix. En utilisant scottfree et l'un des fichiers de données du type Scott Adams qui peuvent être téléchargés depuis le site web de Scott, vous pouvez vous délecter de ces classiques.

Le projet Underworld Adventures est un effort visant à porter le classique de 1992, Ultima Underworld: The Stygian Abyss™ sur des systèmes d'exploitation modernes comme Linux, MacOS X et Windows. Il utilise OpenGL pour les graphiques 3D, SDL pour les tâches spécifiques à la plate-forme et est publié sous la GNU GPL. Underworld Adventures fournit un système graphique impressionnant qui utilise les fichiers de jeu originaux, et vous avez donc besoin du disque de jeu original pour jouer.

Underworld Adventures offre également un tas d'outils pour afficher les cartes de niveaux, examiner les scripts de conversation uw1 et bien d'autres choses.

Ultima 7™ en en fait constitué de 2 jeux : la partie I (The Black Gate™) et la partie II (Serpent Island™) qui utilise une version légèrement améliorée du moteur de The Black Gate™. De plus, une disquette additionnelle a été publiée à la fois pour la partie I (The Forge Of Virtue™) et la partie II (The Silver Seed™).

Une équipe a développé exult, un interpréteur open source permettant d'exécuter les deux parties de Ultima 7™ et leurs disquettes additionnelles. Exult est écrit en C++ et utilise SDL, et compilera donc sur toute plate-forme pouvant compiler des programmes SDL. Il offre également certaines améliorations par rapport aux versions originales du moteur de Ultima VII™. Vous devrez acheter une copie de Ultima 7™ pour pouvoir jouer. Les développeurs n'ont pas l'intention d'étendre Exult pour interpréter les autres Ultima étant donné que les moteurs ont changé radicalement entre les différentes versions.

L'équipe d'Exult a également travaillé dur pour créer un éditeur de niveaux, Exult Studio™, et un compilateur de scripts qui permettra aux utilisateurs de créer leurs propres RPG dans le style Ultima™.

System Shock™ est un jeu de combat à la première personne/aventure classique datant de 1994, ce qui le place en contemporain de Doom™. Néanmoins, son moteur est beaucoup plus évolué que celui du Doom™ original : par exemple, System Shock™ disposait d'acteurs (sprites) 3D, d'un angle de vue modifiable (à la souris), et de la possibilité d'empiler des objets, donnant l'illusion d'une carte 3D complète, comme Quake™. Les critiques que j'en ai lues sont très positives. Elles concordent pour dire que ce jeu a les fonctionnalités de Quake™ avec une intrigue et un scénario plus convaincants que Half-life™. Le moteur de System Shock™ était optimisé pour la sophistication, alors que celui de Doom™ était optimisé pour vous balancer des tas de monstres à la figure : une approche complètement différente. Très impressionnant pour un vieux jeu !

Le System Shock Hack Project est une tentative de mise à jour du jeu pour les systèmes d'exploitation modernes. Ce projet utilise SDL, et est publié sous une licence BSD modifiée. Bien que vous ayez besoin des fichiers de jeu originaux pour jouer à SSHP, il devrait fonctionner avec la version de démonstration de System Shock™, qui est disponible gratuitement.

Voici quelques ressources générales pour les joueurs Linux :

Cette section propose des URL qui devraient être mentionnées mais qui ne trouvaient pas leur place dans une section séparée à l'intérieur de ce guide, et que j'ai donc listées ici dans une sorte d'annexe.