Performance et brouillard volumétrique : comparaison ciblée des paramètres

Le chef de projet graphique vérifié

Les graphismes faibles sont une première comparaison utile lorsque He Who Watches fonctionne mal. Lors d'une discussion le 6 septembre, le développeur Danga a identifié le brouillard volumétrique comme la raison probable pour laquelle la charge du GPU d'un joueur différait fortement entre Moyen et Faible. Dans une réponse distincte du 5 septembre, le développeur a déclaré que le mode Faible désactive le brouillard volumétrique. Ces déclarations soutiennent le test du préréglage ; elles n'établissent pas que le brouillard cause chaque saccade ni que le mode Faible garantit une performance fluide sur chaque machine.

Le rapport sur la performance du hub décrivait également une animation de mouvement irrégulière. Le développeur a considéré cela comme pire que prévu et a demandé des retours depuis le menu de pause pendant que le problème se produisait. Cela reste une distinction importante : une explication probable pour une différence de charge graphique n'est pas un diagnostic confirmé pour chaque symptôme dans le même rapport.

Le flux de travail ci-dessous est une procédure générale de dépannage originale construite autour de cette piste étroite du développeur. Elle n'a pas été testée sur une machine de test pour cet article. Utilisez-la pour faire une comparaison propre dans votre propre configuration, conservez les résultats et décidez si vous avez une solution utile ou un problème nécessitant un rapport.

Décrivez ce qui semble incorrect

Commencez par le symptôme visible. Le mouvement est-il systématiquement lent, l'image s'arrête-t-elle par intervalles ou une entrée semble-t-elle sauter une partie de son animation ? Le problème se produit-il en restant immobile, en tournant ou en se déplaçant dans un hub ? Ces observations sont plus utiles qu'une simple affirmation disant que la performance est mauvaise.

Si vous avez déjà un affichage du taux de rafraîchissement, enregistrez les valeurs que vous voyez, mais ne laissez pas un chiffre remplacer la description. Un jeu peut montrer une moyenne acceptable tout en produisant des pauses visibles. À l'inverse, un taux plus bas mais stable peut sembler plus prévisible. La question de support concerne votre expérience observée, pas seulement le chiffre le plus élevé atteint dans une scène vide.

Gardez les crashs et les redémarrages du système dans une catégorie séparée. Ils nécessitent une réponse différente d'une simple différence de taux de rafraîchissement. Ne relancez pas plusieurs fois une scène qui fait redémarrer toute la machine juste pour collecter un autre échantillon de performance. La page crash-et-retours explique comment enregistrer ce symptôme sans le traiter comme un benchmark ordinaire.

Établissez une base de référence que vous pouvez répéter

Choisissez un endroit auquel vous pouvez revenir et une petite action que vous pouvez répéter, comme un petit tour ou un bref déplacement le long d'une partie visible du hub. Notez le nom de la chambre, le préréglage graphique, la résolution si disponible, la limite de frames si vous en utilisez une, et si la machine est sur sa configuration de puissance normale. Gardez le test suffisamment court pour que l'état de la pièce reste facile à récupérer.

Observez la même action plusieurs fois avant de changer un paramètre. Une pause ponctuelle lors d'une transition peut ne pas représenter le comportement stable de la scène. Vous cherchez un motif assez clair pour qu'une comparaison ultérieure puisse significativement en différer. Ne passez pas toute une session de jeu à collecter des chiffres lorsqu'une brève observation établit déjà le problème.

La référence de base est votre référence locale, pas un point de repère universel. Un autre joueur peut utiliser le même préréglage sur un matériel différent et obtenir un résultat différent. Notez suffisamment de contexte pour que votre propre comparaison avant-après soit équitable sans la présenter comme une promesse pour tout le monde.

Changez d'abord uniquement le préréglage

Sélectionnez Faible dans les options graphiques du jeu, en utilisant les étiquettes de menu visibles dans votre copie. Revenez à la même scène et répétez la même petite action. Laissez les autres paramètres inchangés pour cette première comparaison lorsque cela est pratique. L'objectif est de voir si le changement de préréglage produit une différence notable dans des conditions similaires.

Le rapport initial du joueur a changé à la fois la qualité graphique et la limite de frames. Son résultat n'isole donc pas l'effet d'une seule variable. L'explication du développeur sur le brouillard fait du préréglage une piste solide, mais une comparaison locale contrôlée peut vous en dire plus sur votre configuration particulière que de copier plusieurs valeurs changées ensemble.

