Annonce du moteur de jeu Dæmon 0.52 Beta

Le moteur Dæmon est un moteur de jeu taillé pour des jeux rythmés en arène.

Nous avons fusionné notre branche 0.52 et étiqueté la version 0.52. Unvanquished 0.52 Beta est sorti le vendredi 14 mai. Le compte à rebours est lancé ! Tandis que nous sommes en train d’empaqueter le jeu et sommes en train de contacter les propriétaires de serveur pour mettre à jour leurs serveurs afin d’être prêts pour ce jour, nous annonçons le moteur Dæmon.

L’historique d’Unvanquished et du moteur Dæmon.

Le moteur Dæmon est un moteur brut, le composant logiciel exécutant le code du jeu dans une machine virtuelle et opérant le rendu du jeu tout en gérant les entrées et le réseau. C’est un composant d’un écosystème libre et ouvert mais pas une plate-forme d’édition intégrée comme Godot.

Note de l’auteur — Ceci est une traduction de l’annonce du 10 mai que j’ai écrite pour le site d’Unvanquished. Cet article est sous licence CC 0 1.0.

Sommaire

• Présentons le moteur Dæmon
• Prise en charge du matériel et des systèmes
• Corriger et améliorer le moteur de rendu
• Sauter dans le futur
• Corriger les défauts de conception des matériaux
• Une vue sur l’écosystème du moteur Dæmon
• Comment réduire les coûts
• Pour les jours à venir

Présentons le moteur Dæmon

Initialement basé sur le moteur id Tech 3 de par sa lignée avec Tremulous, et héritant d’améliorations provenant à la fois de Wolfenstein: Enemy Territory et du moteur XreaL, le moteur Dæmon a évolué pour prendre en charge des techniques modernes comme le rendu de lumière dynamique tuilé (dynamic light tiled rendering), les animations de modèle segmenté dont le format MD5Mesh de Doom 3 et le format Inter Quake Model (IQM), le multitexturage de surface dont le deluxe mapping, normal et relief mapping, le bon vieux modèle d’éclairage Phong et (nouveau !) les matériaux PBR, tout en conservant la technique éprouvée du BSP pour rendre l’environnement. Des effets spéciaux comme le flou lumineux (bloom), l’éclairage de bord (rim lighting), flou de bougé (motion blur), brouillage de chaleur (heat haze), l’étalonnage de couleur (color grading) sont pris en charge.

Vous pouvez avoir remarqué une certaine mode pour des mécanismes de moteur de jeu classique sur le marché, même des jeux commerciaux comme Ion Fury basé sur Eduke32 (dérivé du moteur Build, lignée Duke Nukem) ou Wrath: Aeon of Ruin basé sur DarkPlaces (lignée Quake), tous deux étant des moteurs libres comme Dæmon.

Donc si vous êtes à la recherche d’un moteur de jeu avec des techniques modernes de rendues et d’animation de modèle tout en conservant une expérience classique de jeu, le moteur Dæmon est pour vous ! Sans être aussi vieille école que quelque chose basé sur Eduke32 ou le classique Doom avec des personnages à base de sprite (quoique, vous pouvez faire des jeux avec des sensations similaires), le moteur Dæmon se positionne plutôt dans cette famille de jeux comme Unreal, Quake ou Doom 3 avec des environnements grossièrement réalistes mais avec un gameplay nerveux et pas de message « vous quittez la zone de combat ».

Le moteur Dæmon vit comme un projet libre en tant que tel, avec le développement actuellement hébergé sur GitHub. Si vous désirez baser votre jeu sur ce moteur, vous êtes les bienvenus, c’est fait pour !

XreaL puis le moteur Daemon ont toujours été un lieu idéal pour des expérimentations. Si vous recherchez un moteur ouvert pour implémenter telle ou telle nouvelle technique de rendu ou cherchez un jeu ouvert pour essayer des trucs d’IA avancés pour les bots ou n’importe quoi de sympathique, hé, peut-être avez-vous trouvé le projet dont vous avez besoin !

Prise en charge du matériel et des systèmes

La table de compatibilité de carte graphique d’Unvanquished.

