Around the Verse 08/03 – Performance et Optimisation


La nouveauté du format de cet ATV tient dans le fait d’être filmé avec un public, une première dans toute l’histoire des ATV de CIG. Cet épisode est long, très long, 1h mais on va tenter de vous le résumer du mieux possible.

L’équipe travaille sur l’affichage de l’impact des laser/munitions sur le hud en haut à droite.
Ainsi il sera possible de voir si les projectiles qui vous sont destinés arrivent sur le bouclier ou sur vote coque.

Lors des communications entre les joueurs in-game, la “webcam” de votre interlocuteur s’intégrera sur certains écrans du cockpit.
Dans la version de fin mars, la 3.1, il sera possible sur un des moniteurs de votre vaisseau
de changer l’angle de vue que l’on a du vaisseau ciblé ou tout simplement de notre vaisseau.
Toujours dans le cockpit, il sera possible de personnaliser les affichages et de choisir ce que l’on veut voir et dans quel emplacement.

La transition entre le sol et l’espace est maintenant plus lisse. C’est ce que l’on pourra voir sur Yela dans la 3.1.

Les équipes VFX travaillent sur les effets des vaisseaux sortant pour la 3.1 et c’est vraiment beau! Lien
Mais ne vous inquiétez pas, elle est également sur les effets de lumière et les armes.
Le Mobiglass occupera plus d’espace sur l’écran apportant un plus grand confort de visualisation pour la customisation.
Comme nous en avions déjà parlé, les équipes travaillent sur la génération des missions par les joueurs et le fait de pouvoir payer d’autres joueurs contre service, protection, aide.

Le travail sur les performances.
Le système est simple action(souris, clavier) -> prise en compte par l’univers -> rendu graphique et on recommence!
Si l’on a cette suite 60 fois par seconde on a 60 images par seconde.
Mais avec la technologie actuelle, il faut 50 ms et le jeu donnera un rendu de 20 images par seconde
Actuellement le processeur met à jour l’univers, attend que notre carte graphique soit disponible et celle-ci nous donne un rendu visible.
L’équipe nous explique le rendu en parallèle qui consiste à ne pas attendre la disponibilité de la carte graphique et de continuer à calculer l’univers des images suivantes etc… au même titre que votre vidéo youtube qui charge et dont vous n’avez pas encore vu toutes les images.
Dans le cas ou le processeur est plus rapide que la carte graphique, nous avons de la latence.
Dans le cas contraire, la carte graphique ayant moins d’image disponible, le jeu va saccader.
Voilà un exemple de travail sur lequel l’équipe est afin de garantir la meilleure fluidité.
Il y a également du travail sur le réseau et le rendu du jeu en cas de non-réception d’une mise à jour de l’univers en local de votre ordinateur mais nous en parlerons plus tard en détaille dans l’émission de ce dimanche.

Comme c’est un peu compliqué on vous propose le Terrapin d’Anvil en vol : Vidéo du Terrapin en vol

Concernant le rendu, les polygones, les petites formes qui permettent de matérialiser les formes du jeu se feront plus nombreuses si l’on s’en approche et inversement.
Dans le même thème, dans votre vaisseau, l’autre côté d’une porte sera généré à l’ouverture de la porte.

La technologie du “science distance field” permettra d’avoir de meilleures résolutions sur les vaisseaux, plus rapidement et avec le champ de forces qui épousera la coque des vaisseaux.

L’équipe travaille sur la synchronisation entre le traitement du processeur et les évènements de communications réseau afin d’avoir le bon timing entre la réception réseaux et la disponibilité du processeur pour le traitement de cette information, c’est un peu comme si vous n’aviez jamais d’attente à la poste.
Les processus réseau, n’ont jamais été un problème, ce sont les traitements en amont, c’est-à-dire la plus haute couche de traitement.
Les mises à jour utiles sont un vrai questionnement chez CIG, à l’instar de l’état actuel où tout le monde reçoit les mises à jour de tout le monde, l’équipe doit choisir ce qui est utile pour un joueur de savoir et ce qu’il ne l’est pas.
Une fois la réponse trouvée nous auront une des optimisations les plus importantes. C’est le Bind Culling.

Le Blind Culling demande, les variables sérialisées, le streaming d’objet en conteneur et encore d’autres éléments. D’où sa publication en 3.2 et non en 3.1 comme initialement prévu.

L’équipe s’aide d’une machine spécifique pour des auto-tests qui simule plusieurs vrais joueurs afin de mieux trouver les baisses et bug de performance.

Pour terminer, il est toujours bon de rappeler que l’optimisation est toujours à en devenir de par la nature non statique du code qui change au fur et à mesure de l’ajout de fonctionnalités et d’éléments.
Les 144 images par seconde, cela n’est pas pour tout de suite mais la 3.2 a clairement comme objectif de nous apporter une valeur proche de 60 ce qui serait une merveille comparée à l’état actuel du gameplay.


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *