Traduction française
Version : 1.0.1.fr.0.9
Copyright © 2001, 2002 Peter Jay Salzman
Copyright © 2003, 2004 Peter Jay Salzman, Frédéric Delanoy
<
p CHEZ dirac POINT org>
/
http://www.dirac.org/p.
Distribué selon les termes de la Open Software License, version 1.1.
9 juin 2004
Historique des versions | |
---|---|
Version 1.0.1.fr.0.9 | 2004-06-09 |
Traduction de la version 1.0.1 du « Linux Gamers' HOWTO » | |
Version 1.0.1 | 2004-02-04 |
Résumé
Les mêmes questions reviennent continuellement sur les listes de diffusion et groupes de discussion Linux. Beaucoup d'entre elles sont dues à la méconnaissance du fonctionnement de Linux, du moins en ce qui concerne le jeu. Jouer peut être malaisé : cela requiert la connaissance d'une très grande étendue de sujets parmi lesquels on trouve les compilateurs, les bibliothèques, l'administration système, la gestion de réseaux, l'administration de XFree86, et cætera, vous voyez le genre. Chaque aspect de votre ordinateur joue un rôle dans le jeu. C'est un sujet exigeant, mais ce fait est occulté par le but principal du jeu : s'amuser et décompresser.
Ce document est un point de départ pour résoudre la plupart des problèmes courants et pour donner aux joueurs les connaissances nécessaires afin de réagir intelligemment en cas de problème avec leurs jeux. Comme de coutume sous Linux, vous devez connaître un peu ce qui se passe en coulisses pour que vos jeux continuent à fonctionner correctement ou pour poser un diagnostic et agir en conséquence dans le cas contraire.
Table des matières
Si vous avez des idées, corrections ou questions relatives à ce
guide, envoyez-moi un courriel. Le fait de recevoir du retour (même
si je n'ai pas le temps de répondre) me donne l'impression que je
fais quelque chose d'utile. Dès lors, cela me motive à écrire plus
encore et à compléter ce document. Vous pouvez me contacter
(NdT : en anglais) à l'adresse
<
p CHEZ dirac POINT org>
.
Ma page web est http://www.dirac.org/p et mes
pages Linux sont situées sur http://www.dirac.org/linux. N'hésitez pas à envoyer
vos commentaires et suggestions relatifs à ce guide. Même si je ne
les retiens pas tous, votre apport est le bienvenu.
N'hésitez pas à faire parvenir tout commentaire relatif à la version
française de ce document à
<commentaires CHEZ traduc POINT org>
.
Je présume une connaissance pratique de Linux, et j'utilise donc certains termes comme les niveaux d'exécution et les modules sans les définir. S'il y a assez de questions (ou même de protestations), j'ajouterai des informations plus basiques à ce document.
![]() | Important |
---|---|
Le texte ci-dessous est la version française de la licence de ce document. Seule la version originale de cette licence, présentée dans la section suivante, fait foi. |
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.
![]() | Important |
---|---|
Le texte ci-dessous est la licence de ce document. Ce texte fait foi. Il est composé de la licence en anglais du document orignal, suivi de la licence en français de sa traduction. |
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 à :
Moritz Muehlenhoff
<jmm CHEZ Informatik POINT uni-bremen POINT de>
qui m'a envoyé des mises à jour (même si je suis éternellement
à la traîne…)
Frédéric Delanoy pour d'importantes différences, corrections de fautes de frappe ou d'erreurs docbook.
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.
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.
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.
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.
Voici différentes bibliothèques consacrées au jeu que l'on peut trouver sous Linux.
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 constitué de 3 parties :
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 :
Les données associées aux sommets de polygones ne doivent pas être codées/décodées via GLX.
Les données graphiques ne sont pas envoyées via une socket au serveur X.
Sur les machines mono-processeur, le CPU ne doit pas changer de contexte entre XFree86 et son client pour rendre les graphiques.
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.
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.
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 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>.
Si vous avez l'intention de jouer sous X, il est primordial que
vous le connaissiez quelque peu. Le « Guide pratique de
l'utilisateur de X Window » (XWindow-User-HOWTO),
et en particulier man XF86Config
constituent des lectures requises. N'essayez pas
d'y échapper : lisez-les. Elles ont un très bon rapport
signal/bruit. Beaucoup de problèmes peuvent être résolus facilement si
vous savez vous y retrouver dans XF86Config
(ou
XF86Config-4
).
X -probeonly 2> X.out
(--) probed (**) from config file (==) default setting (++) from command line (!!) notice (II) informational (WW) warning (EE) error (??) unknown.
Voici un exemple de quelques informations que j'ai pu glaner :
J'utilise des couleurs 16 bits :
(**) TDFX(0): Depth 16, (--) framebuffer bpp 16
X a détecté que la puce et la mémoire RAM de ma carte vidéo sont :
(--) Chipset 3dfx Voodoo5 found (--) TDFX(0): VideoRAM: 32768 kByte Mapping 65536 kByte
les 4 nombres horizontaux et les 4 nombres verticaux qui définissent votre mode vidéo (le premier couple horizontal/vertical indique la résolution de l'écran). Ces 8 nombres vous indiqueront quelle ligne de mode (modeline) votre X utilise. Voyez le « Guide pratique de configuration vidéo de XFree86 » (XFree86-Video-Timings-HOWTO) pour plus d'informations. Notez que des spécifications explicites ne sont plus nécessaires, car XFree 4.0.1 (et les versions ultérieures) les calcule automatiquement à partir des possibilités de votre moniteur et de votre carte vidéo. Néanmoins, c'est parfois utile en cas de matériel exotique ou si vous voulez un peu bidouiller votre affichage.
La « fréquence d'horloge » à laquelle tourne votre carte vidéo.
Si pour une raison quelconque, vous utilisez X 3.3,
suivez les instructions données dans mtrr.txt
(voyez la la section intitulée « Registres d'intervalles
mémoire ») pour configurer les MTRR.
X 4.0 fait cela automatiquement pour vous.
Si vous jouez sous X, n'exécutez pas de gestionnaire de fenêtres, et certainement pas de gestionnaire de bureau comme GNOME ou KDE. Voyez la la section intitulée « Jouer à des jeux sous X sans gestionnaire de fenêtres » pour plus de détails.
Arrêtez tous les processus non essentiels (en tant que
root) en utilisant les scripts de démarrage de votre système.
Sous Debian, les scripts de démarrage pour le niveau d'exécution
2 sont situés dans /etc/rc2.d/
. Vous pouvez arrêter un
service d'une manière ordonnée en envoyant à son script de
démarrage la commande
« stop » :
# cd /etc/rc2.d # ./ntpd stop
Une autre possibilité (radicale) est de simplement vous placer en mode mono-utilisateur avec
# telinit 1
Cela vous débarrassera même de getty ; votre système s'exécutera avec uniquement ce qui est absolument crucial pour son fonctionnement. Il y aura quelque chose comme 10 processus en cours d'exécution. L'inconvénient est que vous devez jouer en tant que root. Mais votre table de processus sera une ville fantôme, et tous les cycles CPU supplémentaires bénéficieront à votre jeu.
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.
À 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.
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 :
le nom du jeu
le message d'erreur qui est apparu à l'écran quand le jeu a planté.
ce qui a provoqué le plantage et s'il est reproductible ou non.
la pile d'appels
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.
% ./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
strace -o ./LS_LOG /bin/ls
open(".", O_RDONLY|O_NONBLOCK|0x18000) = 4
% ./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
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 la section intitulée « 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 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.
Le « mip mapping » est une technique consistant à stocker diverses copies à l'échelle de la même texture dans la mémoire de la carte vidéo, afin de représenter la texture à différentes distances. Quand la texture est très éloignée, une plus petite version de la texture est utilisée. Quand la texture est proche, une plus grande est utilisée. Le mip mapping peut être utilisé quelle que soit la méthode de filtrage. Il réduit non seulement les besoins en bande passante mémoire (puisque les images sont stockées sur le matériel), mais offre également une meilleure qualité d'image.
Le filtrage trilinéaire est un filtre bilinéaire de haute qualité qui utilise les quatre pixels les plus proches du deuxième niveau de mip map (mip map level) le plus approprié pour produire des transitions plus douces entre les niveaux. Le filtrage trilinéaire échantillonne à partir de huit pixels et les intègre avant de calculer le rendu. Le filtrage trilinéaire utilise toujours le mip mapping. Il élimine l'effet de bandes qui apparaît entre des niveaux adjacents. La plupart des cartes vidéo accélératrices 3D peuvent effectuer du filtrage trilinéaire en matériel sans impact sur les performances.
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.
Il y a 5 choses qui peuvent mal se passer avec votre système son :
# 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
Il n'y a que deux façons de configurer votre carte :
Vous pouvez trouver quel pilote utilise votre carte son en
utilisant lsmod ou en examinant la sortie de
dmesg. Étant donné que le son est de première
importance pour moi, je le compile toujours dans mes noyaux. Si
aucun pilote n'est chargé, vous devez déterminer ce qui a été
compilé dans votre noyau. Ce n'est pas si facile. Il vaut mieux
compiler votre noyau. À propos, sachez que la compilation de
votre propre noyau est la première étape vers la compétence sous
Linux. C'est pénible la première fois, mais une fois que c'est fait
correctement, cela devient très facile, en particulier si vous
conservez tous vos anciens fichiers .config
et
utilisez des choses comme make oldconfig
.
Voyez le « Guide pratique du noyau Linux »
(Kernel-HOWTO)
pour les détails.
Si vous n'avez pas compilé votre noyau vous-même, il est très probable que votre système soit configuré de sorte à charger les pilotes son sous forme de modules. C'est ainsi que fonctionnent les distributions. Compilez tout ce qui est possible sous forme de module et essayez de les charger tous. Ainsi, si vous ne voyez pas le pilote de votre carte son avec lsmod, votre carte n'est probablement pas encore configurée.
La première étape est déterminer ce qui se passe.
(II) XXXXXX: direct rendering enabled
(II) XXXXXX: direct rendering disabled
où XXXXXXX dépend de la carte vidéo que vous possédez. Si le rendu direct est désactivé, alors votre configuration X est en cause, et pas le jeu. Vous devez déterminer pourquoi le DRI est désactivé. L'outil le plus important est le « Guide de l'utilisateur DRI » (DRI Users Guide). C'est un document très bien écrit qui vous donne des informations pas à pas sur la façon de configurer correctement le DRI pour votre machine. Une copie est disponible sur http://www.xfree86.org/4.0/DRI.html.
Notez que si vous réussissez ce test, votre système est capable de faire du rendu direct. Vos bibliothèques peuvent toujours être en cause. Passez donc à l'étape 2.
Il existe un programme appelé glxgears qui accompagne le paquet « mesademos ». Vous pouvez obtenir mesademos sous Debian (apt-get install mesademos) ou vous pouvez chercher le rpm sur http://www.rpmfind.net. Vous pouvez également télécharger les sources depuis le site officiel de mesa et les compiler vous-même.
L'exécution de glxgears montrera des pignons en rotation. La xterm depuis laquelle vous exécutez glxgears affichera « X frames in Y seconds = X/Y FPS » (X images en Y secondes). Vous pouvez comparer votre système avec la liste de bancs d'essais ci-dessous.
CPU TYPE VIDEO CARD X VERSION AVERAGE FPS
Compiler les modules Mesa et DRI vous-même peut vous faire gagner 15 images par seconde, une grosse augmentation de performances ! Donc, si vous obtenez, disons, 20 images par seconde de moins qu'une machine comparable, il est possible que glxgears utilise le rendu logiciel. En d'autres termes, votre carte graphique n'accélère pas les graphiques 3D.
Plus important encore que le nombre d'images par seconde, est la non-variation de ce nombre pour les petites et les grandes fenêtres. Si l'accélération matérielle fonctionne, le nombre d'images par seconde pour glxgears devrait être pratiquement indépendant de la taille de fenêtre. Si ce n'est pas le cas, alors vous ne bénéficiez d'aucune accélération matérielle.
KEGS, de Kent
Dickey <
kentd CHEZ cup POINT hp POINT
com>
, est un émulateur Apple II qui a été écrit à l'origine
pour HP-UX, mais amélioré et taillé pour Linux. Il tourne sous X
pour n'importe quel nombre de couleurs, et supporte des tailles de
mémoire variables, les joysticks et le son.
KEGS amorce toutes les variantes de
Apple II, et prend en charge tous les modes graphiques des Apple
][. Je n'arrive pas à trouver de page d'accueil pour cette
application.
apple2 basé sur SVGAlib et
xapple2 utilisant X peuvent émuler
n'importe quelle variante de Apple ][ sauf le //gs. L'interface est
assez originale, mais utilisable. La configuration est aussi un peu
étrange ; cet émulateur bénéficierait d'un outil de
configuration basé sur SVGA ou X. Il supporte la partie non
documentée du jeux d'instructions 6502 sur laquelle se basent
certains jeux. apple2 est actuellement
maintenu par Michael
Deutschmann <
michael CHEZ talamasca
POINT ocis POINT net>
et semble être développé à une allure
lente mais constante. Je ne pense pas que cette application ait une
page d'accueil.
dosemu est l'émulateur DOS canonique sous Linux. Quand vous pensez à DOS, ne pensez pas à des choses comme PROCOM PLUS OU D'AUTRES PROGRA~1 QUI ONT DES NOMS COURTS ET QUI SONT TOUS EN MAJUSCULES. Quelques classiques ont été écrits pour DOS comme Carmageddon™, Redneck Rampage™ et Tomb Raider™. dosemu peut les faire tourner. Malheureusement, il peut être malaisé de le faire fonctionner et, depuis janvier 2002, le code audio est quelque peu défectueux. Pas un gros problème si vous essayez d'exécuter Wordperfect™ ou une vieille application de base de données, mais ça empêche de jouer en pratique. Parvenir à faire fonctionner correctement dosemu n'est pas facile, mais c'est malheureusement le mieux qu'on puisse faire pour les jeux DOS. Bonne chance. Si vous utilisez avec succès dosemu, prévenez-moi.
wine, qui porte l'acronyme GNUide de Wine Is Not An Emulator (Wine n'est pas un émulateur) est une implémentation non commerciale de l'API Win32. La raison pour laquelle ce n'est pas un émulateur est subtile et pas du plus grand intérêt pour la plupart des non-informaticiens, et nous parlerons donc d'émulateur ici (il s'agit en fait d'une traduction au moment de l'exécution des appels de l'API Win32 en appels POSIX/X11). wine a beaucoup évolué, et est capable d'émuler beaucoup de jeux importants, ce qui est une bonne nouvelle pour les utilisateurs Linux intéressés.
wine ne fournit pas
d'API DOS, et vous ne pouvez donc pas
l'utiliser pour exécuter des applications DOS. Pour cela, vous
devriez jeter un œil à dosemu.
wine n'a jamais très bien implémenté
DirectX, bien que quelques jeux fonctionnent sous
wine. Pour les jeux, vous devriez vous
tourner vers winex.
En plus de la traduction au moment de l'exécution de l'API Win32 vers POSIX/X11 (il exécute des applications Windows sous Linux), wine effectue également une traduction au moment de la compilation de l'API Win32 vers POSIX/X11 (il compile le code source d'une application Windows sous Linux). Vu sous cet angle, wine est un utilitaire de portage Windows-vers-Linux. L'architecture x86 n'est pas requise, mais est recommandée car elle permet une exécution binaire x86 réelle ainsi qu'une utilisation directe des DLL.
Vous pouvez utiliser wine
« avec Windows », ce qui signifie qu'il
utilise des bibliothèques qui proviennent en réalité de Microsoft
Windows lui-même. Cela n'est légal que si vous possédez une copie
de Windows qui n'est pas actuellement utilisée sur un ordinateur.
On dit que wine fonctionne le mieux
quand il est exécuté avec Windows. Vous pouvez également utiliser
wine sans Windows. Les gens de winehq écrivent leur propre jeu
de bibliothèques appelé libwine
qui implémente
l'API Win32 sans aucun code provenant de Microsoft.
wine était à l'origine placé sous licence MIT/X11, et pouvait donc être utilisé à la fois à des fins commerciales et non commerciales. À la mi-2002, des parties de wine sont passées à la LGPL afin de ne plus pouvoir être utilisées à des fins commerciales. Cela pose un problème à des sociétés comme Transgaming (la section intitulée « winex ») et a ouvert la voie à un nouveau projet issu de wine appelé ReWind.
rewind a été démarré par Éric Pouech (un développeur de wine) et Ove Kåven (un développeur de winex) en réponse au changement de licence de wine. Il a vu le jour comme un instantané de la dernière version de wine complètement placée sous la licence MIT/X11. Le but est que rewind demeure sous licence MIT/X11 afin que des sociétés comme Transgaming puissent offrir des produits dérivés de wine.
winex est publié par une société appelée Transgaming. Ses développeurs utilisent wine et y ajoutent le support DirectX/DirectDraw. Bien que winex soit commercial, leur modèle économique est intéressant.
L'utilisateur final (vous) peut télécharger le code source gratuitement. Néanmoins, pour 5 $ US par mois, vous pouvez devenir un abonné de Transgaming, ce qui procure trois avantages principaux :
Les abonnés peuvent à tout moment télécharger des
versions empaquetées de winex dans le
format deb
, rpm
ou tar.gz
(y compris les mises à jour).
Elles sont également plus fonctionnelles que le source
publiquement disponible : celui-ci est une version
antérieure qui ne dispose pas de certaines des fonctionnalités
les plus récentes, comme la prise en charge des programmes
protégés contre la copie.
Les utilisateurs abonnés peuvent indiquer lors de sondages mensuels quels sont les points qu'il faut améliorer en priorité dans winex. Par exemple, ils peuvent voter pour des choses comme « Améliorer la prise en charge des programmes protégés contre la copie », « Meilleur support d'Installshield » ou « Améliorer la prise en charge de DirectX 8.0 ». Il me semble que les développeurs écoutent réellement les sondages.
Le site web de Transgaming comporte quelques forums d'assistance aux utilisateurs. D'un côté, ils utilisent le format le plus affreux, horrible, confus, dispendieux et idiot qu'il m'ait été donné de voir, et j'espère bien ne plus jamais revoir de forum ayant un format aussi mauvais que celui de Transgaming. D'un autre côté, vous pouvez demander de l'aide et les développeurs sont très bons pour trouver une réponse à votre question ; leur vigilance est assez impressionnante. Les non abonnés peuvent parcourir les forums, mais seuls les abonnés peuvent y écrire (et, par conséquent, y demander de l'aide).
Les développeurs de winex avaient l'intention de publier périodiquement leurs améliorations à Installshield, DirectX et DirectDraw dans wine. En contrepartie, au fur et à mesure de la maturation de wine, les développeurs de winex auraient pris les nouvelles versions de wine pour les utiliser dans winex. Néanmoins, depuis la naissance de Transgaming, des parties de wine sont passées à la licence plus restrictive GNU LGPL. Cela signifie en gros que les versions de wine publiées après la date du changement de licence ne peuvent plus être utilisées par winex. Par conséquent, winex sera à présent basé sur rewind.
Win4Lin est un produit commercial de Netraverse. Comme vmware, il utilise l'approche de la machine virtuelle pour exécuter des applications Windows, et affiche donc une grande fenêtre depuis laquelle vous pouvez démarrer Windows et exécuter toutes sortes d'applications Windows. À la différence de vmware, Win4Lin ne prend en charge que Windows 95/98/ME, mais cela s'avère être mieux pour les joueurs. Puisque Win4Lin se concentre sur ces systèmes d'exploitation, on dit qu'il est plus rapide et exécute mieux les jeux sous ces systèmes d'exploitation que vmware. Il est également bien moins cher que ce dernier. Win4Lin, dont la version la plus récente au 30 juin 2003 est la 5.0, souffre néanmoins de certaines limitations :
Il ne prend pas en charge DirectX ou DirectDraw, alors que vmware a un support « limité » pour DirectX.
Il ne prend en charge que les périphériques série et parallèle. C'est important pour ceux qui utilisent des joysticks USB. Notez que vmware peut gérer jusqu'à 2 périphériques USB.
Au 30 juin 2003, comptez 89.99 $ sans documentation imprimée et 99.99 $ avec. De plus, il n'y a pas de copie d'évaluation disponible, bien qu'il y ait une garantie de remboursement sous 30 jours. Néanmoins, puisque c'est commercial, vous avez le support technique. vmware est beaucoup plus cher.
Comme pour vmware, vous devez posséder une copie autorisée de Win95 ou Win98. Win4Lin ne peut utiliser une installation existante de Windows à la manière de wine.
Il ne tourne que sur les architectures x86.
VMWare est une machine virtuelle qui peut exécuter plusieurs systèmes d'exploitation simultanément sur un PC standard : les systèmes d'exploitation pris en charge comprennent ceux de Microsoft, Linux, Novell Netware et FreeBSD. Vous pouvez entre autres l'utiliser pour exécuter un système d'exploitation MS Windows et y lancer votre jeu favori. Vous pouvez même faire tourner Linux sous Linux ; utile par exemple si vous voulez tester une autre distribution. Stupéfiant ! Mais il y a des mauvais côtés. Vous devriez assurément disposer d'une bonne configuration pour l'utiliser ; le minimum annoncé est un CPU x86 500 Mhz avec 128 Mo de RAM, mais un processeur plus rapide avec au moins 256 Mo de RAM semble le minimum absolu si vous désirez des performances raisonnables. Toutes les distributions Linux ne sont pas prises en charge : les dernières RedHat, Mandrake et Suse le sont, mais c'est pas de chance si vous avez une autre version et/ou distribution (comme Debian). De plus, la prise en charge par vmware de DirectX est limitée, et vous pourriez ne pas pouvoir jouer à des jeux récents.
Voyez http://www.vmware.com pour plus d'informations. Ce n'est pas bon marché (environ 300 $ pour la version Workstation), mais vous pouvez obtenir une version d'évaluation limitée à 30 jours.
En premier lieu, vous devriez essayer un émulateur. Bien que certains jeux fonctionnent sous wine, vous aurez probablement le plus de succès avec winex : sa prise en charge de DirectX s'améliore constamment. Dans la version 3.1, la prise en charge de DirectX 8 est quasiment achevée, mais ce n'est pas forcément le cas des versions plus anciennes de DirectX (et donc des jeux plus anciens).
Vous pourriez également essayer une machine virtuelle comme Win4Lin ou VMWare au lieu d'un émulateur. Si votre but est d'exécuter des applications Win95/98/ME sous Linux, sans USB et sur l'architecture x86, le coût et le centrage sur les systèmes d'exploitation de type Win95 de Win4Lin en font un meilleur choix que vmware. Néanmoins, si vous devez avoir la prise en charge de l'USB ou exécuter Linux sur une plate-forme autre que x86, vmware est votre seule possibilité.
Maintenant, si votre but est d'exécuter des jeux pour des systèmes d'exploitation de type Win95 sous Linux, Win4Lin semble presque toujours meilleur que vmware. Le plus gros problème est que vmware a un support limité de DirectX alors que Win4Lin n'en a aucun. Ce fait seul rend tant Win4Lin que vmware inutilisables pour la plupart des jeux un tant soit peu évolués. Mais si vous voulez essayer, vous aurez probablement plus de succès avec vmware.
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.
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.
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.
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™.
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 :
Les jeux en eux-mêmes.
Actualités sur les jeux Linux.
Méta-site web sur les jeux Linux pour les germanophones.
Une base de données de tous les jeux vidéo informatiques connus. C'est un site très complet et un des mes favoris.
ebgames ne vend plus de logiciels Linux. Ils ont cessé de vendre des jeux et des distributions Linux à peu près au même moment où Loki Software a fait aveu de faillite, ce qui est une honte car ils avaient les plus bas prix sur les jeux Linux qu'il m'ait été donné de voir. Néanmoins, de temps en temps, ils proposent des choses comme Code Warrior ou Red Hat Linux.
Votre magasin pour l'achat de jeux Linux commerciaux (les vendeurs de logiciel comme Tribsoft et Loki ont aussi des magasins en ligne sur leurs sites web).
En tant que société qui a apporté CTP™ et Quake3™ sous Linux, Loki était le père du jeu sous Linux. Ils étaient des pionniers et avaient, de loin, le plus de titres (je les ai tous). Loki a porté des jeux sous Linux, principalement en utilisant la bibliothèque SDL. La mort de Loki en janvier 2002 était le plus grand revers subi par Linux dans sa tentative de conquête du marché domestique. Linuxgames.com propose un bel historique de Loki sur http://www.linuxgames.com/articles/lokitimeline/
Tribsoft a publié Jagged Alliance 2™, un excellent jeu de rôle/stratégie qui a réclamé plus de 2 semaines de ma vie. Ils devaient publier Europai Universalis™, Majesty™ et Unfinished Business™. Néanmoins, en date du 3 janvier 2001, Mathieu Pinard de Tribsoft a dit qu'il faisait une pause et que Tribsoft ne publierait plus de jeux pour le moment. Il continuera toujours l'assistance pour JA2™ mais ne vous attendez pas à des correctifs ou à des mises à jour.
MP Entertainment a publié Hopkins FBI™, mon jeu préféré jamais publié pour Linux. Plus violent que Quake™. Plus de nudité que Hustler. Plus de mauvais goût que Liberace. C'est une bande dessinée sur votre moniteur. Il était prévu qu'ils publient Hopkins FBI II™ et quelques autres titres, mais les annonces datent déjà de quelques années sans aucun signe d'arrivée prochaine du jeu. Ils ont ignoré toutes mes demandes d'informations, et j'en ai donc conclu que MP Entertainment est dans la même situation que Tribsoft. Vous pouvez toujours acheter ou télécharger une démo de Hopkins FBI™ depuis leur site web. Si quelqu'un a plus d'informations sur cette société ou sur l'auteur de Hopkins FBI™, veuillez me contacter.
Ils proposent Reel Deal Slots™, qui est très bien fait ! Je ne suis pas trop amateur de jeux de cartes ou d'argent, mais ce jeu est impressionnant ! Étant donné que leur seul spécialiste Linux a quitté la société, Reel Deal Slots™ est leur seule, et à ce jour dernière, publication pour Linux.
Linux Publishing ne vend pas directement au public, mais fournit des services professionnels de publication de jeux aux éditeurs de jeux. Je pense que cela signifie la réplication de disques, l'emballage et la vente aux détaillants.
Page d'accueil de XFree86.
C'est le site web de référence pour qui veut programmer des jeux sous Linux. C'est une montagne d'informations contenant des articles bien écrits sur tous les aspects de la programmation de jeux (pas nécessairement spécifiques à Linux), des liens vers d'importantes ressources relatives à la programmation de jeux, des interviews, tests, sondages et des tas d'autres trucs. Il est difficile d'imaginer un meilleur site web sur le sujet.
Malgré le fait sidérant qu'elle ne mentionne nulle part ce présent guide comme une ressource dans leur texte, je considère la FAQ comme un bon complément à ce guide. J'ai essayé de ne garder que le strict minimum d'informations spécifiques à des jeux particuliers dans ce guide. La FAQ prend l'approche opposée : elle se concentre principalement sur les jeux eux-mêmes, y compris des problèmes spécifiques à certains jeux et l'endroit où les obtenir. La FAQ et le guide sont complémentaires à cet égard, et j'ai essayé de ne pas reproduire leur contenu. Même si les auteurs sont un peu hargneux, leur effort est à souligner. Si vous voulez une source d'informations globale pour des questions spécifiques à certains jeux, la FAQ est un excellent point de départ. De plus, elle donne des informations sur un assez grand nombre de jeux Linux.
Ce guide intéressera principalement les musiciens qui utilisent des cartes professionnelles ou semi-professionnelles pour l'enregistrement et la création de musique sur un ordinateur. Les informations sont très détaillées, peut-être même trop pour les joueurs.