Annonce du moteur de jeu Dæmon 0.52 Beta

35
15
mai
2021
Jeu

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

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

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

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

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

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

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

É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

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 !

granger

Aller plus loin

  • # Merci

    Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

    Bravo, pour tout ce travail, et très belle dépêche. N'étant pas du tout dans le domaine j'ai du mal à apprécier le travail per se, mais plusieurs points me paraissent très intéressant à relever :

    • La persistance de bogues durant de nombreuses années, dont des bogues fantômes particulièrement délicats à débusquer. Quant on pense qu'ici les sources sont librement accessibles et qu'on imagine que nombre d'organisations mettent leurs données critiques en jeux sur des logiciels au code fermés dont les bogues de sécurité n'ont donc quasiment aucune chance d'être corrigés…

    • Le souci écologique et de lutter contre le bloatware : Merci de penser à nous qui utilisons du matériel peu performant. Mon fils apprécie de pouvoir jouer à ce genre de jeux sur son Rpi. L'idée que des cartes graphiques vieille de 18 ans puissent encore faire tourner ce type de moteur est vraiment rassurante. Moi qui avait dû renoncer à Gnome faute de GPU assez moderne, j'apprécie particulièrement.

    • En lisant on se pose de temps en temps la question, et la réponse vient en dernière ligne. Amusant de remarquer comment un auteur francophone commet des anglicisme en traduisant sa propre prose.

    Exemple :

    « 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 pouvons le savoir. »

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Merci

      Posté par  (site Web personnel) . Évalué à 8 (+5/-0). Dernière modification le 16/05/21 à 12:59.

      La persistance de bogues durant de nombreuses années, dont des bogues fantômes particulièrement délicats à débusquer. Quant on pense qu'ici les sources sont librement accessibles et qu'on imagine que nombre d'organisations mettent leurs données critiques en jeux sur des logiciels au code fermés dont les bogues de sécurité n'ont donc quasiment aucune chance d'être corrigés…

      Exactement, et encore, nous avons eu la chance que ce genre de bug aient des répercussions visuelles qu’un œil humain peut apprécier car se produisant sur une surface qu’il peut observer toute entière. Que se passe-t-il si ce genre de petite erreur d’arrondi affecte un mécanisme économique à l’échelle d’un territoire, qui a l’œil adapté pour repérer un tel problème ? Parce que ce genre de bug n’a jamais empêché le jeu de tourner, tout comme d’autres « bugs » n’empêchent pas le monde de tourner mais peuvent avoir un mauvais effet localement sur ceci ou cela.

      Le souci écologique et de lutter contre le bloatware : Merci de penser à nous qui utilisons du matériel peu performant. Mon fils apprécie de pouvoir jouer à ce genre de jeux sur son Rpi. L'idée que des cartes graphiques vieille de 18 ans puissent encore faire tourner ce type de moteur est vraiment rassurante. Moi qui avait dû renoncer à Gnome faute de GPU assez moderne, j'apprécie particulièrement.

      Dans ce domaine on peut peut-être déjà dire que le moteur Dæmon est plus testé que Linux. Les cartes AGP Radeon ne fonctionnent plus avec la configuration par défaut de Linux depuis cet été, et ce n’est pas intentionnel. Ce qui était intentionnel, c’était de désactiver du code AGP spécifique pour les faire tourner avec le code PCI générique… sauf que le code PCI générique est truffé de bug et donc le « fallback » ne fonctionne pas.

      Quelques fils sur le sujet:

      J’ai par exemple sous la main une machine de guerre de l’époque tout à fait capable aujourd’hui: CPU Phenom II à 4 cœurs, 16 Go de mémoire, un GPU Radeon avec puce de génération TeraScale: OpenGL 3.3, capable de faire de l’OpenCL 1 (mais pas de pilote Linux malheureusement), 1 Go de VRAM, HDMI, etc. mais AGP. Cet été, Ubuntu a rétroporté le patch désactivant l’AGP natif depuis la version 5.9-rc1 de Linux vers le noyau 5.4 de Ubuntu 20.04 LTS (support à long terme, avec un cycle de vie jusqu’en 2030). Mise à jour mineur du noyau, reboot. Ah non l’ordinateur ne reboot plus. Il y a des solutions de contournement mais voilà… Voir ce post pour plus de détails.

      J’écrirai peut-être un jour un journal sur ce genre de test. On découvre ou redécouvre des tas de choses, comme la segmentation du marché faite par Intel (deux produits de même nom ayant soit la virtualisation mais pas l’OpenGL moderne, ou bien l’OpenGL moderne mais pas la virtualisation), ou encore comment Nvidia triche sur le sondage de Steam (la GTX 1060 ne devrait pas être en tête avec une écrasante avance de 8.97% mais aux alentours de 1.2%, certainement derrière des AMD : ils ont simplement vendus 7 produits différents sous la même appellation).

      À propos du Raspberry Pi en particulier, le jeu ne tourne pas encore dessus à cause du fait qu’il n’est pas porté sur autre chose qu’x86/x86_64 pour le moment. Mais j’aimerai bien voir le port arm arriver, beaucoup plus pour le Pi que pour l’Apple M1, honnêtement. Notamment, il y a une demande pour faire tourner le serveur sur des Pis.

      En lisant on se pose de temps en temps la question, et la réponse vient en dernière ligne. Amusant de remarquer comment un auteur francophone commet des anglicisme en traduisant sa propre prose. Exemple :

      « 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 pouvons le savoir. »

      Je serai curieux de savoir ce qui te gène et quelle est ta proposition. Par exemple moi je ne suis pas satisfait de la formulation « autant que nous pouvons le savoir ». Peut-être que « autant que nous le sachions » est plus idiomatiquement juste. Parfois la formulation n’est pas foncièrement mauvaise, mais l’usage consacre d’autres formulations pour le même sens. Adapter le texte à ces idiomatismes est un travail plus difficile que la traduction, en particulier ça requiert de prendre du recul, éventuellement de laisser le texte dormir quelques semaines…

      Là en me relisant je remarque des petites améliorations pour accrocher un peu moins l’oreille française :

      - un mot-clé de matériau spécial
      + un mot-clé spécial de matériau
      
      - nous sommes actuellement en cours de porter
      + nous sommes actuellement en train de porter
      
      - ni les outils OGG ni les outils OGM peuvent produire des fichiers OGM avec Theora
      + 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 ne s’est jamais produite
      + Ce code vivait dans une réalité alternative qui ne s’est jamais réalisée

      Pour le mot clé spécial, bon l’expression anglaise était « special material keyword », il fallait déplacer l’adjectif après le nom pour satisfaire aux conventions françaises, mais en fait, je l’ai trop déplacé après et il semble donc qualifier le matériau et non le mot-clé. Pour « en cours de porter », soit on dit « en cours de portage », soit on dit « en train de porter »

      Par contre pour ceci :

      - et les joueurs sur Linux, Windows et macOS pourront apprécier le jeu
      + et les joueurs sur Linux, Windows et macOS pourront profiter du jeu

      La seconde est plus courante, la première est plus pédante… Mais la seconde décrit plus l’utilisateur comme un être de pulsion tandis que la première décrit plus l’utilisateur comme un être sophistiqué. Même si je viens de suggérer une autre formulation possible merci de conserver celle avec « apprécier » juste pour le fun. :D

      Pour vraiment expurger tous les anglicismes, il faudrait probablement quelques mois de travail, avec des phases de recul et de retour, en plusieurs passe (la réécriture d’une partie faisant apparaître d’autres maladresse, c’est une question d’équilibre).

      Avec du recul, je pense que la prochaine fois je traduirai « light map » par « carte d’éclairage » au lieu de « carte de lumière », pour lever la confusion avec le sens mécanique de lumière (une ouverture, un trou), et puis c’est plus joli. Je pourrai ajouter ça à traductions classiques.

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Merci

        Posté par  (site Web personnel) . Évalué à 2 (+0/-1).

        Corrigé, merci.

      • [^] # Re: Merci

        Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

        Je pourrai ajouter ça à traductions classiques

        ah, mais n'hésite pas à déjà l'ajouter en précisant les 2 possibilités et celle préférable ;-) Comme tu le sais, c'est un wiki, tout le monde pourra revenir dessus par la suite :D (et n'oublie pas de valider après prévisualisation :p).

      • [^] # Re: Merci

        Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

        « autant que nous pouvons le savoir ». Peut-être que « autant que nous le sachions »

        Ce n'est pas que pouvoir soit moins adapté que savoir ici, et pourtant la seconde proposition accroche moins l'oreille. Peut-être parce que le subjonctif est plus adapté pour cette proposition que l'indicatif ? D'ailleurs « autant que nous puissions le savoir » ne sonnerait-il pas tout aussi bien ?

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: Merci

          Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

          Hmm, oui tu as raison un subjonctif est plus adapté pour « autant que nous puissions le savoir », bien vu !

          Ce qui ne contredit pas que « que nous le sachions » soit une forme plus courante. =)

          ce commentaire est sous licence cc by 4 et précédentes

  • # Nom terrible : trop générique!

    Posté par  . Évalué à 5 (+4/-0).

    Comment vérifier s'il est disponible dans une distribution? Par exemple "apt-cache search daemon | wc -l" m'affiche 1379 résultats…

    Comment trouver des ressources sur internet? J'ai cherché "daemon", "daemon game" et "daemon moteur" avec toujours autant de succès : beaucoup de choses, rien de pertinent.

    • [^] # Re: Nom terrible : trop générique!

      Posté par  . Évalué à 4 (+2/-0). Dernière modification le 16/05/21 à 12:24.

      Mettre deux termes très génériques dans un moteur de recherche générique ne fait pas des miracles, en effet.

      Par contre, avec Dæmon open source game, ça commence à être pertinent par exemple ;)

      Bravo, sinon !

  • # Merci!

    Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

    Merci pour cette très belle dépêche et bravo pour le travail de fourmi que vous effectuez. Vous êtes combien pour tester sur autant de configurations différentes ?

    En tout cas, ça me rappelle le blog d'Alan Cox il y a 20 ans, qui débuggait du hardware à tour de bras.

    Côté LKML, on sent pas trop l'empressement de corriger les problèmes que tu as découvert. Dommage…

  • # Et sinon, le jeu est sorti =)

    Posté par  (site Web personnel) . Évalué à 6 (+3/-0). Dernière modification le 16/05/21 à 13:36.

    Et le jeu est sorti ce vendredi, la dépêche est en cours de traduction. =)

    Humains Unvanquished

    Aliens Unvanquished

    Le jeu peut être téléchargé là, préférer le « launcher », c’est vraiment fait pour.

    N’hésitez pas à rejoindre notre chat (accessible via IRC ou Discord), il y a un bot qui annonce quand il y a des parties en cours. 🙂

    Il y a généralement une communauté française et italienne qui joue dans la soirée du dimanche. Donc rendez-vous tout à l’heure. 😉


    À noter qu’on a constaté après coup un problème qui a été rapportée par des utilisateurs de Arch ou dérivés (Manjaro), si les locales de votre distribution ne sont pas correctement configurées, le jeu peux planter au démarrage. À la base ça ne devrait pas se produire qu’une distribution ait ce genre de problème de configuration. Si vous subissez le bug, corrigez votre environnement parce que vous pourriez avoir d’autres problèmes dans d’autres applications (problème dans les accents, dans l’interprétation des décimales, notamment les applications monétaires, etc.).

    Les personnes affectées ont confirmé que lancer le jeu de cette manière permettait au jeu de tourner comme prévu :

    LC_ALL="fr_FR.utf8"
    ./updater

    Ça doit être pareil si vous lancez ./daemon directement. On va très probablement sortir une mise à jour mineure qui sera automatiquement proposée si vous utilisez le « lanceur » (updater). Utiliser le lancer a plusieurs avantages, mises à jour automatique, intégration dans l’environnement (vous pouvez rejoindre une partie en cliquant sur les liens sur la liste de serveurs), ah et la lanceur télécharge le jeu et les mises à jour avec bittorrent, c’est très efficace.

    ce commentaire est sous licence cc by 4 et précédentes

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.