Le moteur Dæmon et le jeu Unvanquished en particulier sont testés sur une gamme large de configuration matérielle et logicielle (voir la table de compatibilité de carte graphique d’Unvanquished, pour cette version 0.52 nous avons testé plus de 60 carte graphiques et environ 80 configurations !

Unvanquished en lui-même requiert des cartes à partir d’OpenGL 3. Le moteur de jeu est capable de tourner correctement sur des cartes graphiques à partir d’OpenGL 2.1, dont des cartes AGP datant de juillet 2002, oui nous avons validé des cartes PCI Express, AGP, et même PCI.

Nous avons amélioré un contournement spécial pour un pilote Nvidia buggué. Dans le passé certaines personnes ont rapporté des problèmes avec du matériel Nvidia. Nous avons conduit plus de tests et il apparaît que le bug se produit avec les cartes graphiques Nvidia à base de GT218 faisant tourner le pilote 340. Le pilote 340 est le dernier pilote pour cette gamme de carte graphique et puisque le pilote Nvidia est propriétaire, personne ne le corrigera jamais. Ce pilote défectueux rapporte par erreur qu’il prend en charge une fonctionnalité qu’il ne prend pas en charge, donc pour activer ou désactiver cette fonctionnalité le jeu ne peut pas croire ce que dit le pilote et l’on doit jouer aux devinettes pour détecter le pilote défectueux à la place, donc nous désactivons la fonctionnalité utilisée par cette optimisation quand ce pilote est détecté.

Nous avons beaucoup travaillé pour désactiver le code inutilisé lorsque des fonctionnalités sont désactivées. Par exemple nous nous sommes assurés que les cartes normales (normal map) ne soient pas chargées et que le code de normal mapping des shaders GLSL ne soit pas compilé quand le normal mapping est désactivé. Faire ça n’a pas seulement aidé à améliorer le temps de compilation des shaders et l’utilisation de mémoire graphique sur les systèmes moins performants, cela a aussi permis à certains vieux systèmes de fonctionner tout simplement. Nous avons découvert que le code GLSL du moteur de rendu tuilé (tiled renderer) faisait des choses trop complexes pour la petite ALU (Unité arithmétique et logique) de certains anciens processeurs graphiques, cassant le rendu. Parce que de toute façon ce genre de matériel est trop vieux pour soutenir des lumières dynamiques et que cette fonctionnalité serait désactivée par l’utilisateur, s’assurer que ce code GLSL n’est pas compilé quand cette fonctionnalité est désactivée a simplement rendu ces cartes utilisables. Et c’est ainsi que la Radeon 9700 Pro de juillet 2002 fonctionne avec le moteur : ~40fps si vous ignorez le cas spécifique des modèles d’Unvanquished.

Si le but premier du moteur Dæmon n’est pas d’être un moteur rétro pour tourner sur du matériel obsolète mais d’implémenter des techniques modernes comme le rendu tuilé, le relief mapping ou le PBR (voir ci-après), nous ne laissons pas derrière les joueurs avec du matériel lent.

Comme déclaré, le moteur Dæmon prend en charge OpenGL 2.1 mais Unvanquished requiert OpenGL 3. La raison est que nous utilisons des modèles animés avec trop de segments pour qu’ils soient accélérés sur du matériel pré OpenGL 3. Si vous planifiez de faire un jeu avec le moteur Dæmon, vous savez que vous pouvez aller en arrière jusqu’à des cartes graphiques ayant 18 ans en conservant le jeu jouable en utilisant simplement des modèles plus simples (jusqu’à 41 segments).

Bien entendu les processeurs graphiques modernes sont la meilleure manière d’apprécier le moteur Dæmon, par exemple nous avons testé les modèles GCN et RDNA avec le même soin.

Par exemple l’AMD R9 390X de 2015 supporte la préconfiguration ultra avec une résolution 4K à 144Hz. L’AMD R7 Embedded des APU R series peut supporter une résolution 2K avec la préconfiguration medium aussi bien que l’Intel UHD.

Nous n’avons pas seulement vérifié que ça fonctionnait, nous avons corrigé les bugs associés de manière à ce que ça marche sur cette gamme large de matériel, parfois même en contournant les pilotes défectueux d’Nvidia que nous ne pouvons corriger nous-mêmes. Cela fait peut-être du moteur Dæmon le moteur open source dérivé d’id Tech le plus testé sur ce sujet, autant que nous puissions le savoir.

Faire ces tests a aussi révélé une pile de problèmes avec le code PCI du noyau Linux affectant à la fois les cartes graphiques PCI, AGP et PCI Express, cela rappelle combien ce genre de test est précieux, pas seulement pour le jeu vidéo.

Le moteur Dæmon compile et tourne sur Linux, Windows, et macOS. Nous fournissons des outils (comme un fichier Docker) pour produire des binaires portables et distribuables (releasable). Vous n’aurez besoin que de taper une seule commande sur un hôte compatible Docker et une autre sur un hôte macOS pour obtenir des binaires du moteur pour Linux, Windows et macOS, et le code du jeu multiplate-forme lui-même.

Nous produisons les versions d’Unvanquished sur Debian Buster et le binaire Linux produit devrait tourner sur les distributions à partir de l’époque d’Ubuntu Bionic (2018, nous avons fait des efforts spécifiques en ce sens), et le moteur est toujours compilable sur Ubuntu Xenial (2016), notre système d’intégration continue le vérifie pour nous et nous avons vérifié que de tels binaires étaient jouables.

Donc, comme vous pouvez le voir, nous faisons des efforts spéciaux pour conserver une compatibilité large avec notre moteur. Cependant, pour ne pas distribuer des binaires obsolètes à l’utilisateur moyen, si vous avez vraiment besoin de jouer à Unvanquished sur une distribution âgée de 5 ans, vous devrez compiler le moteur vous-même. Pour cela, se référer au dépôt du moteur Dæmon.

Corriger et améliorer le moteur de rendu

Entre la version 0.51 et la version 0.52, une liste impressionnante de bugs et de défauts de conception ont été corrigés.

Un impressionnant correctif « petit changement, immense effet » fut une unique erreur d’arrondi qui fut la cause de plein de bugs. La ligne en question fut introduite dans XreaL en 2005 et a probablement commencé à faire crépiter les bugs en 2008 quand une autre partie du code fut modifiée…

Ceci n’est pas le seul bug qui vient du Moyen Âge… Un autre patch a corrigé un bug introduit dans XreaL en 2006, et cette fois c’est certain, le bug n’était pas en dormance à l’époque. Ce bug est même plus vieux que Tremulous 1.1 (mais Tremulous n’était pas affecté car basé sur ioquake3 au lieu de XreaL)… Ce bug a été corrigé 14 ans plus tard, jour pour jour.

Le moteur Dæmon implémente un cache de shader GLSL depuis très longtemps pour économiser du temps de chargement, mais pour la version 0.52 nous avons corrigé des bugs qui empêchaient le cache d’être invalidé proprement dans certaines situations. Cela a corrigé une gamme de mystérieux bugs « ça n’est arrivé qu’une seule fois ».

Unvanquished 0.52 introduit des preréglages (presets) graphiques et une fonctionnalité utilisé par ces préréglages est que le moteur rend possible de viser une taille maximum de texture spécifique, au lieu de se reposer sur la fonctionnalité historique PicMip. La fonctionnalité PicMip était problématique parce que si vous aviez une texture de 64×64 à côté d’une texture de 4096×4096, l’option r_picmip 1 les transformeraient en 32×32 et 2048×2048, l’une étant inutilement petite et l’autre toujours immense. En mettant l’option r_imageMaxDimension à 512, l’image 64×64 ne sera pas modifiée, tandis que celle 4096×4096 est transformée en une texture 512×512. Les artistes peuvent utiliser un mot-clé spécial de matériau imageMinDimension pour empêcher le moteur de réduire la résolution d’une texture en dessous d’une certaine taille quand cette texture est connue pour souffrir de la réduction. C’est pertinent quand c’est utilisé sur des textures avec des écritures dessus, ou des grillages…

Une énorme refonte du code du moteur de rendu fut réalisé, plus de 700 lignes de code furent supprimées… et le moteur fait plus de choses à la fin ! Toutes les fonctionnalités similaires utilisent désormais le même code au lieu de variantes légèrement différentes évoluant depuis des copier-coller âgés de décennies.

Le format de matériaux rend désormais super facile d’ajuster les paramètres de matériaux comme l’orientation de carte normale : ajoute simplement la ligne normalFormat X Y Z et indique au moteur de rendu que la carte normale utilise la convention OpenGL, ou bien ajoute la ligne normalFormat X -Y Z et indique au moteur de rendu que la carte normale utilise la convention DirectX. Pour des raisons historiques, sans mot clé explicite, le moteur suppose la convention de carte normale DirectX en lisant les matériaux Quake 3 parce que XreaL (le moteur que nous avons utilisé comme base à l’époque) avait pour intention de charger des matériaux DOOM 3 non modifiés, et Doom 3 utilisait la convention DirectX à l’époque même si c’était un jeu OpenGL… Tous les dérivés id Tech 3 libres, du moins ceux qui ont survécu, ont suivi ce chemin.

Nous avons corrigé plein de bugs, certains étant là depuis avant que Tremulous 1.1 existe… Nous avons aussi corrigé de très vieux défauts de conception que nous avons hérités d’XreaL. XreaL était une démonstration technique impressionnante mais une démonstration technique, il nécessitait des décennies de travail pour être prêt pour la production.

Le moteur de rendu précoce (forward renderer) est déprécié au profit du moteur de rendu tuilé (tiled renderer), qui est plus performant quand il y a plein de lumières dynamiques dans une scène, et ce moteur de rendu est désormais en meilleur forme que le précédent, le nouveau recevant toute l’attention.

À partir de la version 0.52 de Dæmon, il est désormais possible de faire tourner les jeux dans des fenêtres sans bordure, en plus du mode plein-écran et du fenêtrage classique ordinaires.

Sauter dans le futur

Les recommandations de conditionnement de textures du moteur Dæmon.

À partir de la version 0.52, le moteur Dæmon prend en charge le rendu physique réaliste (Physically Based Rendering, PBR). Dans un fichier de materiau, utiliser simplement le mot clé physicalMap suivi du chemin de fichier image pour activer le PBR pour ce matériau. Le conditionnement attendu est ORM (Occlusion, Roughness, Metalness) de façon similaire au standard glTF 2.0 pour rendre les choses faciles. Il y avait déjà une preuve de concept dans la version 0.51 mais ça n’avait pas été rendu disponible. Actuellement le jeu Unvanquished ne fournit pas de textures PBR mais cette fonctionnalité est supposément prête pour être utilisée, y compris dans du contenu communautaire.

Nous avons aussi corrigé la prise en charge du relief mapping, le code de relief mapping était dans le moteur depuis très longtemps puisqu’il avait été hérité d’XreaL, mais il était inutilisé et il y avait de sérieux problèmes associés à ce code. Certains étaient même des défauts de conception.

Pour diverses raisons le code de relief mapping que nous avions s’attendait à ce que les cartes de hauteur (height map) soient distribuées dans le canal alpha des cartes normal la tête en bas, cela signifie que blanc signifiait bas et noir signifiait le niveau du sol… Après investigation, il fut découvert qu’XreaL prenait en charge deux manières de fournir des cartes de hauteur : comme fichier indépendant avec l’orientation standard, et comme canal alpha dans les fichiers de carte normale, mais inversé.

Le gros défaut de conception de telles cartes de hauteur inversées dans un canal alpha est qu’un canal alpha inexistant est supposé être équivalent à un canal alpha opaque, et un canal alpha opaque est censé être complètement blanc. Donc, avec une telle conception, un fichier de carte normale sans canal alpha conduirait le moteur à considérer que le canal alpha est blanc, et parce que la carte normale était lue tête en bas, un canal alpha absent signifierait… un déplacement maximum. Et oui, la façon donc XreaL fut conçu signifiait que ne pas distribuer une carte de hauteur dans le canal alpha d’une carte normale aurait signifié un déplacement maximum…

Pour contourner ce problème, XreaL a implémenté un mot-clé spécial appelé parallax à utiliser dans les matériaux, l’absence de celui-ci aurait indiqué au moteur de ne pas tenter de lire le canal alpha depuis un fichier de carte normale. Ceci était plus compliqué que nécessaire : pour contourner un défaut de conception avec des cartes de hauteur à l’envers, un mot-clé spécial fut créé pour ne pas être utilisé pour que le moteur sache qu’il devait lire les cartes normales avec un code différent des autres textures.

En retournant à l’orientation standard des cartes de hauteur (noir est en bas, blanc et au niveau du sol), toutes les planètes s’alignent parfaitement : tous les fichiers de carte normale peuvent être lus en tant que RGBA et les cartes normales seront toujours correctes même si le canal alpha est absent parce que pas de canal alpha signifie blanc, et blanc signifie pas de déplacement… Et donc, on peut questionner la pertinence du mot clé parallax.

Cependant, nous avons créé un mot clé de matériau spécial nommé normalHeightMap que nous recommandons d’utiliser avec les cartes normales distribuant des cartes de hauteur, simplement pour rendre cela explicite et prendre ceinture et bretelle. Une chose est qu’il est très commun dans le monde du jeu vidéo d’utiliser un format spécial nommé BC3/DXT5 (ou DXT5nm) qui stocke la donnée X dans le canal Alpha au lieu du canal Vert. Le moteur gère ce cas et ne considère pas un tel canal alpha comme alpha, et donc, tout fonctionne. Mais pour être vraiment sûr, comme prévenir des bugs de pilote de carte graphique et d’autres choses, nous recommandons d’utiliser le mot clé normalHeightMap quand il s’agit de distribuer à la fois une carte normale et une carte de hauteur dans le même fichier.

Ainsi, il y a deux manières d’ajouter des cartes normales et des cartes de hauteur à un matériau :

        normalMap textures/shared_pk02_src/wall_big02a_n
        heightMap textures/shared_pk02_src/wall_big02a_h

et :

        normalHeightMap textures/shared_pk02_src/wall_big02a_nh

Bien que le fait d’embarquer une carte de hauteur dans le canal alpha d’une carte normale soit pris en charge, nous recommandons de stocker la carte normale et la carte de hauteur dans deux fichiers différents. Nous recommandons d’utiliser le fichier DXT5nm pour compresser les cartes normales et parce que ce format stocke de la donnée normale dans le canal alpha pour des raisons d’efficacité, ce format ne peut pas distribuer de carte de hauteur. En même temps, l’outil Crunch choisira simplement la meilleure variante DXT pour les fichiers en échelle de gris. Quand le relief mapping (qui est coûteux) est désactivé, les cartes de hauteurs ne seront jamais chargées depuis le disque ni chargées dans la mémoire de la carte graphique.

Le moteur prend désormais en charge l’échelle et la compensation (offset) de carte de hauteur, bien que ce ne soit pas encore rendu officiellement disponible aux artistes. La raison est que nous avons utilisé les cartes et textures de Xonotic comme banc d’essai pour ces fonctionnalités, donc cela est uniquement pris en charge dans le mode de compatibilité DarkPlaces qui est désactivé par défaut, et en utilisant des mots clés qui ne sont pas utilisables sur les terrains fusionnés (blended terrains) par exemple. Le problème de mot-clé DarkPlaces est similaire à celui de Doom 3 dont nous parlons ci-après, les étages (stages) ne sont pas complètement pris en charge et les mots-clés peuvent ne pas être conçus pour être compatibles avec cette fonctionnalité. Fournir la prise en charge d’échelle et de compensation de carte de hauteur est planifié de toute façon. La majeure partie du code est déjà là et fonctionnelle, il ne nous reste plus qu’à ajouter les mots-clés de matériau associé pour que les artistes puissent les utiliser.

Comme dit précédemment, nous avons ajouté des mots-clés de matériau pour basculer l’orientation des composants de carte normale. Nous n’avons pas investigué pourquoi XreaL s’attendait à ce que les cartes de hauteur embarquées dans les cartes normales soient inversées. Nous savons qu’XreaL a inversé le composant Y des cartes normales parce qu’il imitait Doom 3, peut-être qu’XreaL a inversé les cartes de hauteur à cause d’un jeu, et reproduisait simplement le défaut de conception d’une implémentation de référence… De toute façon il serait trivial d’ajouter un mot-clé pour inverser l’orientation de carte de hauteur si nécessaire.

Nous avons créé un dépôt spécial de données pour tester la prise en charge de fonctionnalité et prévenir les régressions dans le moteur et l’outillage associé (éditeur de niveau NetRadiant, compilateur de carte Q3map2…). Par exemple il y a des cartes (niveaux) pour tester les divers formats de carte normale, pour tester l’éclairage dynamique, pour toutes les diverses variantes du format PNG, etc. Je désire remercier spécialement SomaZ du projet OpenJK pour les données qu’il a fournies pour tester la prise en charge du PBR.

Nous avons implémenté du code pour calculer une carte normale depuis une carte de hauteur si la carte normale est absente. Le code fonctionne et est probablement prêt à être distribué, mais il a manqué la version 0.52, parce qu’il lui manquait une carte de test adaptée pour s’assurer que l’orientation de la carte normale calculée était celle attendue. Vous verrez ce code bientôt de toute façon. Cela dit, nous ne recommanderions pas de se reposer dessus parce que ce serait lourd en termes de calcul sur la carte graphique, mais cela peut améliorer la compatibilité avec du contenu tierce-partie.

Parce que nous avons utilisé les données de Xonotic comme banc d’essai pour les diverses fonctionnalités que nous avons implémentées ou corrigées, le moteur Dæmon prend en charge des liens symboliques basiques dans les archives PK3 / DPK, et fournit une couche de compatibilité DarkPlaces, cependant les cartes de lumières (light maps) sRGB ne sont pas encore implémentées. Précédemment dans la version 0.51 nous avions aussi implémenté le préfixe dds/ optionnel pour les fichiers DDS tel que DarkPlaces et Doom 3 s’attendent à les trouver.

Pour tout ce qui ne doit pas être compressé avec un format DXT, WebP est parfait.

Puisque nous parlons des formats DXT, les formats d’image que nous recommandons d’utiliser avec le moteur Dæmon sont les suivants :

• Cartes de lumière (light map) : WebP sans perte;
• Skybox : WebP avec perte;
• Carte normale (normal map) : CRN normalisé (variante Unity/Dæmon avec option -rtopmip);
• Tout le reste : CRN (variante Unity/Dæmon).

Le format CRN est un format spécial optimisé pour la compression et la qualité visuelle. Il est produit par l’outil Crunch. Initialement développé par Binomial, il ne fut pas maintenu et plus tard Unity l’a grandement amélioré. Comme dit au moment de la sortie d’Unvanquished 0.51, notre corpus complet de 1797 textures de l’époque fut compressé 4,31 fois plus rapidement et 11,15% de la taille produite fut économisée, comme promis par les gens d’Unity. La variante d’Unity est incompatible avec celle de Binomial, mais étant donné les chiffres, il n’avait pas de raison de ne pas sauter le pas. Parce qu’à la fois Binomial et Unity se contentent de larguer du code sans attendre de participation communautaire, nous maintenons Crunch sur note GitHub. En dehors de l’option -rtopmip citée pour une meilleure normalisation des cartes normales, tout ce que nous faisons c’est de maintenir la prise en charge sur plusieurs plates-formes (cross platform) tout en ne cassant pas la compatibilité avec l’amont. Si vous cherchez un Crunch maintenu que vous pourriez intégrer dans Windows, Linux et macOS et/ou êtes en recherche d’une intégration CMake adaptée, vous venez de le trouver à l’instant.

Corriger les défauts de conception des matériaux

Nous avons corrigé un bug de rotation de texture. Cela fut d’abord remarqué avec quelques cartes de Tremulous comme Metro ou notre propre carte Unvanquished PArpax. Nous avons ensuite reproduit le bug avec les données de Smokin' Guns, et gimhael l’a corrigé.

Nous avons aussi corrigé un problème avec des skyboxes spéciales ayant des faces de taille différentes. Encore une fois ce bug fut reproduit avec des cartes de Tremulous et de Smokin' Guns. Avoir des skyboxes dont toutes les faces n’ont pas la même taille peut sembler surprenant, mais il semble que c’était une astuce d’optimisation utilisé à l’époque de Quake 3 : la face de dessous est généralement sous le sol et jamais vue (à moins que votre carte soit une plate-forme suspendue dans l’espace), donc la face du dessous était souvent un tout petit succédané (placeholder). Parce que corriger ce problème a aussi révélé plein d’autres en puissance, à la fin nous avons entièrement réécrit cette part du code de skybox.

Puisque nous parlons de matériaux, nous avons modifié un peu la syntaxe pour corriger une régression de conception venant de Doom 3. Quand XreaL a implémenté le multitexturage (multitexturing) comme le fait d’ajouter des cartes normales, spéculaires, etc. à une unique texture, la syntaxe de Doom 3 a été implémentée.

À l’époque de Quake 3 il était possible de décrire un matériau simple comme une liste d’étages (stages). Par exemple un étage peint le texture du mur et une autre étage peint les lumières et ombres calculées. Ces étages étaient puissants : il y a des mots-clés pour fusionner, tourner, translater, etc. Ils n’étaient pas appelés matériaux mais shaders… Ajouter une carte d’addition aurait simplement nécessité d’ajouter un autre étage pour le fusionner avec les précédents.

Cependant, pour la plupart des cas d’usage, comme une surface simple avec une seule texture devant recevoir lumière et ombres, cela était très verbeux, vous deviez littéralement écrire des opérations de fusion pour cela…

Doom 3 a créé des mots-clés spéciaux qui étaient des raccourcis pour les étages, une ligne simple comme diffuseMap chemin/vers/diffusemap configurait la carte diffuse (diffuse map, carte de couleurs de diffusion de base) pour être appliquée avec les lumières calculées, et la ligne specularMap chemin/vers/specularmap appelait l’étage spéculaire.

Parce que réaliser de multiples passes de rendu est coûteux et qu’un shader GLSL peut exécuter plusieurs opérations à la fois, des moteurs tels qu’XreaL puis Dæmon ont tenté d’imbriquer les matériaux avec des heuristiques, donc un seul shader GLSL peut calculer les normales, fusionner les lumières et la carte d’addition, etc. Cela signifie que la syntaxe était suboptimale et ne se rapportait pas bien au véritable calcul, même s’il était possible de jouer aux devinettes au moment de parser le matériau pour atténuer cela.

Cette syntaxe n’était pas seulement suboptimale parce qu’elle ne correspondait pas au véritable calcul, elle était aussi suboptimale parce qu’elle ne satisfaisait pas les besoins des utilisateurs, et un problème qui n’était pas corrigeable avec du code d’optimisation était les régressions de fonctionnalités.

Quake 3 prenait en charge une fonctionnalité appelée fusion de terrain (terrain blending). Vous pouvez étager plusieurs textures dans un seul matériau, comme une texture de rocher et une de sable, et avec des calculs, le compilateur de carte et le moteur vont fusionner ces textures sur la surface. C’est vraiment utile pour les terrains.

Mais avec la syntaxe de Doom 3, un étage spéculaire serait au même niveau que celui d’une autre texture fusionnée, donc le stage spéculaire pour la texture de rocher serait aussi appliqué sur la texture de sable si le matériau consiste à fusionner rocher et sable.

Fusion de terrain multitexturé dans la carte communautaire Hangar 28 par tvezet, avec des composants diffus, spéculaires, normaux et de hauteur.

Donc, avant le moteur Dæmon 0.52, un jeu était en mesure de fournir des surfaces multitexturées excepté dans certains cas comme les terrains fusionnés qui étaient toujours rendus comme en 1999. C’est dommage…

Nous avons amélioré la syntaxe en faisant en sorte que les mots-clés comme diffuseMap ne décrivent pas des étages, mais décrivent les composants d’une seule texture utilisée dans un étage.

Ainsi le moteur Dæmon prend en charge la syntaxe historique de Quake (qui est toujours utile pour les 5% de cas d’utilisations), la syntaxe Doom 3 (avec des avertissements parce qu’il n’y a pas de bonne raison de l’utiliser), et la syntaxe Dæmon, avec deux exemples donnés ici :

textures/parpax_custom/squarelamp_blue_40k
{
    // some hidden editor and map compiler keywords
    {
        diffuseMap textures/parpax_custom_src/squarelamp_blue_d
        glowMap textures/parpax_custom_src/squarelamp_blue_a
    }
}

et :

textures/thunder_custom/ter_rocksand_xy
{
    // some hidden editor and map compiler keywords
    {
        diffuseMap textures/shared_pk02_src/rock01_d
        normalMap textures/shared_pk02_src/rock01_n
        specularMap textures/shared_pk02_src/rock01_s
        rgbGen identity
    }
    {
        diffuseMap textures/shared_pk02_src/sand01_d
        normalMap textures/shared_pk02_src/sand01_n
        specularMap textures/shared_pk02_src/sand01_s
        blendFunc blend
        alphaGen vertex
    }
}

À partir de la version 0.52, le moteur Dæmon propose la puissante versatilité des shaders de Quake 3, tout en rendant facile en même temps de configurer des matériaux multi texturés comme les matériaux de Doom 3, tout en évitant les défauts liés aux shaders Quake 3 (pas de passe de rendu supplémentaire, pas d’heuristique d’imbrication pour économiser les passes de rendu…) et en évitant les limitations des matériaux Doom 3 : vous pouvez fusionner plusieurs textures ayant plus d’un composant ! Du côté de la syntaxe, ce n’est que l’affaire d’un bloc {} supplémentaire. La différence du côté du moteur, c’est le jour et la nuit.

Le code d’imbrication des matériaux historiques fut entièrement réécrit de zéro. D’immenses parties du parseur de matériaux ont été réécrites, il en fut de même pour des parties du code configurant les shaders GLSL, et de grandes parties des shaders GLSL eux-mêmes ont aussi été réécrites.

Une vue sur l’écosystème du moteur Dæmon

Le moteur Dæmon utilise pour le moment Native Client comme plate-forme pour exécuter votre propre jeu avec des performances natives. Compilez votre code une seule fois, distribuez-le aux joueurs ou hébergez votre mod sur votre propre serveur, et les joueurs sur Linux, Windows et macOS pourront apprécier le jeu.

À la différence d’anciennes technologies comme la QVM originale qui requérait un compilateur C spécifique, non libre et désormais obsolète, vous pouvez écrire du code C++ moderne et vous appuyer sur des bibliothèques C et C++ bien connues et prises sur étagère, tout en assurant aux joueurs d’exécuter votre code personnalisé dans un bac à sable. Et vous n’avez pas à vous soucier du système d’exploitation que vos joueurs utilisent.

Parce que l’industrie migre de Native Client vers WebAssembly, nous sommes actuellement en train de porter notre moteur sur la même lancée. Donc pour le moment les architectures autres qu’i686 et amd64 sont en pause parce que nous n’investissons plus de temps dans Native Client et nous nous focalisons d’abord sur le port WebAssembly avant d’investiguer d’autres plates-formes, afin d’économiser du précieux temps de développement. Pour les personnes intéressées par la prise en charge de la plate-forme Apple Silicon, avant que nous ne complétions la prise en charge WebAssembly et ARM, nous pouvons vous rassurer : le moteur Dæmon et le jeu Unvanquished fonctionnent correctement sur Rosetta 2.

Édition de la carte Forlorn d’Unvanquished dans NetRadiant.

À la différence de choses comme moteur Godot ou Unreal, le moteur Dæmon n’est pas une plate-forme d’édition par lui-même, c’est le moteur brut pour exécuter le jeu, un composant qui s’inscrit dans un écosystème plus large d’outils libres et ouverts autour du moteur pour satisfaire vos besoins, incluant l’éditeur de niveau NetRadiant et d’autres.

En plus des formats audio et d’image historiques comme Wav, TGA, PNG et JPEG, le moteur Dæmon prend en charge les formats audio compressés Vorbis et Opus, et prend en charge le format d’image WebP et les formats d’images optimisés pour les cartes graphiques comme KTX, DDS et CRN (voir note version maintenue de Crunch). CRN est parfait pour quasiment toutes les textures du jeu, tandis que nous recommandons le format WebP avec pertes pour les textures qui peuvent souffrir de compressions avec pertes agressives telles que les skyboxes, et le WebP sans pertes pour les textures qu’il ne vaut mieux pas compresser avec pertes, comme les cartes de lumières (light maps).

Nous avons abandonné la prise en charge de vidéo pour le moment parce qu’elle implémentait un format qui n’existe pas et qui ne doit pas exister : OGM avec Theora. OGM était un hack pour multiplexer de la vidéo XviD avec du Vorbis il y a plusieurs décennies avant qu’OGG soit standardisé pour Theora et Vorbis, donc ni les outils OGG ni les outils OGM ne peuvent produire des fichiers OGM avec Theora. Ce code vivait dans une réalité alternative qui n’a jamais eu lieu. Si quelqu’un a besoin de prise en charge vidéo à nouveau, il serait mieux d’implémenter WebM avec VPX et Opus, étant donné que notre moteur implémente déjà WebP et Opus.

Des outils comme le NetRadiant (upstream) et le compilateur de carte et lightmapper Q3map2 associé prennent en charge ces formats avancés de texture. Les joueurs peuvent commencer à concevoir des cartes communautaires pour votre jeu juste après avoir téléchargé le jeu lui-même et l’éditeur, rien de plus.

Modèles d’Unvanquished animés à base de segment dans le moteur Dæmon.

À côté du format de modèle et d’animation md3 de Quake 3 et le md5 de Doom 3, le moteur Dæmon prend en charge le format Inter Quake Model, qui est le standard de facto pour les moteurs de jeu libres comme les dérivés d’id Tech ou ceux de Cube/Sauerbraten. IQM est open-source, documenté, prend en charge des fonctionnalités comme l’animation à base de segment, les couleurs de vertex, etc. et il existe divers visualiseurs, importeurs et exporteurs pour ce format.

Avec l’éditeur de niveau NetRadiant, le compilateur de carte Q3map2, et l’outil de compression de texture Crunch, nous avons un outil graphique appelé Chameleon pour assister le processus de retexturage de niveaux avec des textures de plus haute définition, l’outil Sloth pour prendre en charge le processus de construction d’un dépôt de données et produisant une archive DPK fonctionnelle : vous tappez simplement urcheon build src/map-castle_src.dpkdir et vous obtenez un dpkdir fonctionnel avec les cartes étant compilées en bsp, les textures compressées vers tel variant de WebP ou de CRN selon ce à quoi elles servent, les modèles translatés, tournés, etc. et convertit vers IQM, l’audio compressé comme Opus… C’est un peu comme cmake pour des paquets de données, mais sans le besoin d’écrire un CMakeLists.txt explicite, à la place il repose sur des conventions de nommage pour sélectionner la meilleure action pour vos données. Pour les modèles IQM nous nous reposons sur la branche IQM hébergée par FTEQW parce qu’elle prend en charge des fichiers de commandes et des fonctionnalités de translation/rotation/compensation fonctionnelles.

Le moteur implémente un système de fichiers virtuel amélioré nommé DPK VFS qui est similaire au PK3/PK4 VFS, mais avec la possibilité de charger une sélection arbitraire de paquets. De cette manière un mod ou un niveau personnalisé peut se reposer sur des ressources, paquets et sets de textures donnés, sans avoir à se préoccuper de ce que font les autres mods et autres niveaux.

Comment réduire les coûts

Si vous planifiez de faire un jeu avec le moteur, et ceci est vrai pour n’importe quel moteur de cette nature (ioquake3, DarkPlaces, RBDOOM-3-BFG…), gardez à l’esprit que bien que cela semble super facile de cloner et de compiler son propre fork, et bien sûr que ça l’est, maintenir un moteur de jeu est une autre affaire et cela tourne vite en emploi à temps plein.

Et ensuite vous aurez toujours à trouver du temps pour le développement du jeu lui-même, la conception du gameplay, l’édition de niveaux, la modélisation, la conception sonore, le texturage, la communication de votre projet et les relations publiques, les cycles de versions, le suivi et la correction de bug, le test, la publication…

Donc si vous souhaitez prendre le moins de risque possible et voulez voir votre jeu trouver le succès nous vous encourageons profondément de contribuer vos propres patchs pour vos propres besoins au projet Dæmon amont.

Git, CMake et les outils usuels rendent si facile de construire des choses que cela peut donner de fausses impressions concernant de nombreux coûts cachés. C’est un moteur de jeu taillé pour la production, et même John Carmack travaillait à temps plein quand il travaillait sur id Tech 3 à l’époque, réfléchissez-y à deux fois. 🙂

Pour les jours à venir

Donc, pour le futur, il y a l’effort en cours pour WebAssembly, avec slipher et Kangz travaillant dessus, Kangz était celui qui avait déjà réalisé le port depuis QVM vers Native Client, donc nous savons qu’il a les compétences pour le faire, tout ce dont il a besoin c’est du temps libre.

Il y a eu des expérimentations de faites pour prendre en charge de meilleurs espaces de couleurs pour le stockage des cartes de lumières afin de réduire la gradation de couleur (colour banding), ainsi que la diffusion d’erreur (dithering) à cette même intention. Il y a aussi du code non-fusionné pour générer des cartes normales depuis des cartes de hauteur quand les cartes normales sont absentes, et des solutions de replis pour activer le deluxe mapping sur des matériaux sans cartes normales ni spéculaires sont investiguées. Le temps nous le dira, mais il est probable que certaines de ces fonctionnalités intégreront une future version.

Et la meilleure chose qui vient est que ce vendredi 14 mai, nous avons sorti Unvanquished beta 0.52, basé sur ce moteur. Dites-le à vos amis ! Ramenez-vous ! Soyez prêts !

Aller plus loin

• Annonce originale en anglais (unvanquished.net) (79 clics)
• Unvanquished : Changements de gameplay à venir (linuxfr.org) (39 clics)
• Unvanquished : Bâtir une communauté comme un service (linuxfr.org) (39 clics)
• Unvanquished : Maintenant nous sommes libres ! (linuxfr.org) (38 clics)