Si Faible aide clairement, vous avez un choix de configuration pratique. Vous n'avez pas besoin de restaurer une mauvaise configuration à plusieurs reprises pour prouver l'amélioration. Notez ce qui est devenu meilleur et ce qui est resté inchangé. Une réduction de la charge avec des pauses persistantes dans le hub est un résultat différent de la disparition des deux symptômes, et la différence compte pour un rapport utile.

Évaluez la limite de frames séparément

Si le jeu expose une limite de frames dans votre menu actuel, vous pouvez comparer une limite inférieure comme deuxième test. Gardez le préréglage graphique fixe lors de cette comparaison. Il s'agit de dépannage graphique général, pas d'une solution confirmée par le développeur pour ce titre. Utilisez une valeur qui a du sens pour votre écran et vos préférences plutôt que de copier le chiffre d'un autre joueur comme objectif idéal.

Observez si la limite change la cohérence, la réactivité et le symptôme que vous avez initialement décrit. Une cible plus basse peut modifier la charge de travail du système, mais le résultat réel dépend de la configuration et de la scène. Ne déduisez pas une température ou une réduction de charge spécifique sans la mesurer sur votre machine.

Si vous modifiez la limite de trame et le préréglage graphique ensemble par commodité, enregistrez-les comme un test combiné. Cela reste utile si l'objectif est une configuration confortable. Cela ne peut simplement pas indiquer quel changement a produit l'amélioration. Une étiquette honnête préserve la valeur du résultat sans prétendre avoir réalisé une expérience que vous n'avez pas effectuée.

Comparez les hubs avec des scènes plus petites

Le développeur a noté que les hubs sont plus grands, tout en disant que le comportement rapporté semblait pire que prévu. Vous pouvez aider à distinguer un problème spécifique à une scène en comparant la même action de base dans un hub et dans une salle plus petite à laquelle vous avez accès. Gardez les paramètres graphiques fixes pendant cette comparaison.

Enregistrez si le problème apparaît dans tous les hubs que vous avez vérifiés ou seulement dans une chambre nommée. Ne généralisez pas à partir de l'espace où vous l'avez remarqué pour la première fois. Un rapport sur un hub particulier donne au développeur un point d'investigation plus concentré qu'une déclaration selon laquelle toutes les grandes zones sont défectueuses alors que vous n'avez testé qu'une seule.

Si le problème suit une vue particulière dans le hub, notez le repère ou la direction visible. Cela ne prouve pas quel effet ou objet est responsable, mais cela peut rendre le comportement plus facile à reproduire. Une courte description de la vue est souvent plus utile qu'une supposition non étayée sur le moteur de rendu.

Gardez les problèmes de mouvement distincts

Une animation qui semble couvrir deux tuiles à la fois n'est pas automatiquement un problème de liaison d'entrée. De même, tourner le personnage à gauche et à droite au lieu de se déplacer latéralement n'est pas automatiquement un problème de fréquence d'images. Comparez la position finale et la direction du regard après une entrée volontaire. Cela vous aide à décider si vous devez enquêter sur le timing, l'état d'entrée, ou les deux.

La solution connue avec Shift a un symptôme spécifique et une réponse du développeur propre. Utilisez cette page si la rotation remplace le mouvement latéral, surtout après le superposé. Ne la combinez pas avec des changements graphiques à moins d'avoir observé les deux problèmes et de les tester séparément. Sinon, vous pourriez perdre la capacité de déterminer quel changement a aidé.

Si la scène se met en pause mais que l'action finale est correcte, indiquez-le. Si l'état final lui-même diffère de l'entrée que vous attendiez, indiquez cela à la place. Le développeur peut utiliser ces distinctions pour séparer un problème de présentation visuelle d'une action qui pourrait avoir été traitée différemment.

Contexte du système d’enregistrement sans deviner

Incluez le système d’exploitation, le processeur, le périphérique graphique, la mémoire, et si vous jouez à travers une couche de compatibilité lorsque vous pouvez les identifier. Utilisez les noms indiqués par votre système plutôt qu’une description vague comme un ordinateur portable de jeu. Vous n’avez pas besoin d’exposer des informations personnelles sans lien pour fournir un contexte matériel utile.

Si vous n’êtes pas sûr d’un composant, marquez-le comme inconnu jusqu’à ce que vous puissiez vérifier. N’inférez pas un modèle graphique à partir de la marque de l’ordinateur ou d’un autocollant marketing. Des informations précises sont utiles, mais une précision inventée peut détourner le support de la bonne voie.

