Zeph (./7) :
Je viens de tester très rapidement, sympa
Curieux aussi de savoir pourquoi vous avez choisir de redévelopper un moteur (surtout que ça doit prendre un certain temps) plutôt que d'utiliser Id Tech 3 qui semble techniquement assez similaire (à moins que l'objectif n'ait été justement d'apprendre en codant votre propre moteur).
En fait Dæmon est un moteur id Tech 3 basé sur les moteurs de Quake 3 et de Wolfenstein: Ennemy Territory, avec un moteur OpenGL 3 est hérité d’XreaL, un fork d’idTech3 qui avait du succès à l’époque™ (Note: le moteur OpenGL 3 d’ioquake3 hérite beaucoup d’XreaL et parfois les mêmes développeurs ont bossé sur celui d’ioquake3 et le notre). id Tech 3 n’est pas un moteur, c’est une famille de moteurs.
Par rapport au moteur de Quake 3 original, les changements majeurs sont :
- Rendu OpenGL 3 (c’est à dire, pas le pipline legacy d’avant), fondamentalement les choses comme OpenGL 4.6 ne sont que des extensions par dessus OpenGL 3 (extensions qu’on peut activer si on en a besoin pour tel effet optionnel) alors que OpenGL 3 est conceptuellement différent d’OpenGL 1. On peut voir ça aussi sur certains moteurs idTech3 modernes (type ioquake3).
- Remplacement de la QVM historique (la machine virtuelle qui fait tourner le game code), qui… sentait bon les années 90, et qui requérait un compilateur C spécifique et non-libre. Actuellement on tourne sur NativeClient, un port vers WebAssembly (qui porte très mal son nom, le web n’est qu’un usage parmi d’autres) est en cours. Avec NaCl déjà, bah on utilisait un compilateur moderne (LLVM), avec la possibilité de faire du C++ avancé et de pouvoir réutiliser des librairies C/C++ existantes, sans être limité par le compilateur spécifique d’il y a plus de 20 ans (plus toutes les améliorations que l’industrie a apporté à ce genre de compilateur). Avec Wasm, il ne sera pas impossible de faire un jeu avec d’autres langages (Rust?) mais bon, pour être honnête, il y a déjà toute l’API en C/C++ donc ce serait se fatiguer pour pas grand chose.
- Beaucoup de réécriture en C++.
- La prise en charge de modèles animés à partir d’ossature, que l’on utilise (format IQM (privilégié) ou MD5mesh de Doom 3). Là encore certains moteurs idTech3 modernes type ioquake3 peuvent faire cela aussi, mais ça n’est pas utilisé dans les jeux historiques à cause de la compatibilité avec les moteurs historiques.
- La prise en charge de formats audio/vidéo plus modernes, tel vorbis/opus pour l’audio, et png/webp (ce dernier explose à la fois jpg pour la compression destructive et le png pour le sans perte), ainsi que les formats optimisés pour carte graphique tel que KTX/DDS ou CRN. Ces formats sont uploadés dans le GPU directement compressés, et ne sont pas décompressés par la carte graphique. Voir la section Sauter dans le futur de l’article sur le moteur. Les moteurs id Tech 3 implémentent généralement aussi le png mais bon… Pour Unvanquished, on fait du 100% CRN ou WebP.
- Des tas de fonctionnalités avancées : deluxe mapping (sorte de light map qui code la direction des lumières précalculées, c’est ce qui permet notamment aux lumières de se refléter entre une lampe et le joueur, avec le reflet qui s’adapte à la position du joueur), specular mapping et physical mapping (deux techniques différentes pour coder les effets de surface), normal mapping (pour simuler des effets de reflets/ombrages comme si la surface était en relief et non plane), relief mapping (pour effectivement imprimer un relief sur une surface plane), etc. Tous ces effets n’existaient pas dans id Tech 3 et sont rendus en une seule passe, et certains effets qui requéraient trois passes passes dans id Tech 3 ne requièrent plus qu’une seule passe, par exemple, appliquer une texture, l’éclairage précalculé et les additions (par exemples un écran qui reste toujours allumé et qui n’est pas affecté par les ombres) sont désormais rendus en une seule passe au lieu de trois. Certains moteurs comme ioquake3 implémentent plus ou moins ces fonctionnalités mais là encore c’est très peu utilisé donc peu éprouvé.
- Pour permettre certaines de ces nouvelles fonctionnalités, on a du étendre le format de description de matériaux (et pas de chance, certains défauts historiques d’id Tech 3 font que certaines textures ne sont pas rendues du tout si certaines fonctionnalités optionnelles ne sont pas comprises).
- On a amélioré le format de paquet PK3 afin de gérer les dépendances. Le format PK3 fait partie d’un système de fichier virtuel, c’est très pratique parce que tout fichier dans une archive différente appartient à une même arborescence unifiée. Ça permettait à id Software de mettre à jour ses jeux en ajoutant des fichiers dans des archives supplémentaires ou en en remplaçant (sans remplacer les archives). Ça a rendu le modding très facile, mais ce n’était pas conçu pour ça : n’importe quel fichier téléchargé depuis n’importe quel serveur pouvait remplacer (tel que vu par le jeu) des fichiers officiels ou des fichiers d’autres moddeurs/mappeurs par erreur. Avec notre changement, si un moddeur/mappeur fait une erreur, il n’affecte que ses fichiers (il est toujours possible de faire quelques mauvaises choses intentionnellement mais ça sera l’étape d’après). Dans tous les jeux id Tech 3, le problème de ces problèmes accidentels étaient une plaie. Tu joues sur un serveur, et ton menu est changé à tout jamais, ou tu as des textures manquantes. Pire, pour faire certaines choses, les moddeurs devaient remplacer des choses officielles (et donc casser les jeux des joueurs) alors qu’avec le format DPK (notre évolution), on peut intentionnellement remplacer des fichiers officiels sans casser les jeux des joueurs, car ces fichiers remplacés intentionnellement ne sont pas chargés par défaut ni par les autres serveurs.
- Notre interface utilisateur est décrite dans une variante de HTML/CSS plutôt qu’un système propre à quake 3 (ça c’est du côté du game code que c’est géré, mais c’est important aussi comme changement fondamental).
- Et plein d’autres choses que j’oublie.
Je t’invite franchement à lire l’
article dédié au moteur Dæmon qu’on a sorti à l’occasion de la 0.52 d’Unvanquished. Il répondra à beaucoup de tes questions.
Une question légitime pourrait être, pourquoi avoir amélioré idTech3 et ne pas être parti sur id Tech 4 (qui a aussi été libéré, utilisé par
The Dark Mod) ? La raison est qu’on a évolué depuis Tremulous qui a commencé comme un mod de Quake 3, et qui fut ensuite basé sur un dérivé d’ioquake3. Le jeu a toujours tourné sur un moteur idTech3 et dérivé, c’était vrai en 2006 avec Tremulous, c’est vrai en 2021 avec Dæmon. L’évolution se fait donc de manière incrémentale, en améliorant l’existant. Il existe aussi des milliers de cartes qui peuvent être portées avec un simple réempaquetage en DPK (et en suivant les nouvelles conventions) même en ayant perdu les sources de ces cartes. Pour revenir à id Tech 4, il y a même des régressions de fonctionnalité entre Quake 3 et Doom 3/Quake 4 (c’est expliqué dans l’article sur le moteur). Et franchement, l’éclairage d’un jeu comme Quake 4 est franchement moche, de bonnes lumières précalculées de qualité sont plus séduisantes qu’un éclairage entièrement dynamique mais laid. Et avec notre « tiled renderer » on n’a pas vraiment à se soucier des performances pour ajouter des dizaines et des dizaines de lumières dynamiques. Sur ces aspects, en terme de fonctionnalité et de qualité de rendu on a mieux que Quake 3 et Doom 3 / Quake 4 (si tant est que les artistes savent les exploiter, bien sûr, ce qui n’est pas plus compliqué dans notre cas). Je dis sur ces aspects parce que sur d'autres aspects Doom 3 fait certainement des choses que nous ne faisons pas (par exemple nous sommes pas un jeu solo donc certaines fonctionnalités associées ne sont pas autant développées).
Avant de passer à Unvanquished, Kangz et Amanieu étaient développeurs de TremFusion (un moteur alternatif mais compatible avec Tremulous, première tentative d’apporter un moteur amélioré basé sur XreaL), Ingar (mappeur) et Stannum (modelleur) étaient membres officiels de Tremulous, Supertanker, Viech et EmperorJack étaient des mappeurs emblématiques de la communauté de Tremulous (beaucoup de nos cartes officielles ont été commencée pour Tremulous), donc oui on fait du id Tech 3 de haut en bas.
À noter qu’id Tech 3 n’existe pas. C’est une appellation rétroactive des ayants droits originaux qui tente de faire coller rétroactivement une pratique actuelle de leurs concurrents, mais qui n’étaient pas mise en œuvre, et au contraire, la méthode était strictement opposée. L’appellation id Tech 3 s’intégre dans une catalogue
actuel entre id Tech 2 et id Tech 4. Et sans le dire de manière péjorative, c’est techniquement une forme de révisionnisme à but de communication et de travail de marque opéré à partir d’id Tech 5. Il n’y a pas de moteur id Tech 3 (ni de moteur id Tech 2 ni de moteur id Tech 4), il y a la famille des moteurs de l’époque de Quake 3 qu’on appelle rétroactivement id Tech 3. Chaque jeu avait son propre moteur, chaque jeu avait son propre fork du moteur incompatible. Le moteur n’était pas réutilisable, il n’était pas conçu pour cela, au contraire, le moteur était conçu pour ne pas être réutilisé tel quel mais instancié comme un « template » de jeu. Avant toute chose, la première chose qu’un développeur devait faire était de modifier le moteur livré pour qu’il ne soit plus le moteur d’un autre jeu.
Donc sur ce plan, nous sommes pleinement un jeu et un moteur id Tech 3, autant que Quake III Arena / Team Arena, Star Trek Voyager: Elite Force / Elite Force 2, Jedi Knight: Outcast / Academy, Return to Castle Wolfenstein, Wolfenstein: Ennemy Territory, Call of Duty (original) / United Offensive, Soldier of Fortune II: Double Helix, Medal of Honor : Allied Assault, Heavy Metal : F.A.K.K. 2, Resident Evil: Dead Aim, 007: Agent Under Fire, 007: Everything or Nothing, Dark Salvation, Iron Grip: Warlord… Tous ces jeux utilisent un moteur dérivé d’id Tech 3 mais qui sont des moteurs incompatibles, exactement comme nous : le moteur de Quake 3, le moteur d’Elite Force, le moteur de Call of Duty… Certains ont vécu plus longtemps que d’autres, en devenant toujours plus éloigné… Nous restons toujours très proches du moteur de Quake 3 cependant, en fait on peut toujours charger des archives PK3, des modèles MD3, les matériaux (.shader) de Quake 3, les BSP (map) de Quake 3… sans les modifier, mais par contre, plus de QVM obsolète ni de limitation au langage C des années 90, et plein de choses en plus.
En fait avec Dæmon on fait quelque chose qu’id Software n’a jamais fait avec « id Tech 3 » : on met sur le marché (même si gratuit) un moteur en tant que produit à part entière, pensé comme un produit, et présenté comme un produit. id Software n’a jamais fait ça avec id Tech 3, et en fait ils ne le font pas vraiment non-plus avec leur dernières itérations, quand bien même ils utilisent ce discours id Tech 3 / 4 / 5 / 6 pour donner l’apparence de faire comme Epic avec Unreal Engine ou encore Unity et Unigine, mais ces efforts de communication ne se traduisent pas sur le marché, ça simplifie simplement la communication (et la communication tierce-partie) en utilisant des éléments de langages actuels qui peuvent être ainsi réutilisés par les communicants, journalistes, testeurs, revieweurs, streamers, etc. En réalité id Tech 1, 2, 3, 4, 5, 6… ne désigne pas des moteurs mais des générations de moteurs (comme les générations de console).
À ce sujet j’ai
donné une conférence pour Debian,
traduite ici. id Tech 3 n’existe pas en tant que moteur. Dæmon fait partie de la famille des moteurs id Tech 3 comme il y en a probablement une vingtaine.
Bref, à un moment il est légitime de vouloir mieux que ce qui formait l’état de l’art en 1999. Et contrairement à des projets comme ioquake3, on peut se permettre de corriger des défauts ou limitations de conception, ce qui casse la compatibilité.