Pour UnrealArena, c’est un projet ex nihilo, il n’y a pas de portage depuis un autre moteur. C’est le moteur qui a été choisi par ce projet et c’est comme ça.
Pour Smokin'Guns, il se trouve que Smokin' Guns est, comme Tremulous, un mod de Quake3 devenu standalone. On sait qu’un portage depuis le moteur Quake 3 vers Dæmon est possible: Unvanquished l’a fait. Il est assez naturel pour un projet basé sur les technologies de Quake 3 qui voudrait se réinventer un peu de lorgner du côté de Dæmon. Les données utilisent les mêmes formats, avec les mêmes outils pour les gérer. Dæmon apporte quelques changements par-dessus et autour de ces formats parce qu’avec des décennies de recul on sait ce qui pouvait être mieux pensé, mais même quand la compatibilité est cassée pour faire mieux, porter les données de l’un à l’autre n’est pas très compliqué.
Au final Dæmon est un moteur qui est réellement utilisé par un jeu et qui est maintenu. Un projet comme ioquake3 apporte de nouvelles fonctionnalités, mais elles ne sont pas vraiment éprouvées parce que la vocation première d’ioquake3 est de faire tourner Quake 3 sans le casser. Ça veut aussi dire qu’ioquake3 ne peut pas corriger certains défauts de conception.
Par exemple ce que je vais dire pourra paraître surprenant et à contre-courant des présupposés, mais Quake3 n’as pas vraiment été pensé pour être "moddé", il a été pensé pour être mis à jour facilement. La nuance, c’est que les mécanismes utilisés par les "moddeurs" sont des mécanismes qui permettent à l’éditeur du jeu de modifier son propre jeu pour l’améliorer, distribuer ses mises à jour, mais ces mécanismes ne sont pas pensés pour isoler les modifications du jeu original. N’importe quel serveur malintentionné peut distribuer un fichier de mise à jour qui casse le jeu tant que ce fichier n’est pas supprimé manuellement par le joueur (s’il l’identifie). Dæmon a amélioré le format des archives à la base du système de fichier virtuel du jeu en ce sens par exemple.
Par ailleurs, le moteur est juste plus avancé dans plein de domaines, notamment graphique.
Pour Xonotic, la raison n’est pas « plus beau ». En termes de résultat final (ce qui est affiché à l’écran), Dæmon est encore un peu en retrait de Darkplaces (le moteur actuellement utilisé par Xonotic. Pour être au même niveau il faut réparer les effets d’eau et implémenter les lightmaps dans l’espace sRGB. Par ailleurs Darkplaces est encore un peu plus performant que Dæmon. DarkPlaces a l’avantage d’être bien plus mature et éprouvé, 3D Realms a même sorti un jeu dessu en 2020: Wrath: Aeon of Ruin.
Mais DarkPlaces est un vieux cheval. C’est initialement un moteur pour faire tourner Quake 1, et aucune modification qui pourrait casser Quake 1 ne sera implémentée. Dans DarkPlaces, les jeux sont codés en QuakeC, une espèce de langage dédié qui ressemble un peu au C, et tournent dans une machine virtuelle maison communément dénommée Q1VM. C’est un langage et un environnement très spécifique, avec des tas de vieilleries, de limitations, et de bizarreries.
Le moteur de Quake 3 avait fait le choix de partir sur du C pour le code des jeux, du véritable C, mais compilé avec un compilateur spécifique (et non-libre, LCC) dont les binaires tournaient sur une machine virtuelle maison (QVM). C’est déjà énorme par rapport à la Q1VM et le QuakeC. Dæmon est allé plus loin. Le problème de la QVM est que là encore, c’est une technologie spécifique, on est donc loin des performances que peut permettre l’état de l’art actuel, même s’il faut le reconnaître, c’est tout de même pas mal. L’autre problème de la QVM c’est que si c’est du vrai C, c’est du C assez ancien qui compile avec un compilateur ancien et limité. On oublie tous les progrès sur les compilateurs qui ont pu être fait en 20 ans, on oublie la réutilisation de certains codes en C écrit depuis qui ne seraient tout simplement pas compilable sur LCC, etc. Sachant que pour conserver des fichiers sources commun entre le moteur et le jeu, le moteur en subit des limitations
Dæmon prend en charge le même C++ dans le moteur et le jeu. La machine virtuelle actuelle est NativeClient (NaCl), maintenant que celui-ci est déprécié au profit de WebAssembly (WASM, le mal nommé, qui n’est pas du tout spécifique au web), nous avons un plan de migration vers celui-ci, mais jusqu’à très récemment d’après les spécialistes, WebAssembly n’était pas encore prêt pour nos besoins. À suivre...
Le but de Xonotic serait donc de s’affranchir de DarkPlaces. Il y a plusieurs expérimentations. Celle qui donne des résultats déjà visibles est une espèce de glue qui en réalité implémente une Q1VM par-dessus NaCL. L’idée serait de porter le jeu en Quake C d’abord, puis de l’améliorer par partie dans un autre langage si j’ai bien compris. Actuellement tout ce qu’on peut faire avec ça c’est se ballader dans les maps et c’est tout. C’est une démo technique, une preuve de concept.
J’ai vu passer deux projets de transpileurs. L’un qui transpile du code vers du C++ mais sans tenir compte du fait que ce soit lisible à la sortie. L’idée serait là aussi de porter petit à petit le code tout en transpilant ce qui n’est pas porté, si j’ai bien compris.
Un autre projet plus ambitieux est un projet qui vise à transpiler le code QC vers du rust directement exploitable.
Tout ça ce sont fondamentalement des travaux de recherche en fait. Le futur appartient aux audacieux, aux persévérants, et aux chanceux qui survivent aux chauffards.
Il est tout à fait possible que Xonotic reste sur DarkPlaces encore longtemps.
De ce que je sais, même si Dæmon est un peu à la traine derrière Darkplaces concernant certains effets graphiques (mais pourrait être en avance sur d’autres, mais pour Xonotic forcément l’éventuel « plus » ne peut pas se voir), Dæmon aurait une architecture plus moderne sur le plan du moteur de rendu. L’idée serait donc de bénéficier de ce que DarkPlaces n’a pas en ajoutant ce qui manque a Dæmon, sur une base déjà plus accueillante.
Il se trouve que DarkPlaces a implémenté nombre de technologies de Quake 3: le format des paquets, le format des maps, et partiellement le format des matériaux. Xonotic a donc des données qui se chargent à 90% dans Dæmon sans trop pousser. Ceci est vraiment important pour Xonotic car avec 19 ans d’histoire (en comptant Nexuiz) ça fait plusieurs milliers de cartes communautaires dont il serait dommage de casser la compatibilité.
Et globalement, derrière tout ça, il y a l’idée d’aller plus loin ensemble.
Par exemple revient parfois la discussion de l’éventualité d’intégrer le moteur graphique de Dæmon dans ET:Legacy, mais seulement la partie rendu graphique parce qu’ils doivent rester binairement compatible avec le jeu Wolfenstein: Enemy Territory. Ce serait là aussi pour éviter la dispersion. Mais comme beaucoup de choses ce sont des idées qui flottent au-dessus de nos têtes et on verra bien dans le futur ce qu’il en deviendra...
Les communautés de joueurs ne se mélangent pas vraiment, mais plusieurs développeurs ont un pied dans plusieurs projets. Et personnellement je travaille beaucoup à entretenir le réseau. Je pense que c’est vraiment ce qui me tient le plus à cœur : jeter des ponts et rassembler. J’essaie de faire ce qui est à ma portée. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Avantages pour les autres projets
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Unvanquished : maintenant nous sommes libres !. Évalué à 9.
Du plus simple au plus complexe à décrire...
Pour UnrealArena, c’est un projet ex nihilo, il n’y a pas de portage depuis un autre moteur. C’est le moteur qui a été choisi par ce projet et c’est comme ça.
Pour Smokin'Guns, il se trouve que Smokin' Guns est, comme Tremulous, un mod de Quake3 devenu standalone. On sait qu’un portage depuis le moteur Quake 3 vers Dæmon est possible: Unvanquished l’a fait. Il est assez naturel pour un projet basé sur les technologies de Quake 3 qui voudrait se réinventer un peu de lorgner du côté de Dæmon. Les données utilisent les mêmes formats, avec les mêmes outils pour les gérer. Dæmon apporte quelques changements par-dessus et autour de ces formats parce qu’avec des décennies de recul on sait ce qui pouvait être mieux pensé, mais même quand la compatibilité est cassée pour faire mieux, porter les données de l’un à l’autre n’est pas très compliqué.
Au final Dæmon est un moteur qui est réellement utilisé par un jeu et qui est maintenu. Un projet comme ioquake3 apporte de nouvelles fonctionnalités, mais elles ne sont pas vraiment éprouvées parce que la vocation première d’ioquake3 est de faire tourner Quake 3 sans le casser. Ça veut aussi dire qu’ioquake3 ne peut pas corriger certains défauts de conception.
Par exemple ce que je vais dire pourra paraître surprenant et à contre-courant des présupposés, mais Quake3 n’as pas vraiment été pensé pour être "moddé", il a été pensé pour être mis à jour facilement. La nuance, c’est que les mécanismes utilisés par les "moddeurs" sont des mécanismes qui permettent à l’éditeur du jeu de modifier son propre jeu pour l’améliorer, distribuer ses mises à jour, mais ces mécanismes ne sont pas pensés pour isoler les modifications du jeu original. N’importe quel serveur malintentionné peut distribuer un fichier de mise à jour qui casse le jeu tant que ce fichier n’est pas supprimé manuellement par le joueur (s’il l’identifie). Dæmon a amélioré le format des archives à la base du système de fichier virtuel du jeu en ce sens par exemple.
Par ailleurs, le moteur est juste plus avancé dans plein de domaines, notamment graphique.
Pour Xonotic, la raison n’est pas « plus beau ». En termes de résultat final (ce qui est affiché à l’écran), Dæmon est encore un peu en retrait de Darkplaces (le moteur actuellement utilisé par Xonotic. Pour être au même niveau il faut réparer les effets d’eau et implémenter les lightmaps dans l’espace sRGB. Par ailleurs Darkplaces est encore un peu plus performant que Dæmon. DarkPlaces a l’avantage d’être bien plus mature et éprouvé, 3D Realms a même sorti un jeu dessu en 2020: Wrath: Aeon of Ruin.
Mais DarkPlaces est un vieux cheval. C’est initialement un moteur pour faire tourner Quake 1, et aucune modification qui pourrait casser Quake 1 ne sera implémentée. Dans DarkPlaces, les jeux sont codés en QuakeC, une espèce de langage dédié qui ressemble un peu au C, et tournent dans une machine virtuelle maison communément dénommée Q1VM. C’est un langage et un environnement très spécifique, avec des tas de vieilleries, de limitations, et de bizarreries.
Le moteur de Quake 3 avait fait le choix de partir sur du C pour le code des jeux, du véritable C, mais compilé avec un compilateur spécifique (et non-libre, LCC) dont les binaires tournaient sur une machine virtuelle maison (QVM). C’est déjà énorme par rapport à la Q1VM et le QuakeC. Dæmon est allé plus loin. Le problème de la QVM est que là encore, c’est une technologie spécifique, on est donc loin des performances que peut permettre l’état de l’art actuel, même s’il faut le reconnaître, c’est tout de même pas mal. L’autre problème de la QVM c’est que si c’est du vrai C, c’est du C assez ancien qui compile avec un compilateur ancien et limité. On oublie tous les progrès sur les compilateurs qui ont pu être fait en 20 ans, on oublie la réutilisation de certains codes en C écrit depuis qui ne seraient tout simplement pas compilable sur LCC, etc. Sachant que pour conserver des fichiers sources commun entre le moteur et le jeu, le moteur en subit des limitations
Dæmon prend en charge le même C++ dans le moteur et le jeu. La machine virtuelle actuelle est NativeClient (NaCl), maintenant que celui-ci est déprécié au profit de WebAssembly (WASM, le mal nommé, qui n’est pas du tout spécifique au web), nous avons un plan de migration vers celui-ci, mais jusqu’à très récemment d’après les spécialistes, WebAssembly n’était pas encore prêt pour nos besoins. À suivre...
Le but de Xonotic serait donc de s’affranchir de DarkPlaces. Il y a plusieurs expérimentations. Celle qui donne des résultats déjà visibles est une espèce de glue qui en réalité implémente une Q1VM par-dessus NaCL. L’idée serait de porter le jeu en Quake C d’abord, puis de l’améliorer par partie dans un autre langage si j’ai bien compris. Actuellement tout ce qu’on peut faire avec ça c’est se ballader dans les maps et c’est tout. C’est une démo technique, une preuve de concept.
J’ai vu passer deux projets de transpileurs. L’un qui transpile du code vers du C++ mais sans tenir compte du fait que ce soit lisible à la sortie. L’idée serait là aussi de porter petit à petit le code tout en transpilant ce qui n’est pas porté, si j’ai bien compris.
Un autre projet plus ambitieux est un projet qui vise à transpiler le code QC vers du rust directement exploitable.
Tout ça ce sont fondamentalement des travaux de recherche en fait. Le futur appartient aux audacieux, aux persévérants, et aux chanceux qui survivent aux chauffards.
Il est tout à fait possible que Xonotic reste sur DarkPlaces encore longtemps.
Il y a des choses intéressantes à lire à ce sujet ici :
https://gitlab.com/xonotic/xonotic/-/issues/244
Et là:
https://gitlab.com/xonotic/daemon-glue/-/issues/1
De ce que je sais, même si Dæmon est un peu à la traine derrière Darkplaces concernant certains effets graphiques (mais pourrait être en avance sur d’autres, mais pour Xonotic forcément l’éventuel « plus » ne peut pas se voir), Dæmon aurait une architecture plus moderne sur le plan du moteur de rendu. L’idée serait donc de bénéficier de ce que DarkPlaces n’a pas en ajoutant ce qui manque a Dæmon, sur une base déjà plus accueillante.
Il se trouve que DarkPlaces a implémenté nombre de technologies de Quake 3: le format des paquets, le format des maps, et partiellement le format des matériaux. Xonotic a donc des données qui se chargent à 90% dans Dæmon sans trop pousser. Ceci est vraiment important pour Xonotic car avec 19 ans d’histoire (en comptant Nexuiz) ça fait plusieurs milliers de cartes communautaires dont il serait dommage de casser la compatibilité.
Et globalement, derrière tout ça, il y a l’idée d’aller plus loin ensemble.
Par exemple revient parfois la discussion de l’éventualité d’intégrer le moteur graphique de Dæmon dans ET:Legacy, mais seulement la partie rendu graphique parce qu’ils doivent rester binairement compatible avec le jeu Wolfenstein: Enemy Territory. Ce serait là aussi pour éviter la dispersion. Mais comme beaucoup de choses ce sont des idées qui flottent au-dessus de nos têtes et on verra bien dans le futur ce qu’il en deviendra...
Les communautés de joueurs ne se mélangent pas vraiment, mais plusieurs développeurs ont un pied dans plusieurs projets. Et personnellement je travaille beaucoup à entretenir le réseau. Je pense que c’est vraiment ce qui me tient le plus à cœur : jeter des ponts et rassembler. J’essaie de faire ce qui est à ma portée. =)
ce commentaire est sous licence cc by 4 et précédentes