Notez aussi si d’autres travaux exigeants étaient en cours pendant la comparaison. Ce n’est pas une raison pour blâmer chaque application en arrière-plan. Cela aide simplement à expliquer pourquoi deux observations locales peuvent différer. Gardez vos tests dans des conditions globalement similaires si vous voulez attribuer la différence à un cadre de jeu.

Interprétez soigneusement l’utilisation du GPU

Une forte utilisation du GPU ne permet pas d’identifier un bug. Sa signification dépend de la charge de travail, des paramètres, de la cible de trames et des symptômes observés. Le commentaire du développeur donne une explication probable de la différence entre deux préréglages dans un même rapport, pas un seuil au-dessus duquel chaque système est défaillant.

Si vous surveillez déjà l’utilisation, enregistrez-la en même temps que la scène et les paramètres plutôt que comme un nombre isolé. Une valeur provenant d’un hub et une valeur d’un menu ne constituent pas une comparaison claire. Il en va de même pour les mesures prises après différentes durées de jeu ou avec d’autres travaux en arrière-plan.

Ne copiez pas les valeurs de température d’un autre joueur comme une limite sûre ou non sûre pour votre matériel. Cette page n’est pas un manuel de diagnostic matériel. Si l’ordinateur lui-même s’éteint ou redémarre, cessez de considérer la session comme un test de performance et utilisez un support approprié des appareils accompagné d’un rapport de jeu factuel.

Évitez les recettes d’optimisation non prises en charge

Les sources ici n’établissent pas de drapeaux de lancement spéciaux, de modifications de registre, de fichiers de configuration supprimés, ni de dérogation de pilote spécifique au jeu qui corrige les saccades du hub spécifiquement. Une longue liste de tels changements donnerait à l’article un aspect complet tout en réduisant la fiabilité de ses conseils. Commencez par l’introduction prédéfinie documentée et les comparaisons observables ordinaires.

La maintenance générale, comme maintenir les logiciels supportés à jour, peut être appropriée pour votre système, mais elle ne doit pas être annoncée comme une solution He Who Watches éprouvée. Si vous changez un pilote ou un composant du système d’exploitation pour vos propres raisons, notez l’état avant et après et évitez de modifier plusieurs autres variables dans le même test.

Ne sacrifiez pas une configuration fonctionnelle pour atteindre le niveau d'une machine appartenant à quelqu'un d'autre. L'objectif utile est un jeu stable et confortable sur votre propre matériel. Un réglage modeste qui fonctionne de manière constante peut être un meilleur choix pratique qu'un réglage plus exigeant choisi uniquement parce qu'une vidéo de comparaison l'a utilisé.

Utilisez les valeurs numériques maintenant affichées dans les menus.

Le patch du 4 septembre ajoute les valeurs affichées à côté des curseurs. Lorsque votre option pertinente utilise un curseur, notez cette valeur affichée plutôt que de décrire vaguement sa position. Cela rend la comparaison des paramètres plus facile à reproduire et un rapport de support plus facile à interpréter.

Le changement n'établit pas les noms ou les plages de chaque option. Lisez les étiquettes actuelles dans votre menu et conservez-les dans vos notes. Si vous faites une comparaison avec une autre langue, incluez une capture d’écran ou une courte description de la fonction plutôt que de supposer qu’une étiquette traduite est identique à un guide en anglais.

Gardez un petit enregistrement des paramètres pour la configuration que vous préférez. Si vous expérimentez plus tard, vous pourrez revenir à cette référence locale connue sans vous souvenir de la position de plusieurs curseurs. Ceci est particulièrement utile lorsque le réglage qui affecte le confort est différent du réglage que vous modifiez pour la performance.

Décidez si la solution de contournement est suffisante.

Si le réglage Bas élimine le problème et que le résultat visuel vous convient, continuer ainsi est un résultat pratique raisonnable. Vous pouvez toujours signaler le comportement original si vous disposez d'une description claire. Il n'est pas obligatoire de continuer à dépanner après que votre objectif de jeu confortable est atteint.

Si Bas améliore le chargement mais pas les pauses, gardez les deux résultats séparés. Le préréglage peut être utile tandis qu’un autre problème persiste. C’est plus informatif que de dire que cela n’a pas du tout fonctionné. Cela indique au développeur quelle partie de l’expérience signalée a changé sous la comparaison recommandée.

S’il n’y a aucune amélioration visible, cessez de répéter le même test sans poser une nouvelle question. Recueillez les détails de la scène, des paramètres et des symptômes et utilisez la voie de retour d’information. Un résultat négatif est une preuve utile lorsque les conditions sont claires ; il n’est pas nécessaire de le transformer en une théorie certaine sur un goulot d’étranglement.

