À l’occasion de la sortie de la version 25.10.1 de la suite Radeon Software for Linux du 21 mai 2025, AMD a annoncé que la série 25.10 est la dernière à livrer des composants logiciels propriétaires.

Ces composants propriétaires étaient déjà optionnels depuis bien longtemps, la plupart des utilisateurs de cartes AMD ne s’en servait déjà pas, et le plus grand nombre ignorait peut-être jusqu’à l’existence de certains d’entre eux…

Ce jalon est l’accomplissement de 18 années d’un travail acharné commencé en 2007 avec la publication de documentations des cartes graphiques ATI après le rachat par AMD… Les plus anciens se souviendront de RadeonHD… Et désormais, ce sont les derniers bouts de logiciel propriétaire qui sont poussés vers la sortie.

Nos logiciels libres sont plus sereins lorsqu’ils reposent sur des pilotes libres…

Sommaire

• L’offre complètement libre de pilotes graphiques AMD sous Linux
• RADV officiellement supporté
• Ce que support veut dire
• Le départ des derniers
• Adieu OGLP
• Adieu AMDVLK-Pro
• Adieu AMF
• Souvenir des pilotes AMD abandonnés sur le bord du chemin
• Mais… et les firmwares ?
• Préférer le DisplayPort à l’HDMI pour les très hautes définitions…
• Prochain objectif : l’universalité du calcul et de la virtualisation ?

L’offre complètement libre de pilotes graphiques AMD sous Linux

Voici comment se composera très bientôt l’offre officielle de pilotes graphiques AMD pour Linux :

OpenGL et Vulkan sont des interfaces de programmation (API) graphiques, VA-API est une interface de programmation multimédia, et HIP et OpenCL sont des interfaces de programmation pour le calcul spécialement conçues pour satisfaire aux particularités architecturales des cartes graphiques.

Il est à noter que même si vous n’utilisez pas la suite Radeon Software for Linux, votre distribution vous fournit déjà le pilote Linux et les pilotes Mesa mentionnés.

• Pilote noyau
  • Linux amdgpu pour les cartes GCN1 et suivantes (pilote officiel).
• Pilote graphique Vulkan
  • AMD AMDVLK pour les cartes RDNA1 et suivantes (pilote officiel) ;
  • Mesa RADV, pour les cartes GCN1 et suivantes (pilote officiel).
• Pilote graphique OpenGL
  • Mesa RadeonSI pour les cartes GCN1 et suivantes (pilote officiel).
• Pilote multimédia VA-API
  • Mesa RadeonSI pour les cartes GCN1 et suivantes (pilote officiel).
• Pilote de calcul HIP
  • AMD ROCm pour une sélection de cartes RDNA2 et suivantes (pilote officiel),
    il n’existe pas d’autre implémentation de pilote HIP pour les autres cartes.
• Pilote de calcul OpenCL
  • AMD ROCm pour une sélection de cartes RDNA2 et suivantes (pilote officiel) ;
  • Mesa RustiCL pour les cartes GCN1 et suivantes.

Ces pilotes concernent donc les cartes GCN et RDNA. La famille de cartes GCN pour « Graphics Core Next » sont les cartes sorties à partir de la série HD 7000 en 2012, aussi nommées « Southern Islands » et qui ont inspiré le nom du pilote RadeonSI. La famille RDNA pour « Radeon DNA » (ADN Radeon) est une évolution de cette micro-architecture GCN et les cartes RDNA1 commencent avec les modèles RX 5000 en 2019 et les cartes RDNA2 avec les modèles RX 6000 en 2020.

Le tableau suivant se limite aux générations de cartes graphiques pour lesquelles il existe au moins un pilote fonctionnel faisant partie de la suite officielle Radeon Software for Linux. Il s’agit donc seulement de compatibilité technique. Les générations et modèles officiellement pris en charge par le support commercial d’AMD est évidemment plus restreint, et plus fluctuant, et puis ça dépend de l’API… La compatibilité technique effective intéressera probablement plus le lecteur.

✅️ = Pilote fonctionnel.
🧐️ = Pilote fonctionnel pour une sélection de modèles.
❌️ = Pilote non-fonctionnel.
⭐️ = Pilote faisant partie de la suite officielle Radeon Software for Linux (pour RADV : après les versions 25.10).
🐧️ = Pilote empaqueté en standard dans les distributions Linux usuelles.

La famille de cartes RDNA4 venant tout juste d’être mise sur le marché, conjecturer sa prise en charge est un exercice périlleux. On sait que le pilote ROCm n’est pas encore prêt, par exemple. Il est évident que les prochaines versions de tous ces pilotes les prendront en charge dans un futur proche.

Les derniers pilotes graphiques AMD propriétaires qui subsistaient encore étaient donc les pilotes OGLP, AMDVLK-Pro, et AMF.

Maintenant que tout est libre, ce qu’on attend désormais d’AMD est de faire fonctionner leur pilote de calcul HIP et leur pilote de virtualisation graphique GIM sur plus de matériel…

RADV officiellement supporté

La phrase est explicite, à partir de la sortie de la suite Radeon Software for Linux en version 25.20, « The Mesa Vulkan driver will be officially supported ». Autrement dit, le pilote Vulkan de Mesa sera officiellement supporté par AMD.

Le pilote Mesa pour les cartes AMD est RADV, initié originellement par Valve alors qu’AMDVLK était encore propriétaire.

Cette formulation n’exclut pas le pilote Vulkan libre AMDVLK d’AMD. AMDVLK sera donc très certainement encore supporté comme il l’est déjà.

Ce qui va changer pour Vulkan concerne AMDVLK-Pro, c’est ce que signifie la phrase « The AMD proprietary OpenGL and Vulkan drivers will no longer be included in the release », qui signifie aussi que le pilote OGLP pour OpenGL est également poussé vers la sortie.

Ce que support veut dire

Ce terme de support couvre les paquets de pilotes qu’AMD propose eux-mêmes, par exemple pour Ubuntu, Red Hat Linux Entreprise ou SUSE Linux Enreprise, ce sont les paquets dans le dépôt repo.radeon.com.

Mais AMD participe déjà activement au développement de pilotes Mesa comme le pilote OpenGL RadeonSI. Apprendre qu’AMD ne fera pas que redistribuer mais supportera officiellement le pilote Mesa RADV dans sa suite de pilotes permet d’espérer une contribution similaire à RADV. En d’autres termes, si un bug affecte RADV, ils pourront considérer qu’il est de leur responsabilité de le corriger dans RADV directement.

De plus, cela encourage désormais AMD à implémenter la prise en charge des futures cartes directement dans RADV avant que les cartes elles-mêmes ne soient mises sur le marché, ce qui était le principal argument en faveur d’AMDVLK-Pro et AMDVLK comparé à RADV.

Ainsi, si vous utilisez une carte AMD et quand bien même vous utiliseriez le pilote RADV fourni par votre distribution, vous profiterez des effets de ces travaux de maintenance d’AMD comme vous en profitez déjà pour RadeonSI.

C’est une très bonne nouvelle pour tout le monde car RADV est le pilote Vulkan installé par défaut (car faisant partie de la suite Mesa) par toutes les distributions Linux… et ce pilote devrait désormais profiter directement des efforts d’AMD.

Le départ des derniers

Il est important de noter que parce que ces pilotes en espace utilisateur sont écrits pour fonctionner par-dessus le pilote noyau amdgpu, il reste toujours possible d’utiliser ces pilotes désormais abandonnés, que ce soit OGLP, AMF et AMDVLK-Pro qui nous quittent désormais, ou les plus anciens PAL et ORCA, pour ceux qui recherchent un environnement spécifique tout en utilisant une distribution très récente. Et ce sera probablement encore vrai pendant des années, à condition de conserver votre ancien matériel compatible avec ces pilotes désormais obsolètes.

En réalité ça fait longtemps qu’il n’est plus nécessaire d’employer un logiciel propriétaire pour utiliser ses cartes graphiques AMD sous Linux. Toutes les API supportées par AMD avaient déjà des implémentations libres depuis longtemps.

Ce qu’AMD est en train de faire est de se débarrasser définitivement des rares alternatives propriétaires qui survivaient encore…

Adieu OGLP

OGLP était jusqu’à maintenant le pilote OpenGL propriétaire d’AMD sous Linux. AMD recommande le pilote libre Mesa RadeonSI pour OpenGL sous Linux depuis très longtemps. Le pilote libre Mesa RadeonSI lui est très supérieur, que ce soit en termes de fonctionnalité, de performance, et de qualité, et AMD contribue directement à ce pilote RadeonSI. Il est très probable que la majorité d’entre vous n’ait même pas connaissance que le pilote OGLP existait, ni même connaissait son nom.

