Je suis James Fulop, programmeur en chef du moteur de l’équipe de Guild Wars 2. La prise en charge de DirectX11 a demandé beaucoup de temps. Dans cet article, je vais parler de certaines des décisions techniques de haut niveau qui ont été prises pour déterminer le cadre du projet, et je vais également décrire notre exécution des graphismes et l’influence que le rendu DirectX11 a sur les performances.

La bêta commencera le 21 septembre 2021. Vous pourrez choisir de vous y inscrire directement depuis le menu « Options graphiques » du jeu. Vous devrez redémarrer le jeu pour constater les changements.

Pour commencer, pourquoi avons-nous décidé de passer à DirectX11 ? Nous mettons la priorité sur les performances client, et nous voulons que chacun puisse jouer avec la meilleure fréquence d’image possible. Nous avons remarqué que le jeu restait parfois figé jusqu’à ce que tout le rendu soit exécuté. Guild Wars 2 existe désormais depuis neuf ans, et il peut être judicieux de mettre en place des fonctionnalités propres à DirectX11 pour faire en sorte que le jeu reste tout aussi beau au fil du temps.

DirectX11 propose également des options de technologie moderne qui n’étaient pas disponibles avec DirectX9. Le passage à DirectX11 représente la première étape pour pouvoir réaliser encore plus de belles choses.
Après des recherches minutieuses, nous avons choisi d’intégrer la bibliothèque open source de rendu BGFX dans Guild Wars 2. BGFX est une bibliothèque soignée qui prend en charge plusieurs entrées développeur pour les graphismes et qui est déjà employée dans de nombreux jeux à travers toute l’industrie. Pour en savoir plus, je vous invite à consulter son site officiel.

Alors que les écosystèmes graphiques de l’industrie informatique continuent d’évoluer, BGFX nous permet de collaborer au sein d’une communauté d’ingénieurs de rendu, et nous évite à tous de devoir « réinventer la roue » dans chaque studio. ArenaNet a déjà contribué au développement de BGFX, et continuera de le faire.

Nous avons préféré DirectX11 à DirectX12 ou Vulkan, car nous avons découvert que le passage à la mise en œuvre de DirectX11 et sa bibliothèque BGFX fournissait une amélioration suffisante des performances pour que l’entrée développeur des graphismes ne limite plus jamais les performances client. DirectX11 est très stable et a déjà été employé dans des milliers de jeux pendant presque une décennie. Cela nous permet de prendre en charge les ordinateurs à partir de Windows Vista, alors que la prise en charge par Vulkan ne commence qu’à Windows 7, et celle par DirectX12 ne commence qu’à Windows 10. En ce qui concerne les fonctionnalités graphiques, le passage de DirectX9 à DirectX11 nous donne quantité d’options pour ajouter des fonctionnalités intéressantes au moteur du jeu dans les années à venir. La prise en charge de plusieurs de ces entrées développeur entraînerait une surcharge de travail pour l’équipe d’assurance qualité, pour peu d’avantages concrets.

Le rendu DirectX9 actuel n’a pas été modifié de manière importante. En travaillant sur ce projet, l’une de mes stratégies consistait à faire en sorte que le rendu DirectX11 soit similaire au DirectX9. Si j’avais apporté des modifications aux deux rendus en même temps, il n’y aurait plus eu d’élément témoin sur lequel baser le reste. Le rendu DirectX9 finira par être inaccessible, puis supprimé du moteur lorsque le nouveau rendu sera stable.

Chute de fréquence

Maintenant, j’aimerais expliquer en quoi le rendu DirectX11 affectera les performances du jeu. Commençons par les bases : les jeux vidéo fonctionnent comme un film, vous voyez des images fixes qui défilent rapidement sous vos yeux. Ces images fixes sont aussi appelées « frames ». Ce système est à l’origine du terme anglais « frames per second » (FPS, ou fréquence d’images). Plus les FPS sont élevées, plus l’action semble fluide, jusqu’à atteindre la limite physique de votre écran. Le procédé qui consiste à constamment réagir aux saisies (de clavier et de souris) et à produire des images s’appelle « la boucle de jeu ».

Voyons maintenant la visualisation chronologique de la boucle de jeu. Ces données concernent l’endroit ci-dessus, dans l’Arche du Lion, avec la configuration graphique « Privilégier le rendu ».

J’ai choisi cet endroit, car il présente beaucoup de rendu à réaliser. Il y a toute la ville, et la technique que nous utilisons pour les réflexions en temps réel crée plus ou moins une deuxième fois le monde, à l’envers.

Pour ce test, j’utilise un processeur Intel I7-6700 et une carte graphique NVIDIA 1080.

Voici une capture d’écran de Telemetry, un outil de visualisation que nous utilisons, conçu par RAD Game Tools. Il permet de visualiser la distribution de l’exécution du jeu à travers les cœurs du processeur. Le temps est représenté dans les abscisses. On peut voir la logique de jeu dans l’équivalent de deux images fixes. J’ai brouillé beaucoup d’identifiants par souci de clarté.

Chaque rangée horizontale représente une trame logique. Vous pouvez donc voir que j’ai six trames de travail. Nous ajustons le nombre de trames de travail en fonction du nombre de trames d’exécution que votre processeur autorise. La puce que j’utilise autorise huit trames d’exécution matériels, le jeu les répartit donc entre une trame de jeu, une trame de rendu, et six trames de travail. Notez que Guild Wars 2 utilise d’autres trames, que je ne présente pas actuellement. Ces trames sont peu gourmandes en ressources processeur, et ne sont donc pas pertinentes pour cet article.

Les divers blocs dans les canaux d’une trame représentent le travail en cours. Lorsque la trame s’affiche comme vide, cela signifie qu’elle est inoccupée et ne génère rien pour le jeu. Dans ces cas-là, la trame matérielle peut récupérer du travail auprès d’autres applications de votre machine.

Les images logiques sont les moments où l’on considère que la boucle de jeu a recommencé. Les barres verticales symbolisent le début des images logiques. Les saisies matérielles (comme les claviers et les souris) sont mises en attente à ce moment-là.

Voici le moment où l’image graphique recommence. Puisque le début de l’image de jeu ne produit aucun rendu, on laisse un peu du travail de l’image précédente déborder dans la nouvelle image, pour pouvoir faire autant de travail que possible en parallèle. Mais au bout d’un moment, il est nécessaire d’attendre que l’image précédente soit purgée avant de commencer à donner du travail à l’image suivante. Là, vous avez peut-être remarqué un bloc rouge de travail sur la trame principale, qui s’aligne à la complétion de travail de la trame de rendu. Voilà ce qu’on souhaite éliminer. La trame de jeu ne devrait jamais avoir à attendre que le travail de rendu soit terminé.

D’autre part, il y a quelques autres blocs rouges, beaucoup plus petits, sur la trame principale. C’est parce que cette trame attend que celle de travail ait terminé.

Ici, on établit des listes détaillées d’instructions que la trame de rendu doit exécuter. Lorsqu’un bloc de travail de rendu généralisé a été réalisé, il est transmis à la trame de rendu.

La trame de rendu convertit le travail de rendu en données graphiques pour entrée développeur (OpenGL ou DX9).

Image de rendu DX11 Bêta

Voici à quoi ressemble le nouveau rendu dans le profileur.

La configuration des trames est identique.

La trame principale n’est plus obligée d’attendre que celle de rendu ait terminé ! Ce résultat est dû à l’architecture de BGFX. Les éléments à représenter sont collectés sur la trame de jeu (et également sur les trames de travail, mais on en parlera plus tard). Ensuite, lorsque l’image se termine, BGFX prend en compte ces éléments sur sa trame de rendu. Et on a donc beaucoup de capacités pour représenter les éléments !

La conversion des données de rendu en attente en éléments à représenter par BGFX se passe en parallèle, à travers les trames de travail.

Et voilà ! Ce projet était très intéressant. J’ai hâte de découvrir l’avenir technologique qui attend Guild Wars 2.

N’hésitez pas à nous dire si la bêta DirectX11 vous plaît dans les forums.

À bientôt en Tyrie !

– James Fulop