Envoyez des retours tant que le problème est pertinent.

Dans le fil hub-performance, le développeur a spécifiquement demandé un rapport de retour via le menu pause pendant que le lag se produisait. Suivez cette voie si le jeu reste suffisamment jouable pour le faire. Décrivez le hub, l’action, le préréglage, et si le même comportement apparaît ailleurs. Incluez le résultat de votre comparaison Bas.

Un court rapport peut indiquer qu’un hub nommé fait une pause lors d’un simple tournant, qu’une pièce plus petite ne le fait pas, et que le changement de préréglage a réduit la charge sans modifier les pauses. Il s’agit d’un modèle de rapport, pas d’une affirmation concernant votre machine. N’utilisez que les observations que vous avez réellement faites et laissez de côté les comparaisons non testées.

Si vous joignez un enregistrement, concentrez-vous sur le moment reproductible. Expliquez l’entrée et le mouvement attendu afin que le développeur puisse distinguer une pause volontaire du problème. Marquez les zones secrètes de manière appropriée si vous publiez publiquement, et évitez d’exposer un contenu de bureau non lié dans la capture.

Re-vérifiez uniquement lorsqu’un élément pertinent change.

Après avoir choisi une configuration fonctionnelle, revenez sur le problème lorsqu’une mise à jour pertinente, un changement matériel ou de nouvelles instructions du développeur vous en donnent la raison. Répéter le même benchmark à chaque session apporte peu d’informations. Une note datée permet de comparer un changement ultérieur avec l’état que vous avez déjà documenté.

Ne supposez pas qu’un nouveau patch corrige les performances sauf si ses notes ou vos observations établissent ce résultat. L’annonce du 4 septembre couvre les changements de puzzle et de menu, pas une correction universelle des saccades. Maintenez une amélioration ultérieure liée à la version et aux conditions où vous l’avez observée.

La boucle de support utile est petite : décrivez le symptôme, comparez un paramètre dans la même scène, conservez le résultat, et rapportez un problème persistant avec le contexte. Cela rend le brouillard du développeur exploitable tout en préservant la distinction entre un comportement de paramètre confirmé et un diagnostic de performance non résolu.

Lisez un petit journal de comparaison.

Imaginez un journal local avec trois entrées : un hub sur le préréglage original, le même hub sur Low, et une pièce plus petite sur Low. Il s’agit d’une structure de test suggérée, pas de données de benchmark de cet article. La première paire demande si le préréglage modifie le symptôme. La deuxième paire demande si le comportement restant dépend de la scène. Maintenir ces questions distinctes facilite l’interprétation des résultats.

Si le hub s’améliore sur Low et que la pièce plus petite est également fluide, vous disposez d’une configuration pratique à utiliser. Vous pouvez signaler le problème initial avec le contexte des paramètres, mais vous n’avez pas besoin de continuer à changer les options simplement pour produire une explication plus élaborée. L’objectif local de jeu stable peut déjà être atteint.

Si le hub ne s’améliore que partiellement alors que la pièce plus petite fonctionne bien, nommez le symptôme restant. Il peut s’agir d’une pause répétée brève, d’une animation abrupte ou d’un autre effet visible. Ne transformez pas l’amélioration partielle en « complètement résolu » ou « sans différence ». La distinction donne au développeur une image plus claire de ce que le préréglage affecte.

Si les deux scènes montrent le même problème, la comparaison n’a pas isolé un problème spécifique au hub. Cela ne prouve pas que la cause se trouve en dehors du jeu. Cela signifie simplement que la taille de la scène, dans les conditions que vous avez testées, n’a pas permis de distinguer les cas. Incluez le résultat et passez à une question de support pertinente au lieu d’inventer une conclusion.

Si les mesures varient trop pour être interprétées, raccourcissez le test et stabilisez les conditions. Utilisez la même vue, action et paramètres pour l’observation suivante. Une comparaison bruitée est une raison d’améliorer l’observation, pas une raison de choisir n’importe quel chiffre qui soutient votre théorie préférée.

Gardez le journal suffisamment petit pour rester lisible. Une poignée de comparaisons clairement décrites peut être plus utile que des centaines de valeurs sans scène ni paramètres attachés. Le développeur doit savoir ce qui a changé et ce qui n’a pas changé. Votre futur vous-même a besoin des mêmes informations lorsqu’il décide si une mise à jour ultérieure a affecté le problème.

Sources et preuves

1. Saccades dans les zones centrales : réponse du développeur ↗
2. Plantages et qualité graphique basse : réponse du développeur ↗
3. Mise à jour des curseurs numériques du 4 septembre ↗