OGLP proposait une implémentation OpenGL et OpenGL ES.

Mon expérience dans l’évaluation de pilotes graphiques pour le jeu Unvanquished m’a fait constater que le pilote OGLP présentait les mêmes bugs que le pilote propriétaire AMD pour Windows, Adrenalin. Il est donc extrêmement probable que c’était une simple recompilation du même pilote, mais pour Linux, comme à l’époque de Catalyst et fglrx.

En effet déjà à l’époque de fglrx pour ATI, et encore aujourd’hui pour Nvidia, les pilotes propriétaires graphiques de ces concepteurs de cartes graphiques sont généralement exactement le même pilote quel que soit le système, avec une couche de compatibilité pour le système, ce qui est logique dans une optique de réduction des coûts de développement.

OGLP était donc très certainement le pilote OpenGL de la suite fglrx, le pendant Linux du pilote Windows Adrenalin, mais porté pour le pilote noyau libre amdgpu au lieu du pilote fglrx abandonné il y a déjà des années.

On pourra s’étendre en conjectures sur pourquoi AMD maintenait encore le pilote OGLP jusqu’en 2025, il est probable que celui-ci répondait à des exigences contractuelles professionnelles. Sur le plan technique pendant longtemps le pilote Mesa s’était limité à implémenter seulement le « core profile » d’OpenGL et pas le « compatibility profile » qui pouvait être requis par certaines applications industrielles, et cela justifiait alors l’existence d’un pilote propriétaire pour satisfaire la clientèle. Mais Mesa a depuis implémenté ce « compatibility profile » et ce depuis longtemps désormais, il est donc possible que ne subsistait plus que des exigences contractuelles — peut-être même pas techniques — pour justifier la fourniture de ce pilote OGLP.

Adieu AMDVLK-Pro

Le pilote AMDVLK-Pro était en fait le pilote libre AMDVLK amalgamé de composants propriétaires.

Le pilote AMDVLK est un pilote libre qui implémente l’API graphique Vulkan.

Contrairement au pilote OpenGL officiel RadeonSI qui est développé en collaboration avec Mesa, le pilote Vulkan AMDVLK est développé exclusivement par AMD, mais c’est tout de même un pilote libre.

Au tout début AMDVLK était aussi un pilote propriétaire mais conçu dès le départ pour devenir un pilote libre plus tard, avec la promesse qu’il soit libéré un jour. Le pilote AMDVLK, alors qu’il était encore propriétaire, avait permis à beaucoup d’utilisateurs de Linux de profiter des fonctionnalités Vulkan de leurs cartes graphiques AMD sans avoir à attendre un pilote libre, que ce soit AMDVLK lui-même une fois libéré, ou le pilote RADV développé par Mesa.

Le pilote AMDVLK-Pro était donc en quelque sorte la continuité de ce pilote qui distribuait au plus tôt les fonctionnalités aux utilisateurs, en remettant à plus tard la libération de ces fonctionnalités. Quand AMDVLK avait été libéré, AMDVLK-Pro en était donc devenu la variante propriétaire qui implémentait et distribuait les dernières nouveautés.

Là encore, il est pertinent de supposer que le pilote AMDVLK est construit sur la même base de code que le pilote Windows. Quand bien même existe désormais le pilote Mesa RADV pour Linux, il est peu probable que le pilote libre AMDVLK disparaisse de l’écosystème Linux de si tôt.

Peut-être un jour AMDVLK, bien que libre, suivra le sort d’OGLP si un jour AMDVLK n’apportera rien de plus que RADV et ce depuis un temps certain ? L’avenir nous le dira.

Adieu AMF

AMF (Advanced Multimedia Framework) s’en ira également, c’est une bibliothèque d’accélération matérielle pour le décodage et l’encodage de formats vidéo. AMD recommande d’utiliser à la place l’implémentation VA-API de Mesa.

Souvenir des pilotes AMD abandonnés sur le bord du chemin

Parmi les pilotes AMD propriétaires conçus pour tourner sur le pilote noyau amdgpu, AMD a déjà abandonné ORCA et PAL. C’était des pilotes de calcul OpenCL (conçus pour les cartes GCN 2 à 4 pour ORCA, et GCN 5 pour PAL) qui ont été remplacés par ROCm.

On peut aussi supposer que PAL et ORCA étaient des portages du pilote OpenCL de Windows mais conçus pour tourner sur le pilote noyau amdgpu à la manière d’OGLP et d’AMDVLK.

Pour les plus pointilleux, PAL (Platform Abstraction Library) était en fait le nom de la bibliothèque d’abstraction entre le code propriétaire commun et le système Linux, et par métonymie on appelait PAL le pilote OpenCL qui utilise PAL comme interface. Dans la même veine, certains parlent parfois de ROCr OpenCL pour l’implémentation actuelle de OpenCL de la suite ROCm, ROCr étant le ROCm Runtime. Le nom ORCA n’échappe probablement pas à cette règle d’usage, mais je n’ai jamais trouvé d’explication de ce nom (je ne suis même pas sûr que ce soit un acronyme), la chaîne orca était simplement utilisée dans le nom du paquet (par exemple : opencl-orca-amdgpu-pro-icd).

PAL et ORCA ont longtemps été regrettés, car ils prenaient en charge la totalité des cartes de leurs générations, contrairement à ROCm. On peut lire à ce sujet sur LinuxFr.org l’article de 2022 « OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx ». Heureusement, Mesa fournit désormais RustiCL qui leur est désormais supérieur sur bien des points. Cela pourrait faire l’objet d’une dépêche à venir… 😉

Et avant cela, il y a bien longtemps avant de s’embarquer dans son aventure amdgpu, AMD fournissait la suite Catalyst entièrement propriétaire, qui exécutait au-dessus du pilote noyau propriétaire fglrx des pilotes propriétaires OpenGL et OpenCL pour le graphisme et le calcul.

Mais… et les firmwares ?

Les micrologiciels (firmwares) des cartes graphiques ne sont toujours pas libres, mais ceux-ci ne s’exécutent pas avec le système d’exploitation de votre ordinateur dans le processeur principal de votre machine, ils s’exécutent dans la carte graphique directement, c’est donc un tout autre sujet.

Certains réclament aussi la libération de ces micrologiciels, mais d’ici à ce que ce rêve devienne un jour réalité, si ce jour vient un jour, vous savez déjà que votre Linux, lui, il peut déjà prendre en charge toutes les fonctionnalités de votre carte avec des logiciels libres sous Linux.

Préférer le DisplayPort à l’HDMI pour les très hautes définitions…

Un petit couac cependant… Les pilotes AMD sous Linux ne peuvent légalement pas implémenter la version 2.1 du protocole HDMI, donc si vous avez besoin d’utiliser des définitions telles que le 4K à 120 Hz ou le 5K à 240 Hz, il faut privilégier le DisplayPort. Ce n’est pas la faute d’AMD : AMD avait en fait implémenté cette prise en charge mais n’a légalement pas le droit de la publier dans un pilote libre. Le HDMI Forum a restreint l'accès public aux spécifications en 2021, et publier cette partie du code du pilote serait contraire à ces nouvelles conditions. Ce code de prise en charge HDMI 2.1 est censé être implémenté dans le pilote noyau amdgpu, et AMD n’a aucune intention d’abandonner son pilote libre, alors que sa stratégie est précisément de tout libérer !

Prochain objectif : l’universalité du calcul et de la virtualisation ?

Enfin, je dis que « Linux peut déjà prendre en charge toutes les fonctionnalités de votre carte avec des logiciels libres » mais si vous souhaitez profiter de ROCm et GIM ce n’est vrai qu’à condition de bien choisir votre carte. 😬

AMD a la volonté d’améliorer la situation de ROCm, tel qu’en témoigne un sondage il y a quelque mois invitant les utilisateurs à exprimer leurs souhaits dans le cadre de l’effort d’AMD d’étendre la prise en charge. Mais ça prend du temps ! Et si, se faire attendre, c’est se faire désirer, il ne faudrait pas trop attendre pour AMD au risque que le désir se détourne vers d’autres propositions.

Et du côté de la virtualisation de carte graphique (GPU-IOV), le pilote GIM est libre aussi mais la situation est encore pire : il ne prend en charge que deux accélérateurs (ces produits n’ont pas de sortie vidéo)… Certains diront que c’est un progrès car la version précédente ne prenait en charge qu’un seul accélérateur… Il a été annoncé qu’une prise en charge matérielle plus large serait « sur la feuille de route » mais si ça prend le même temps que ROCm ou plus, il faudra se montrer très patient. 😄

