Le 30 novembre 1997, id Software sortait son nouveau FPS, « Quake 2 », qui succédait à son succès de l’année précédente, Quake. Le moteur de Quake 2 était une version lourdement modifiée du premier Quake : possibilité de ramper, source de lumière colorée, eau transparente entre autres. Surtout, c’est le premier jeu d’id Software sortant directement pour MS-Windows. Même si Hexen II de Raven Software proposait une partie des nouveautés.
Pour la petite histoire, quand id Software a renommé ses moteurs en 2007, id tech 2 regroupa sous son nom les deux premiers Quake sous son appellation. Les moteurs id tech 1 s’occupant de Doom et Doom 2, id tech 3 étant celui de Quake 3 Arena, id tech 4 celui de Doom 3 et Quake 4. Fermons cette parenthèse technique 🙂
Après un monde inspiré des oeuvres de HP Lovecraft, on se retrouve dans un scénario plus typique de la science fiction classique. La Terre a été attaqué par une race extra-terrestre, les Strogg. Les armées terrienne pour se défendre décide d’attaquer la planète des Strogg dans une mission dénommé Alien Overlord.
Bien entendu, l’opération est éventée, et vous vous retrouvez seul à devoir attaquer la capitale ennemie. Bon courage 🙂
Une des nouveauté du jeu à l’époque était de supporter deux types de rendu : le logiciel et l’accélération matérielle. En gros, soit l’ordinateur s’occupait tout seul de l’affichage, soit il délaissait la main à une carte accelératrice qui le soulageait avec de plus beaux graphismes. À l’époque, c’était les 3Dfx qui tenaient le haut de gamme.
Quand Quake 2 est sorti, le MS-Windows le plus avancé était la version dite OSR 2.5 de MS-Windows 95. J’aurais bien voulu lancer la démo du jeu avec l’OS disponible en 1997, mais l’installation de cette antique version de MS-Windows se plantait tout le temps.
J’ai donc décidé de me replier sur un MS-Windows 2000, après avoir bataillé comme un beau diable pour faire fonctionner MS-Windows 98 avec plus de 16 couleurs, en vain. Dommage pour l’homogénéité de l’ensemble. Quoiqu’il fallait avoir du courage pour jouer sous MS-Windows à l’époque 🙂
Après la libération du code source en décembre 2001 de Quake 2, le code a été dépoussiéré et adopté pour de nombreuses plateformes, avec des ports sur des machines comme l’Amiga !
Sous Linux, il existe le port Yamagi Quake qui permet de jouer – tant qu’on a une version légale des niveaux et graphismes – avec Quake 2 et ses deux extensions. Vous avez pu voir comment quelques textures en haute définition, un gamma modifié et l’ajout des ombres transcendent le jeu, non ? 😀
Même si le résultat n’était pas époustouflant, la durée de vie compensait largement. Quand le jeu est sorti, le haut de gamme était monopolisé par les premiers Pentium 2 de la série Klamath, avec une vitesse ébouriffante allant de 233 à 300 Mhz. Souvenirs, souvenirs 🙂
VirtualBox ne prend pas les Win9x en charge pour les pilotes vidéo (il reste en 16 couleurs). Le plus ancien Windows pris en charge est effectivement Windows 2000.
Pourtant, il y a un moyen de le forcer à afficher autre chose que du 640 × 480 × 16 en installant manuellement un pilote dit « universel » (la marche à suivre est indiquée ici : https://forums.virtualbox.org/viewtopic.php?t=9918, et je crois avoir moi-même pris ceux de VBEMP 9x Project : http://bearwindows.zcm.com.au/vbe9x.htm).
En gros, ce sont des fichiers Zip à décompresser depuis l’hôte et, en se débrouillant pour les faire lire par l’OS virtualisé (je crois que j’avais créé une ISO pour la monter dedans), j’ai fait installer par le Windows virtualisé le fichier INF correspondant au modèle (doit correspondre au nombre de Mo alloués à la CG virtuelle : 32, 64 ou 128 Mo). Et zou ! À nous les définitions supérieures et les couleurs sur 32 bits sur Win9x dans VirtualBox ! J’ai testé : ça marche aussi bien sur du Windows 95 OSR 2 que du Windows 98 Deuxième Édition.
À garder pour une éventuelle prochaine occasion.
Le problème est que mon exemplaire de 95OSR2 refusait de complètement s’installer. Merci pour le tuyau néanmoins.
Je réagissais surtout à propos de ce passage : « J’ai donc décidé de me replier sur un MS-Windows 2000, après avoir bataillé comme un beau diable pour faire fonctionner MS-Windows 98 avec plus de 16 couleurs, en vain. »
Je m’en doutais un peu. C’est vrai qu’émuler MS-Windows 9x tient parfois du parcours du combattant 🙁
A l’époque, je jouais à Quake 2 en Lan avec mon bi Pentium 2 266 + 2 cartes 3DFx 2… et tout ça sous Linux, les tout débuts de la 3D accélérée pour notre OS préféré. Souvenirs, souvenirs 🙂
J’avais même pondu cet article de tests/vulgarisation 3 ans après, alors que je suivais de très près le développement de Utah-GLX avec un certain John Carmack aux manettes 🙂
http://www.linux-france.org/article/3d/
En relisant la première page de l’article, je me rappelle le délire que c’était à l’époque avec la librairie (proprio) glide pour Linux.
Avec les Voodoo on ne pouvait faire que de la 3D plein écran (il fallait une carte 2D à part).
Et aussi la grosse bidouille qui permettait d’avoir une appli 3D en mode 2D, avec le framebuffer de la carte Voodoo recopié dans une fenêtre X11… Et crash si on tentait de lancer 2 applis 3D 😀
Allez, je copie colle le chapitre intéressant :
Petite histoire de la 3D accélérée sous Linux, les débuts entre 1995 et 2000. (article écrit en Novembre 2000, la vache, 15 ans déjà !)
Tout a commencé début 1995 avec la publication initiale de Mesa, une librairie 3D offrant la même API qu’OpenGL et permettant de recompiler sous Linux (et autres machines Unix), les applications 3D utilisant ces appels. Pas question d’accélération matérielle à l’époque, tout est calculé par le processeur.
La première carte accélératrice 3D abordable pour PC, la 3Dfx Voodoo 1 est sortie en 1996 et la librairie Glide pour Linux mi 1997. Il est enfin devenu possible de faire de la 3D accélérée sous Linux en utilisant les API Glide directement ou en utilisant les API OpenGL via Mesa utilisant lui même les API Glide pour accéder au matériel. La 3D rapide n’était possible qu’en plein écran (la Voodoo 1 étant une carte vidéo à part entière shuntant la carte 3D normale lors d’un affichage 3D). L’affichage dans une fenêtre était possible via une ruse : recopier la mémoire vidéo de la carte 3Dfx dans une fenetre sur l’écran X11 ! C’était beaucoup plus lent et dangereux car lancer 2 applis 3D entrainait un crash !
C’est à la même époque qu’a démarré le projet XFree86/Mesa GLX pour utiliser MesaGL sous X11 via le protocole GLX d’une façon bien plus standard, similaire à ce qui se fait sur station Silicon Graphics par exemple. Mais bien sur ici, pas d’accélération matérielle, l’architecture des cartes 3Dfx Voodoo 1 ne se prétant pas à cette utilisation.
La situation n’était pas idéale : librairie propriétaire, non open source, 3D rapide seulement en plein écran, utilisation dangereuse en mode fenêtré… Mais bon, c’était la seule possibilité donc tout le monde remerciait 3Dfx pour son support de Linux. Les choses n’ont pas beaucoup bougé en 1998 à part le support des toutes nouvelles cartes Voodoo2 (ma première carte 3D sous Linux d’ailleurs :-).
Fin 1998, les choses ont recommencé à bouger avec la sortie d’autres cartes 3D venant concurrencer sérieusement 3Dfx : NVidia TNT, Matrox G200, ATI Rage 64 et qui surtout étaient de VRAIES cartes 2D + 3D. Matrox ayant publié les spécification de sa carte G200, le projet Mesa GLX, rapidement renommé Utah-GLX, a pu redémarrer pour intégrer le support de l’accélération 3D dans X11 sous Linux.
Par la suite, les spécifications techniques ont été obtenues pour d’autres cartes. Nvidia a procédé différement en fournissant un code précompilé illisible permetant au développeurs du projet Utah-GLX d’intégrer un support préliminaire des cartes TNT et TNT2 mais ce code n’a jamais subi d’amélioration.
Parallèlement à cela, la future version du serveur X11 XFree86 4.0 était en développement. La publication en open source du code de GLX par Silicon Graphics a permis l’intégration du tout dans XFree86 4.0 au sein d’une architecture étudiée pour obtenir la meilleure intégration possible : la DRI (Direct Rendering Infrastructure).
Pour terminer, NVidia a publié début 2000 des drivers Linux hautement optimisés pour toutes ses cartes graphiques mais fournis seulement sous forme binaire. Bien que nécessitant XFree86 4, il n’utilisent pas la DRI mais une architecture propriétaire ! Ca nous fait donc 4 architectures différentes pour accéder aux cartes 3D ! Et encore, je passe sous silence les serveurs X11 commerciaux disponibles pour Linux… Heureusement que les API OpenGL et GLX fédèrent tout ça !
Je me souviens bien de la sortie du jeu, j’étais dans un service informatique et ils avaient téléchargé la démo… Et pourtant j’ai peu joué à ça. Un peu plus tard, j’ai eu Unreal puis Unreal Tournament et la claque était là. Il faut aussi dire que je n’avais pas de 3DFX, que ma pauvre carte S3 avait du mal… un peu moins ma Diamond Fire1000 ensuite . Mais que de souvenirs tout de même sur ces grands hits du FPS à l’heure où jouer en ligne n’était pas aussi facile.