En attendant, on peut célébrer cette victoire : La pile graphique d’AMD sous Linux est désormais complètement libre !

🥂🍾

Après une longue attente la version 0.55 du jeu Unvanquished a été publiée le 20 octobre 2024. Deux mises à jour mineures se sont succédées le 3 novembre et le 15 décembre pour peaufiner cette version, juste à temps pour être déposée sous le sapin de Noël !

Unvanquished est un jeu vidéo libre et gratuit mêlant stratégie en temps réel et actions à la première personne dans un univers futuristique où deux factions (humains, aliens) combattent pour leur survie.

S’inscrivant dans la continuité de Tremulous (révélé en 2006) et basé sur ce dernier, Unvanquished développe cette expérience de jeu nerveuse et exigeante depuis 2013, en améliorant continuellement le moteur et explorant des variantes et ajustements de jouabilité.

Laisse-moi goûter à cette version !

Sommaire

• Gameplay
• Bots
• Interface utilisateur
• Traductions
• Nouveaux visuels
• Fichier d’entité
• Le futur est lumineux
• Corrections du moteur de rendu
• Performance améliorées
• Bien entendu que ça fait tourner Unvanquished !
• Nouveaux joujoux
• À venir
• Il est temps de jouer !

Cette version avait été promise dans le dernier article Des nouvelles de Unvanquished, et 10 mois après la version 0.54, voici la version 0.55.

Pendant cette année 2024, le jeu a fait l’objet d’un développement soutenu et vu l’arrivée de nouveaux contributeurs.

Gameplay

• La portée du « rocket pod » a été réduite: 2000qu → 1300qu (62m → 40m).
• Il n’est plus possible de désévoluer vers la même classe, ce qui permettait de recharger ses projectiles sans attendre.

Bots

• Les bots aliens savent désormais éteindre les bases en feu.
• Ils peuvent aussi utiliser le granger avancé pour atteindre des plate-formes élevées et y construire.
• Les classes sachant marcher sur les murs le font de manière plus fiable, et le saut de mur du maraudeur est plus précis lorsqu’il escalade des murs.

D’autres améliorations sont plus subtiles, les bots peuvent naviguer dans les cartes de façon plus efficace depuis que la taille des tuiles du maillage de navigation est configurable. Les mappers (ceux qui créent ou modifient des cartes) peuvent aussi configurer d’autres aspects de la navigation.

Un déséquilibre qui rendait les bots aliens moins bons que les bots humains a été retravaillé.

La navigation dans la carte perseus a été améliorée. C’est un des patchs de la mise à jour mineure 0.55.1, c’était déjà prêt pour la 0.55 mais avait été oublié (oups !).

La 0.55.2 a donné aux bots la capacité de voler et la capacité de danser autour des ravins sans tomber.

Interface utilisateur

Il est désormais possible de se déplacer et d’utiliser certaines touches d’action alors que certains menus circulaires sont ouverts : évolution, construction, balises (beacons). Cela permet d’ouvrir le menu de construction en tant que granger avancé sans tomber. On peut aussi évoluer tout en courant ou en sautant, etc.

Les nouveaux menus avec les options de réticules.

Traductions

La version 0.55 est la première version majeure d’Unvanquished à distribuer de nouveau des traductions ! Nous avions déjà distribué quelques traductions avec la version de correction 0.54.1, elles étaient en quelques sorte en prévisualisation. Cette version apporte les traductions pour le Français, l’Allemand, l’Italien, l’Espagnol, le Finlandais, deux variantes de Portugais, et trois variantes de Chinois.

Dans les premiers jours d’Unvanquished nous avions des traductions, mais il y a longtemps nous avons changé la technologie utilisée pour implémenter l’interface utilisateur et la prise en charge des traductions a dû être réimplémentée. Les voici de retour et nous sommes heureux de vous les distribuer de nouveau. Pour contribuer plus de traductions et les affiner, le mieux est de le faire sur Weblate.

Nouveaux visuels

De nouveaux modèles sont là : la « painsaw » d’Alex Tikkoiev et le Chaingun d’extreazz. Ils ont été intégrés au jeu par Ishq. Cela semble simple à faire mais nous n’avons pas de modeleur ni d’animateur actif et cela nous freine beaucoup, vous pouvez nous rejoindre.

Le nouveau chaingun d’extreazz.

La painsaw produit désormais des étincelles quand elle impacte des surfaces dures, agissant comme le Grand Communicateur de vos désirs de disperser des tripes extra-terrestres.

La nouvelle painsaw d’Alex Tikkoiev.

Il y a dix ans nous avons reçu une fonctionnalité bien sympathique appelée particules douces (soft particles). Cela empêche certains effets comme le brouillard ou les nuages d’acides d’être affichés de manière disgracieuse lorsqu’ils touchent des murs. Initialement l’effet n’était configuré que pour une poignée de shaders. Rapidement des programmeurs paresseux se sont dits : « configurer les shaders est ennuyeux, et si nous activions la fonctionnalité pour toutes les particules ? ». Malheureusement, cela rend certaines particules invisibles, spécialement les effets d’impacts qui sont très proches de murs ou de sols. Apparemment personne n’a remarqué ça pendant 9 ans, jusqu’à ce que nous retournions à la configuration manuelle de shaders à cause de changements architecturaux liés à autosprite2. Après une revue méticuleuse de tous les systèmes de particules du jeu, nous avons corrigé, retiré ou amélioré certains effets graphiques. Par exemple le souffle du canon lucifer produit désormais une onde de choc, causant une distorsion visuelle. Un tel effet était déjà présent dans les données, mais il ne fonctionnait pas à cause d’un problème de tri des shaders. Le tir secondaire produit aussi un flash violacé à l’impact, effet qui était souvent invisible à cause des particules douces automatiques.

Le nouvel effet de soin de la médistation.

Reaper a repensé l’effet de soin de la medistation et l’a rendue plus transparente, pour que les joueurs en cours de soin puissent voir à travers.

Sweet a ajouté un nouvel effet visuel au champ de force de la carte plat23. Cela utilise l’effet de mirage de chaleur (heat haze) qui était initialement conçu pour les armes et les effets de feu, mais il se trouve que ça peut également produire des effets très sympathiques dans les cartes. Nous remercions Masmblr pour la manière dont il nous fait avancer en démontrant dans ses propres cartes communautaires comment il est possible d’exploiter de façon créative et nouvelle des fonctionnalités que nous proposons déjà !

Fichier d’entité

Le moteur prend désormais en charge les fichiers d’entité. Cela est particulièrement utile pour les cartes (niveaux de jeu) sans source (il y en a des centaines !). Un fichier d’entité permet certaines personnalisations de comment certaines entités fonctionnent (portes, ascenseurs, téléporteurs…). Il est possible d’extraire une description d’entités avec q3map2 et le fichier extrait peut être édité avec un éditeur de texte et lu par le moteur lorsqu’il charge une carte. Le fichier d’entité peut aussi être utilisé pour modifier comment la lumière d’une carte sera appliquée (il est possible d’y renseigner des variables qui configurent le moteur de rendu pour cette carte).

Le futur est lumineux

Une vidéo démontrant la compatibilité des lumières de diverses cartes historiques (voir la vidéo complète).

Un effort aux long cours est fait pour que le moteur affiche de meilleures lumières en jeu. Les investigations ont commencé à livrer des résultats significatifs en 2020 avec l’affinage du procédé de compilation des lumières. Cet effort est multi-facettes et touche à de multiples aspects de la chaîne de production et de rendu. Ces dernières années, Illwieckz s’est assuré que différents types d’éclairage soient pris en charge. L’éclairage par vertex (vertex lighting) a été ajouté en plus de l’éclairage par grille (grid lighting) et de l’éclairage par texture (lightmap). Ainsi les cartes qui mélangent éclairage par vertex et éclairage par texture sont désormais correctement affichées. Illwieckz a aussi débuggué les styles de lumières, une sorte de lumière dynamique pré-calculée qui fusionne plusieurs textures de lumière (lightmap) au moment du rendu.

Comparaison entre l'ancien suréclairage (à gauche) et le nouveau suréclairage (à droite). Comparer avec un curseur.

Après cela Illwieckz a réimplémenté le mécanisme de suréclairage (overbright) pour éviter la troncature des lumières (light clamping). Il se trouve que le moteur de rendu de Quake 3 souffrait d’une limitation qui atténuait les lumières autant qu’il les éclaircissait… Le nouveau code non-buggé est désormais activé par défaut. Cela a suscité des débats puisque comme le moteur id Tech 3 avait un suréclairage buggé depuis plus de 20 ans, utiliser un moteur de rendu non-buggé peut révéler des bugs que les créateurs de niveaux n’ont jamais vu avant, et il était même possible d’introduire des bugs dans certains logiciels de production sans que les gens ne s’en rendent compte ! Certaines personnes peuvent argumenter que l’affichage buggé est la façon dont le créateur du niveau s’attend à ce que son niveau soit vu… Cette histoire va si loin que cela mériterait un article dédié !

La prochaine étape sur ce chemin vers un meilleur éclairage sera de faire de la colorimétrie correctement et de faire de la fusion linéaire de lumière (quelque chose qu’id Tech 3 n’a jamais fait), mais cette tâche est pour le futur.

Corrections du moteur de rendu

Une vidéo montrant la récursion de miroirs et de portails et leur fusion (voir la vidéo complète).

• Sprites : Les surfaces utilisant le mot clé de shader autosprite2 sont correctement affichées, c’est parfois utilisé pour afficher des effets de symétrie axiale, par exemple pour une flamme de bougie. Ce travail a été réalisé par Slipher.
• Portails et miroirs : Reaper a terminé l’implémentation de la récursion de portail et de miroir, a implémenté la fusion de portails et la fusion alphaGen (une technique qui permet d’obscurcir un portail selon la distance à celui-ci), et a rendu possible d’avoir des portails mobiles. Il a corrigé la rotation de portail ainsi que des bugs de portails liés aux lumières, et s’est assuré que du creep extra-terrestre de taille 10 millions de fois la taille de l’univers observable n’apparaissent pas dans les portails…
• Vidéo : Nous pouvons à nouveau jouer des vidéos sur les surfaces. Avec le temps le code s’était gâté (rotten code), était devenu cassé et avait même été enlevé tandis qu’il était cassé. Il fut ressuscité et a fait l’objet d’une profonde réécriture par Slipher, et la fonctionnalité fonctionne de nouveau — et même mieux qu’avant (avec moins de limites arbitraires) ! Cette nouvelle implémentation était déjà visible dans la version 0.54.1, la voici désormais dans une version majeure. Le seul format pris en charge est l’antique format RoQ utilisé par Quake 3 qui, par mesure de compatibilité avec les données de jeu existantes, est le codec que nous devons prendre en charge avant tout autre codec. Nous ne fermons pas la porte au fait de prendre en charge d’autres codecs, mais pour cela il faudrait que la fonctionnalité soit utilisée plus souvent pour justifier cet effort supplémentaire.
• Brouillard : Reaper a corrigé l’effet de brouillard, qui était cassé dans la version 0.45. Oups !
• Lumières : Les lumières dynamiques sont désormais moins pixelisées, quand bien même ce problème n’est pas encore complètement corrigé.
• PBR : La prise en charge de textures prétendues « basées sur la physique » est désormais dans un état viable grâce à Ishq (plus d’artefacts noirs). C’est déjà utilisé avec un nouveau modèle de chaingun. Pour le rendre bon, nous avons besoin de le faire fonctionner avec les réflexions spéculaires (réflexions statiques).

Une vidéo montrant la lecture de vidéo sur les surfaces du jeu (voir la vidéo complète).

En corrigeant le shader autosprite2, la fusion de portails et la lecture de vidéos, nous avons corrigé 3 régressions du moteur original de Quake 3 et qui étaient liées à la prise en charge de format de fichiers anciens et de techniques tout aussi anciennes. Parce que notre moteur de rendu n’est plus celui de Quake 3, corriger certaines de ces régressions requiert parfois d’écrire du code neuf plutôt que de corriger un code existant, et c’est exactement ce qui s’est produit pour les portails.

Performance améliorées

Unvanquished 0.55.2 a été publiée pour Noël !

Le moteur et le jeu sont plus rapides que jamais !

• Simplification du ciel : Reaper a purifié par le feu le code de rendu du ciel qui était archaïque et… étrange. Ce code pouvait générer plus de 1000 triangles par trame rien que pour dessiner le ciel. Une skybox n’a pas besoin d’une géométrie aussi fine, elle est simplement modélisée comme l’intérieur d’un cube. En plus le code faisait des allers-retours mémoire entre la mémoire principale et la mémoire graphique… 🤦‍♂️️ Nous dessinons donc le ciel maintenant avec seulement 12 triangles. Inutile de dire que les performances sont significativement améliorées, et ça aurait toujours dû être comme ça.
• Culling : Il s’agit du procédé qui élague les surfaces non-visibles pour éviter de les dessiner. Illwieckz a optimisé l’implémentation générique pour processeur central (CPU), Slipher a ciselé à la main un code SSE pour les processeurs x86, et Reaper a permis d’utiliser la carte graphique (GPU) quand le pilote et le matériel sont compatibles.
• Réduction des délais IPC par du traitement par lots et de la mise en cache : Ces travaux accélèrent des choses comme les particules, les marques d’impact, et les ombres. Illwieckz a réduit le temps d’attente pour ces communications interprocessus en ajoutant des alternatives à nos interfaces de programmation (API) qui fonctionnent par lot. L’IPC est comme un service postal qui transporte les messages entre le processus du jeu Unvanquished et le moteur Dæmon. Pour un facteur, l’important n’est pas le nombre de pages que vous écrivez mais le nombre d’enveloppes à livrer. Vous pouvez donc alléger sa charge de travail en mettant toutes vos lettres dans une seule grande enveloppe. Pour un cas d’utilisation (déjà livrée dans la version 0.54.1), Slipher a implémenté une mise en cache côté code de jeu. Pour filer la métaphore, il n’est pas nécessaire de ré-envoyer le même courrier si le contenu est déjà connu. Sur du matériel actuel, ces optimisations peuvent augmenter le taux de trame (framerate) de plusieurs centaines de FPS quand il y a de nombreuses particules et autres choses de ce genre à l’écran (spam de grenade incendiaires, par exemple !).
• Code de vertex flottant plus rapide : L’implémentation de vertex plein-flottant écrite par Slipher pour étendre la compatibilité à du matériel plus ancien ou de plus basse gamme qui ne prennent pas en charge les demi-flottants a aussi doublé le taux de rafraïchissement sur du matériel qui fonctionnait déjà ! La réécriture a aussi apporté de menues optimisations dans le code de modèles.
• Placage de relief : Reaper a corrigé un bug dans le code des cartes de relief (relief mapping), ce qui a débloqué quelques centaines de FPS sur des cartes graphiques de génération actuelle.
• Usage mémoire des images : Illwieckz a implémenté le mécanisme fitScreen pour les textures d’interfaces utilisateur : c’est une alternative à l’antique implémentation noPicMip de Quake 3 : noPicMip instruisait le moteur de ne jamais réduire la taille d’une image, fitScreen s’assure qu’elle soit réduite d’une façon qu’elle ne devienne jamais plus large que l’écran. Par exemple une capture d’écran d’une carte (niveau) utilisée dans la liste des cartes et au chargement d’une carte ne sera plus jamais chargée en pleine résolution dans la mémoire graphique si elle doit être affichée sur un écran 640×480 (pour donner un exemple extrême)… Combiné avec le mécanisme r_maxImageDimension que nous avons ajouté en version 0.52 pour les textures qui ne sont pas utilisées pour les interfaces utilisateurs comme alternative à r_picmip, ce nouveau mécanisme donne au jeu une empreinte mémoire en VRAM très très faible quand on utilise un écran avec une résolution toute petite.
• Plus de pré-calcul : De nombreuses décisions étaient préalablement prises à chaque trame en rendant telle ou telle surface, Illwieckz s’est assuré que ces décisions soient désormais prises une fois pour toute lorsque le shader est parsé. Ce que nous appelons « shader » ici est un format de définition de matériaux utilisé par id Tech 3 et ses dérivés, ainsi que de nombreux outils d’édition de cartes. Ne pas confondre avec un « shader GLSL » qui est un programme exécuté sur la carte graphique.
• SSAO : Le shader GLSL SSAO (Screen Space Ambient Occlusion) a été rendu un peu plus rapide par Reaper.

Le moteur et le jeu ont été profilés intensivement par Illwieckz en utilisant Orbit. Cet effort a permis d’identifier des goulots d’étranglement (bottleneck) et du code non-optimal. Au final cela nous a aidé à implémenter de nombreuses optimisations à de nombreux endroits dans le code.

Le chargement de carte a aussi été amélioré de plusieurs façons :

• Le moteur ne calcule plus la somme de contrôle des images CRN au chargement.
• Le moteur ne compile plus certains shaders GLSL qui sont détectés comme inutilisés.
• De la même façon nous avons réduit le nombre de permutations de shader GLSL à compiler.
• Les joueurs qui aiment jouer seul apprécieront notre génération « multithread » de maillage de navigation de bot (bot navigation mesh), grâce à Ishq et Slipher. Cela fait partie de la phase de chargement lorsque vous jouez une carte pour la première fois dans un jeu local. Cette génération n’utilisait avant qu’un seul fil d’exécution (thread), désormais toute la puissante de votre processeur est exploitée en mettant tous les cœurs à contribution. Les hébergeurs de serveurs peuvent également en profiter et peuvent configurer cette fonctionnalité avec la variable g_bot_navgenMaxThreads (utiliser moins de fils utilise moins de mémoire, ce qui peut être préféré sur certains serveurs).

Il y a aussi tout un ensemble de choses qui n’ont pas de lien avec le moteur de rendu qui rendent le jeu plus rapide :

• Le préréglage « le plus bas » (lowest) pour les appareils de très bas de gamme a été optimisé encore plus.
• Nous distribuons des modèles optionnels en faible qualité – pour le moment seulement pour les constructions, avec la seule différence que ces modèles ont moins d’articulations. Cela permet de traiter l’animation de ces modèles sur des GPUs plus bas de gamme (au lieu de basculer sur le code CPUs quand le GPU est trop bas de gamme).
• Il a été découvert que certaines variables de configuration (cvar) étaient utilisées par le code de jeu pour envoyer des informations à l’interface du code du jeu dans le but de les afficher à l’écran. Cela signifie que le jeu s’envoyait une lettre à lui-même à travers le moteur à chaque trame… En fait cela demandait même deux lettres : une pour envoyer la donnée au moteur, une pour la récupérer depuis le moteur, tout ça pour une donnée déjà connue ! Cette horreur a été atomisée avec un préjudice extrême.
• L’accès à une cvar de jeu par son nom depuis le jeu utilise désormais un cache local, réduisant encore le nombre de messages que le jeu et le moteur doivent échanger, accélérant de beaucoup l’interface utilisateur.

Ceux qui aiment faire tourner des benchmarks seront heureux d’apprendre que le taux de trame de la fonctionnalité timedemo n’est plus plafonné à 999 fps.

De plus, l’interface Curses peut désormais afficher les FPS.

Bien entendu que ça fait tourner Unvanquished !

Toujours du côté du moteur de rendu, l’exigence minimale est désormais OpenGL 2.1 sans extension spéciale. Cela signifie que le matériel le plus limité qui puisse faire tourner Unvanquished inclue les ATI R300, les Intel GMA 3 et 4 (sous Linux) et les Nvidia NV40. Parfois même un OpenGL 2.1 incomplet pourrait suffire !

Votre carte graphique est prise en charge. Si cela ne fonctionne pas alors qu’elle est censée prendre en charge OpenGL 2.1 (ou plus), c’est très probablement un bug de pilote.

Par exemple même le VC4 du Raspberry Pi 3B+ peut soutenir 60 fps avec la préconfiguration la plus basse (lowest) et une résolution faible. Cependant le pilote a encore besoin d’être amélioré pour être compatible avec tous les niveaux jouables.

Un Raspberry Pi 3B+ dessinant la carte plat23 à 60 fps avec le préréglage « le plus bas »…

Jouer à Unvanquished sur un RPI3 n’est vraiment pas recommandé (la mémoire vive disponible sera aussi très limitante), mais si un RPI3 arrive à tenir le rang, c’est que le jeu tourne sur vraiment n’importe quoi, y compris sur un topinambour (parce que même une patate ça serait du luxe 🤭️).

Voici quelques optimisations qui ont été faites pour étendre la compatibilité du moteur :

• L’extension GL_ARB_half_float_vertex n’est plus requise. Cela s’ajoute au fait que l’extension GL_ARB_framebuffer_object n’est plus non-plus requise depuis la version 0.54 pour être compatible avec plus de matériel. La réécriture faite par Slipher pour prendre en charge à la fois les vertex demi-flottants ou les vertex plein-flottants a même amélioré les performances du moteur (code plus concis, code plus performant, et qui permet plus de chose… tout ça à la fois) !
• Les textures 3D ne sont plus requises. C’est quelque chose qui est obligatoire en OpenGL 2.1, mais le moteur peut faire sans lorsque l’implémentation est incomplète. De telles implémentations incomplètes peuvent être trouvées avec certaines puces graphiques embarquées conçues pour OpenGL ES, et Mesa se permet de fournir « autant qu’il peut » d’OpenGL pour faire fonctionner les compositeur de bureau. Le moteur Dæmon sait désormais se satisfaire lui-aussi d’une telle implémentation incomplète.
• Une collection de codes de détection a été implémentée pour identifier des pilotes buggés ou lent, ainsi que des matériels lents. Quand c’est possible, un code moins buggé ou plus rapide est activé lors de l’exécution. Par exemple lors de ce cycle de développement nous avons mis le pied dans ce que les développeurs Intel caractérisent comme un défaut matériel de l’architecture Iris (l’actuelle…), et ont suggéré un contournement qui limite les défauts visuels la plupart du temps. Il y a quelques années nous avions identifié que le dernier pilote Nvidia pour toute une génération de carte donnée ment sur la présence d’une extension, et plante si on tente de s’en servir, et ne sera jamais mis à jour… donc depuis un moment déjà on le détecte pour corriger ses prétentions. Il y a aussi une génération de vieilles cartes ATI qui sont plus rapides en flottants qu’en demi-flottant (la prise en charge annoncée par le pilote est très probablement une émulation pour permettre de faire fonctionner d’autres logiciels qui n’ont pas d’implémentation alternative), donc on détecte et on utilise le code le plus adapté à cette architecture. Il y a d’autres types de contournements mais ces trois-là sont représentatifs. Nous avions déjà quelques-uns de ces contournements implémentés (comme celui pour certaines Nvidia), mais désormais nous avons un procédé standardisé pour implémenter de tels contournements et pour pouvoir les désactiver (pour que les fabricants de matériel et/ou développeurs de pilotes puissent reproduire les bugs, par exemple).

Bien sûr toutes les améliorations de la vitesse d’exécution ont étendu la compatibilité en transformant des équipements « capable de faire le rendu » en « quelque chose avec lequel on peut jouer ».

Nous avons aussi ajouté la possibilité de compiler et exécuter un moteur Dæmon natif sur FreeBSD. Les binaires NaCl exécutés dans le bac à sable tournent toujours dans le mode de compatibilité Linux, mais le moteur peut désormais être natif FreeBSD. Une telle astuce doit probablement être utilisable sur d’autres systèmes qui ont une compatibilité Linux intégrée (NetBSD par exemple, mais nous n’avons pas testé), en utilisant un binaire natif pour le moteur et la compatibilité Linux pour la machine virtuelle du code du jeu.

Un point que nous aimerions améliorer dans le futur au niveau du moteur est l’utilisation mémoire.

Nouveaux joujoux

Remarquez les reflets sur les tuyaux !

Placage de reflet (très expérimental) : Tandis que notre moteur de rendu progresse, les reflets statiques qui étaient complètement cassés sont désormais en meilleur état. Une fois activés, vous pourrez apercevoir votre environnement dans les matériaux réfléchissants, comme des tuyaux métalliques, des plastiques brillants, et des surfaces excessivement polies… Puisque cela est statique, seule la géométrie stationnaire de la carte est pour le moment reflétée, bien que cela soit suffisamment subtil pour que les différences ne soient pas trop évidentes, surtout au beau milieu de l’action. En outre, les données de reflets sont enregistrées et chargées depuis le disque quand vous activez la mise en cache dans les options. Le code du moteur en charge de sélectionner les reflets pour chaque surface a aussi été amélioré, apportant des reflets plus corrects et de grandes améliorations de performance.

Système de matériaux (très expérimental) : Une autre étape vers la modernisation du moteur est l’ajout d’un système de matériaux. Lorsque le matériel et les pilotes sont compatibles, cela déplace de nombreuses tâches de rendu depuis le CPU vers le GPU, produisant ainsi un flux de travail centré sur le GPU. Bien que cela ajoute un peu plus de travail au GPU, cela élimine une forte pression mise sur le CPU, ainsi que de nombreux aller-retours entre le moteur et le pilote et entre le CPU et le GPU. Sur les cartes les plus exigeantes pour le CPU (en particulier celles avec un “vis” mauvais, le vis est une représentation de la carte générée par le compilateur de carte qui détermine quelle partie devrait être visible selon le point de vue) cela peut doubler le taux de trame comparé au moteur de base. Ce système est encore incomplet et de nombreuses améliorations sont à venir.

Reaper est celui qui se cache derrière la réalisation de ces chantiers impressionnants.

Pour pouvoir en profiter il vous sera nécessaire d’avoir OpenGL 4.6 et (en plus) l’extension GL_ARB_bindless_texture. Il reste cependant des problèmes avec certains matériels et pilotes : tout devrait fonctionner avec Nvidia, le système de matériaux et le « frustum culling » devraient fonctionner avec Mesa (radeonsi pour AMD, etc.) quand la dernière version de Mesa est utilisée (l’ « occlusion culling » ne fonctionne pas encore et pourrait planter avec un Mesa qui ne vient pas de la branche de développement main…). Cela ne fonctionne pas avec le pilote propriétaire AMD à cause de bugs. Des contournements pour ces problèmes sont planifiés, mais tous n’ont pas été implémentés à temps pour la sortie de cette version.

À venir

Parmis les développements qui sont déjà testables sur certains serveurs et qui seront disponibles dans la prochaine version, il y a le mode « vampire », qui est un mode alternatif de gestion des ressources : plutôt que de miner du point de construction, chaque équipe se voit dotée d’un lot déterminé de points en début de partie et lorsqu’une équipe détruit une construction adverse elle s’approprie les points de construction associées. Ce mode « vampire » est évalué comme une solution potentielle au problème de certaines parties qui sont trop longues ou semblent bloquées avec des équipes trop bien fortifiées de chaque côté. Ce mode de jeu peut être testé en avant-première sur des serveurs comme Map&Bot Testing, Der Bunker, ou Bug Squash Central.

Il est temps de jouer !

Le jeu Unvanquished se télécharge ici et les parties en cours sont listées ici !

La dernière dépêche sur le jeu Unvanquished a été publiée ici en 2023, pour son dixième anniversaire. La dernière version annoncée ici était la version 0.53, en 2022. Alors que nous sommes à deux mois de 2025 et à quelques jours de la prochaine version 0.55, c’est l’occasion de faire un point sur ce qui s’est passé ces dernières années et d’ajouter un épisode à la série « des nouvelles de [votre jeu préféré] » et de faire suite à celui sur Xonotic.

Laisse-moi sortir de là ! — réclame la version 0.55…

Unvanquished est un jeu de stratégie en temps réel (RTS) à la première personne (FPS) où des extraterrestres évolutifs et des humains lourdement armés s’affrontent pour leur survie. Son développement, basé sur Tremulous, a commencé en 2011.

Sommaire

• Quelques nouvelles en vrac
  • Un nouveau lanceur
  • Des améliorations graphiques
  • Un explorateur de serveur minimaliste
  • Des vidéos et un compte Mastodon
• Unvanquished, ARMé et dangereux
  • De nouvelles architectures
  • Interface, jouabilité et bots
  • La danse des submodules
  • Contributions
  • Des traductions !
• La 0.55 arrive !

Quelques nouvelles en vrac

Un nouveau lanceur

En prévision de la prochaine version 0.55 qui arrive (deux « release candidates » ont déjà été publiées), le « lanceur » (aussi appelé « updater ») a été mis à jour en juillet dernier.

Le lanceur est le moyen recommandé d’installer Unvanquished : il permet une intégration optimale avec le système (possibilité de cliquer sur des liens pour lancer une partie) et propose la mise à jour du jeu quand une nouvelle version est disponible. Le lanceur sait aussi se mettre à jour et c’est ce qui a été fait en juillet.

Des améliorations graphiques

L’année dernière le projet Unvanquished avait annoncé être en recherche d’un développeur spécialisé dans les moteurs de rendus. Reaper a rejoint l’équipe et a réalisé un gros travail : débugage et finalisation des miroirs récursifs et d’autres choses. Il fait aussi progresser le moteur pour tirer partie d’OpenGL 4.6 et autre techniques avancées (« bindless textures », etc.).

Un explorateur de serveur minimaliste

Viech a publié un explorateur de serveur de jeu minimaliste qui tient dans la barre de notification (tray browser). C’est à la fois simple et pratique.

Des vidéos et un compte Mastodon

Diverses vidéo montrant les avancées du développement ont été publiées sur la chaîne Youtube d’Unvanquished, c’est l’occasion de rappeler l’existence de cette chaîne : https://www.youtube.com/@UNVofficial

Pour ceux qui préfèrent Peertube, qui permet aussi de s’abonner aux chaînes à travers Mastodon et plus globalement le Fédiverse, avec la publication de certaines parties : https://vdo.unvanquished.greboca.com/

Un compte Mastodon a été créé sur l’instance idtech.space dédiée aux technologies id Tech et projets associés (le moteur d’Unvanquished dérive d’id Tech 3) : https://idtech.space/users/UNVofficial

Ce compte Mastodon s’ajoute aux comptes X et Facebook. Le public libriste sera peut-être plus intéressé par ce compte Mastodon.

Unvanquished, ARMé et dangereux

De nouvelles architectures

La version 0.54 de Unvanquished sortie en janvier 2023 avait été la première à être jouable autrement que sur PC (x86 et x86-64), en proposant des binaires pour les processeurs ARM (sous Linux seulement pour l’instant).

Côté moteur la version 0.54 avait reçu de nombreuses optimisations pour mieux tourner sur des machines moins performances, par exemple, Certaines ressources logiciels optionnelles comme les deluxemaps ne sont plus chargées si désactivées, ceci économise non seulement le calcul, mais aussi la mémoire de la carte graphique. Les lightstyles peuvent être désactivés, ce qui peut accélérer le rendu graphique, etc. La compatibilité matérielle sera encore étendue avec la version 0.55.

À partir de la version 0.54 tous les binaires pour toutes les architectures matérielles et systèmes d’exploitation sont compilés dans des containers Docker, y compris les binaires macOS compilés dans un container Linux en utilisant Darling, Darling étant à macOS ce que Wine est à Windows. La version 0.55 sera produite de la même manière.

La version 0.55 apportera la compatibilité pour un nouveau système d’exploitation ! 🤫️

Interface, jouabilité et bots

Le nouvel écran de chargement des cartes.

L’interface avait été revue à l’occasion de la version 0.54 :

• Nouvelles icônes d’inventaire contribuées par Nanaa, Gireen et Bob Vador
  Ces icônes donnent un coup de fraîcheur, on distingue mieux les deux types de grenades et les armures ainsi que le mode de déplacement.
• L’écran de chargement des cartes affiche le nom de la carte et des auteurs (si renseigné) depuis les métadonnées. Historiquement, les artistes inscrivaient ces informations sur l’image d’illustration de la carte avec un logiciel de dessin… (!!!)
• La version 0.55 apportera des modifications d’interface réalisées par Grise.

Côté jouabilité, la version 0.54 avait corrigé le momentum négatif qui était particulièrement pénalisant. Le momentum, est généré par les Leech (Alien) ou les Drills (Humain). Il faut qu’il y ait assez de momentum pour pouvoir construire d’autres éléments.

La version 0.54 a apporté toute une série de nouveautés au niveau des bots (entités qui remplacent les joueurs afin de compléter les équipes) :

• Amélioration de l’évitement d’obstacles pour les bots.
• Les bots peuvent viser des cibles situées sur des navmesh différents.
• Certains bots n’hésiteront pas à sauter pour atteindre une cible en hauteur, d’autres se retiennent d’exécuter une attaque qui pourraient les blesser si la cible est trop proche…

Depuis quelque temps, le développement des bots suscite un regain d’intérêt. La version 0.55 ne sera pas la plus riche à ce sujet car elle apportera surtout des améliorations du moteur. Le développement de gameplay ne s’est pas ralenti mais s’est surtout focalisé sur des mods dont il faudra fusionner les avancées dans le tronc commun après la sortie de la version 0.55. Ces améliorations de gameplay sont déjà jouables sur des serveurs en ligne.

L’amélioration du comportement des bots à permis un nouveau type de jeu : Le PVE. C’est à dire que les joueurs peuvent jouer ensemble contre l’ennemi piloté par le serveur. Certaines cartes ont été créées spécifiquement pour ce type de jeu, et d’autres ont été adaptées à l’aide de layout qui étaient déjà utilisés pour créer des variantes de parties.

La version 0.54.1 n’avait pas vraiment proposé de modifications des données, il s’agissait surtout de publier des correctifs de bugs gênant du moteur. La version 0.55 viendra avec une mise à jour des données et donc avec les corrections attendues. Par exemple un bug dans la chaîne logicielle de conversion d’images avait produit des artefacts dans certaines textures, ce sera corrigé dans la version 0.55.

La danse des submodules

            _________________
           /                 \
          |         ✝         |  
          |                   |
          |      beloved      |
          |     submodule     |
          |                   |
          |    2017-12-30     |
          |     2023-04-11    |
          |                   |
          |       R.I.P.      |
          |                   |  🄵
  (,,)é   |                   |   ɘ̀(⹁⹁)  ɘ̀(⹁⹁)
////////////////////////////////////////////////

Press F to Pay Respects!

Tous ceux qui doivent traiter avec Git savent que les submodules sont très pratiques mais parfois bien ennuyeux. Un travail de fond réalisé sur les outils de production des données a permis la réintégration du dossier source unvanquished_src.dpkdir. Le générateur de code CBSE qui produit la plomberie pour la logique de jeu a été réintégré aussi. Cela rend plus facile de travailler sur des mods en évitant de devoir gérer plusieurs dépôts différents.

Contributions

Voulez-vous en savoir plus ?

Comme vous le voyez, ce cycle de développement a aussi vu de nouveaux contributeurs apporter leur concours au projet. Certaines de leurs améliorations ont déjà été publiées dans la version mineure 0.54.1, d’autres arriveront avec la version 0.55.

Récement, le développeur Slipher qui est un des développeurs Unvanquished les plus prolifiques et les plus fidèles a étendu ses activités au moteur de rendu et a rejoint la petite élite de ceux qui savent comment le moteur fonctionne. Il a corrigé entre autre le rendu de vidéo sur des surfaces et une fonctionnalité de sprites.

La liste de régressions depuis le désormais lointain ancêtre d’Unvanquished, Tremulous, est maintenant réduite à peau de chagrin.

Des traductions !

La grosse nouveauté de la version 0.54.1 publiée en décembre 2023 a été de proposer à nouveau des traductions intégrées au jeu. L’outil de traduction est gracieuseuement hébergé par Weblate.

L’interface de traduction Weblate.

Il y a longtemps, le jeu était traduit, mais suite à de très profonds changements (par exemple le remplacement total de la technologie utilisée pour faire des menus, désormais sous RmlUi), l’effort de traduction avait été interrompu.

La traduction francophone est bien avancée, mais la traduction en breton a besoin de plus de contributions. Si vous souhaitez contribuer votre langue régionale, vous êtes les bienvenus, c’est ici que cela se passe !

La 0.55 arrive !

Préparez votre souris et votre clavier, la version 0.55 arrive très bientôt.

Ces 3 et 4 février 2024 ont lieu à Bruxelles le FOSDEM, Free and Open Source Software Developers' European Meeting ou Réunion européenne des développeurs de logiciels libres et open source, une conférence ayant lieu tous les ans à l’Université Libre de Bruxelles (la bien nommée) depuis 2001.

Lors de l’édition 2023 du FOSDEM j’avais lu ce Tweet sur le réseau social qui s’appelait encore Twitter:

 Plus de 20 [ans] que l’ULB accueille le #FOSDEM, évènements majeurs de la communauté opensource.
Mais ce n’est pas assez « tape à l'œil » pour qu’un média belge en parle un peu ;(

Ce compte était publié par le compte Bad Service Belgium qui se spécialise dans le partage d’expérience de mauvais service en Belgique.

Ça tombe bien, quand bien même LinuxFr.org n’est peut-être pas un « média belge », j’y étais en 2023, et à l’occasion de l’édition 2024 du FOSDEM je vous propose donc une présentation de ce rassemblement incontournable, illustrée de mes photos de l’année dernière.

Sommaire

• De la difficulté de voir les événements liés aux logiciels libres être couverts par la Presse
• Mais qu’est-ce que le FOSDEM ?
• Un évènement populaire
• Les conférences
• Suivre les conférences en ligne
• Les stands
• Les visiteurs
• Où est la Presse ?
• À propos des photos

De la difficulté de voir les événements liés aux logiciels libres être couverts par la Presse

Le constat de Bad Service Belgium ne s’applique pas seulement à la Belgique.

En décembre dernier Stéphane Bortzmeyer a partagé dans la rubrique liens de LinuxFr.org la conférence de Loris Guémart intitulée « Les journalistes se moquent des logiciels libres, je vous explique pourquoi ». Cette conférence avait eu lieu lors du Forum PHP organisé par l’AFUP. Ce journaliste d’Arrêt sur images avait commencé sa conférence par questionner pourquoi il n’y pas de journalistes couvrant l’évènement.

En 2022 lors du salon Open Source Experience (OSXP), en discutant avec Nÿco sur le stand LinuxFr.org, j’avais émis l’idée d’aller au FOSDEM en 2023 pour faire un reportage photo comme celui que j’avais fait pour les Journées Méditerranéennes du Logiciel Libres et de le la démopartie Alchimie en 2013.

Car un événement de plus de 20 ans d’âge réunissant plus de 8000 spécialistes à la pointe de la technologie ça mérite l’intérêt et le détour.

Mais qu’est-ce que le FOSDEM ?

Créé à l’initiative de Raphaël Bauduin en 2001 sous le nom de OSDEM pour Open Source Software Developers' European Meeting (le F de Free fut ajouté plus tard), le FOSDEM rassemble chaque année des milliers de développeurs de logiciels libres du monde entier, aussi bien utilisateurs, contributeurs bénévoles, ou salariés d’entreprises travaillant dans ce domaine ou ayant un intérêt dans le logiciel libre, et probablement aussi certains de leurs employeurs.

L’événement se passe sur deux jours, et accueille une grande quantité de conférences sur des sujets divers et variés en rapport avec le logiciel libre.

Se faufiler parmi la foule pour prendre cette photo ne fut pas chose aisée…

L’évènement reçoit régulièrement pour ses conférences des personnes renommées comme Larry Lessig et Alan Cox en 2003 et 2005, Theo de Raadt, Jimmy Wales et Richard Stallman en 2005, Keith Packard et Miguel de Icaza en 2007, Andrew Tanenbaum et Greg Kroah-Hartman en 2008.

Vous êtes journaliste et vous ne connaissez pas ces noms ? C’est le moment de commencer à potasser le sujet. Cette liste est incomplète et s’arrête en 2008 ? Je vous invite à écrire les articles qui permettront de compléter et sourcer la page Wikipédia. 😉️

Mais au-delà de quelques personnalités qu’on peut parfois y croiser, le FOSDEM est un événement très populaire qui rassemble beaucoup, mais vraiment beaucoup de monde.

D’abondantes conférences ont lieu en simultané toute la journée, et de nombreux stands sont présents un peu partout pour des présentations plus informelles, notamment pour les associations.

C’est l’occasion d’acheter quelques goodies et de se servir en autocollants à apposer sur son laptop de hacker, mais surtout de faire des rencontres. Lors de ma visite en 2023 j’ai par exemple eu l’occasion de trinquer à la buvette avec Karol Herbst de chez Red Hat (l’auteur de RustiCL, la nouvelle implémentation d’OpenCL en Rust de Mesa).

Repartir du FOSDEM avec un ordinateur aussi bien décoré que celui du stand FreeBSD, c’est un projet de vie tout à fait honorable…

Un évènement populaire

Je me suis rendu compte à mon retour en 2023 que mes photos ne sauront entièrement retransmettre le sentiment que provoque l’impressionnante foule que rassemble le FOSDEM. Dans mon exercice photographique, je me suis surtout concentré sur des tableaux illustrant la vie au FOSDEM avec un cadrage plus personnel, ce qui rend moins évident cet aspect de masse humaine très impressionnante.

Mes photos de la conférence de clôture 2023 qui se déroule alors sans concurrence donne un certain aperçu du nombre de personnes présentes, mais humainement, je pense que le plus fort sentiment pour un visiteur sur place est nourri à midi lorsque tout le monde fait la queue aux différents food trucks.

PostgreSQL et patin-couffin…

Cette année 2024 voit l’ouverture d’un FOSDEM junior avec des ateliers pour les plus-jeunes, de 7 à 17 ans ! Contrairement aux ateliers des adultes, les ateliers pour les jeunes sont sur inscription.

Quelqu’un qui participe au FOSDEM se trouvera un hôtel à proximité et s’achetera une carte du tramway local. J’ai remarqué que le matin du deuxième jour, les suggestions Youtube sur la télé de mon hôtel avaient complètement changé en comparaison avec celles de la veille : Youtube me proposait désormais des vidéos de développement avec Rust. 😁️

Le primo-visiteur du FOSDEM aura aussi besoin d’un smartphone avec un grand écran et une bonne batterie (qu’il n’est pas forcément évident de recharger sur place). En effet, la grande taille du campus, le nombre considérable de salles, le nombre de conférences impressionnant, et la quantité de monde toute aussi superlative font qu’il vaut mieux compter sur sa poche pour avoir un plan des lieux à tout instant, ainsi que le programme complet. En fait ce n’est pas absurde pour un nouveau venu de venir avec un dossier imprimé sous le bras, plus fiable qu’une zappette au lithium.

La restauration est assurée par des restaurateurs ambulants locaux et leur camion-fricadelle, camion-frites, camion-pizza, camion-pâtes, et camion-gauffres, sans oublier le chocolat, avec les gauffres.

Bon par contre, j’ai testé pour vous, on a beau être en Belgique où la langue française est une des langues nationales, si mon hôtel parlait français, aucun des restaurateurs ambulants n’a honoré des simples commandes (frites, pizza…) en français. Même à Bruxelles, l’anglais est obligatoire pour manger sur le lieu de l’évènement. Ah, et la moutarde n’existe pas. Vous aurez droit à une variété de sauces pour vos frites, mais la moutarde y est totalement inconnue ! 😲️

Frites et fricadelle	Pizza

Un « vrai influenceur » prend en photo ce qu’il mange n’est-ce pas ? J’attends encore ma moutarde…

Une buvette tenue par les volontaires est disponible dans les locaux. Oubliez les distributeurs automatiques que vous pourriez trouver dans les couloirs, ils ne seront jamais en mesure d’encaisser le choc d’une telle population, de toute façon.

La buvette est aussi le lieu parfait pour le geek qui veut se poser avec son ordinateur portable (là encore, avec une bonne batterie) pour geeker en toute convivialité, accompagné d’une gaufre au chocolat et d’un sympathique petit rafraîchissement à bulles.

La buvette

Avec ses milliers de participants, le FOSDEM ne tournerait pas sans son armée de bénévoles qui font un travail tout aussi précieux que discret. J’en ai compté environ 160 pour 2023.

L’équipe du FOSDEM veille au bon déroulement de l’évènement.

Au-delà de ses conférences et de ses stands chamarrés, le FOSDEM est donc aussi l’occasion d’une virée en Belgique pour y manger des frites, des gaufres et boire de la bière. Si vous n’avez pas une conférence qui vous attend très tôt le lendemain matin, c’est l’occasion de vous promener en centre-ville dans la soirée.

Les conférences

Le FOSDEM a 35 salles de conférences, en 2023 il y avait 787 conférenciers. En 2024 ce sont 946 conférenciers qui sont attendus ! Pour deux jours seulement de conférences !

Il faut donc compter qu’au plus fort de la journée, à chaque instant, se déroulent plus d’une trentaine de conférences en simultané. Une fois qu’une salle est pleine, on n’entre plus. C’est l’usine.

Quelques photos panoramiques…

Mmh, ça en fait du monde…

Les salles de conférences vont de petites salles de cours à l’atmosphère intimiste aux grands amphis qui peuvent nous faire regretter de ne pas avoir apporté une jumelles.

Le découpage en de très nombreuses conférences permettent tout de même quelques échanges de questions/réponses à la fin de celles-ci, malgré le nombre conséquent de visiteurs.

Suivre les conférences en ligne

Toutes les conférences du FOSDEM sont captées, diffusées, et enregistrées !

Il est donc possible d’assister aux conférences en ligne, y compris les archives des années précédentes.

En 2023, le FOSDEM avait diffusés 35 flux vidéo simultanés (une par salle j’imagine), avec 19 630 spectateurs uniques et 800 spectateurs concurrents. Ça fait plus de 300 heures de vidéo pour un seul FOSDEM !

Des développeurs Microsoft viennent au FOSDEM pour nous parler de Rust, certains douteront-ils encore que Rust saylemal?

Les stands

Les couloirs de l’université sont le lieu des stands, et cette partie est similaire à ce qu’on peut trouver à d’autres rassemblements d’utilisateurs et développeurs de logiciel libres.

Stands en tout genre	Stands en tout genre

On y trouve aussi bien des stands d’associations que d’entreprises et cela reflète bien la dynamique libre de collaboration. Prenez l’expérience OSXP et imaginez les entreprises avec la même ambiance que le village associatif, ça donne les couloirs du FOSDEM.

J’y ai retrouvé le stand Debian que j’avais vu à l’OSXP quelques mois plus tôt, ainsi que celui de VLC avec sa roue de la fortune dont le succès n’était égalé que par l’incroyable salopette orange de son animatrice.

Au détour de ces stands lors de ma visite en 2023 j’ai eu une conversation très sympathique avec les tenanciers du stand de Chamillo, un logiciel libre d’ « e-learning ».

Les visiteurs

Le bain de foule du FOSDEM est aussi l’occasion d’une analyse sociologique de sa population, entre les officiels de certaines entreprises, les invités de marque, les geeks barbus dont la taille de la pilosité reflète peut-être la profondeur de leur expertise (ou pas), etc.

Rust saymal…	Google c’était mieux avant !

Quelques affichages sauvages facétieux…

On peut aussi sonder certaines tendances parmi cette population. Prenons par exemple deux catégories d’utilisateurs de logiciel libre : le geek enthousiaste à la pointe de la technologie et prêt à sauter sur la première nouveauté d’où qu’elle vienne, et le prudent et circonspect par défaut, plus porté sur les aspects de souveraineté, de vie privée, etc.

On peut supposer que la communauté des utilisateurs et développeurs des logiciels libres soit plus favorable à la seconde population que d’autres communautés, par exemple on aura probablement plus de chances de trouver un partisan de l’autohébergement chez un libriste linuxien que chez un membre d’un fanclub Apple.

Mais la population « circonspecte » est-elle majoritaire dans la population libriste ? Il y a une dizaine d’années certains remarquaient l’omniprésence de Macbooks à certaines conventions de libristes, cette mode semble être passée et j’ai observé un grand retour des Thinkpads quoi que j’ai pu entendre des intentions d’achat de machines Apple silicon pour jouer avec Asahi Linux.

Un autre aspect cher à certains libristes attachés à une certaine philosphie Unix est : un outil pour une tâche. Je me suis pourtant trouvé un peu comme un OVNI à séparer les fonctions téléphone, appareil photo, et carte bancaire…

C’est pour ces deux raisons que j’ai trouvé particulièrement intéressante et inattendue l’observation sociale suivante : le constat que l’écrasante majorité des participants au FOSDEM paient leurs consommations avec leur téléphone. Cela vous surprend-il ? N’hésitez pas à partager votre analyse ou vos explications en commentaire ! 😉️

Où est la Presse ?

Comme indiqué en introduction, en 2023 la conférence de clôture était donc donné par Steve Crawford de la NASA, ce qui pouvait susciter un article facile pour la presse non-spécialisée. On pouvait traduire le début de l’annonce de cette conférence ainsi : « Le logiciel a été le fil conducteur de toutes les grandes réalisations de la NASA, de l’alunissage aux images les plus profondes de notre univers. Aujourd’hui, la NASA s’appuie sur les logiciels libres, y contribue et les publie pour faire avancer ses missions scientifiques. ». Sans forcément entrer dans des détails cryptiques, il était facile de faire quelques publications avec un joli titre accrocheur.

La NASA au FOSDEM en 2023	Dans les étoiles

Cette année 2024, on notera la conférence « Where have the women of tech history gone? » qu’on doit pouvoir traduire par « Où sont passées les femmes de l’histoire technologique ? », un sujet accessible à de très nombreux médias, et tout à fait dans l’air du temps pour vendre du papier.

À propos des photos

Ces photos sont un peu mes cartes postales envoyées au lectorat de LinuxFr.org, avec un service postal soumis aux aléas de mes (in)disponibilités 😜️.

Les photos de ce reportage sont distribuées sous license libre CC By 4.0 (Creative Commons Attribution). L’album complet peut être téléchargé ici. On y trouvera quelques photos que je n’ai pas mises ici pour ne pas noyer le reportage, et quelques photos un peu redondantes mais dont le point de vue ou certains aspects peuvent susciter un certain intérêt (spécialement si certains s’y reconnaissent !).

Ceux qui souhaiteraient faire un don libre pour les photos peuvent le faire ici.

Ce reportage photographique a été réalisé avec les logiciels libres suivants :

• Darktable (développement photo numérique) ;
• Hugin (assemblage de photo panoramique) ;
• Magic Lantern (extension pour micrologiciel d’appareil photo) ;
• GpsPrune (géolocalisation de photos) ;
• Ghostwriter (édition de texte au format Markdown).

Et si vous êtes au FOSDEM cette année, n’hésitez pas à venir raconter votre aventure ! 👋️