Hello,

Je rebondis juste sur le point 1/, pourquoi calculer plus de fps que ce que l'écran peut afficher.

Je ne retrouve plus l'article ( peut-être le même que celui de cybersam ), mais en gros ça disait que l'affichage c'est l'affichage ok. Donc pas besoin de calculer beaucoup plus juste pour l'écran.

MAIS si ton jeu peut tourner "plus vite" ( plus de fps), alors tu auras une meilleure réactivité à tes inputs ( clavier/manette). Pratique pour les jeux compétitifs, ou pour les jeux ou tu fais beaucoup de changements de direction ( bah oui entre un jeu a 60 ou 120 fps, on gagne jusqu'à 8ms de temps de réaction - dans le pire cas)

effectivement il est vrai de dire que théoriquement, le jeu continue de tourner et que cela pourrait améliorer les inputs. Après je ne sais pas quelles sont les coding rules des developpeurs à ce sujet. En effet, les moteurs graphiques et physiques peuvent être décorélés. Si la séparation est bien faite, limiter le framerate (donc la partie graphique) n'aurait potentiellement pas d'impacte sur la réactivité des inputs. Pour être honnête, je pense que par soucis pratique, la plus part des jeux doivent probablement bloquer tous les moteurs, voir essayer de toujours les faire tourner au même framerate. Mais j'avoue qu'une confirmation m’intéresserait.

Bon sinon sur the division 2, je joue en WQHD Ultra AAx4 et je suis à 60fps tout le temps sauf dans la darkzone qui me fait descendre en moyenne à 50 fps. Je n'ai pas vérifié si le problème vient du CPU ou GPU par contre.

Hum… perso, je ne suis pas du tout sûr que les jeux bloquent leur moteur pour avoir toujours le même framerate (lorsqu'on désactive la synchronisation verticale). Mais il serait effectivement intéressant d'en avoir la confirmation.

En tout cas, si tu tournes à 60fps en "Ultra" dans the Division 2 en Quad HD (2.560x1.440), c'est plus ou moins ce que semblent obtenir les différents performance tests… avec un INTEL Core i9 9900K et toutes les options graphiques au maximum. C'est donc très bien.

je me suis peut etre mal exprimé, ou je n'ai pas compris ta réponse.

je voulais dire qu'il est possible comme le dit @mar1k que, au moins pour certains jeux/moteurs, limiter le framerate (par exemple en activant la synchro verticale) limite la fréquence de rafraîchissement de l'ensemble du jeu et pas seulement de la partie graphique. La réactivité des input en serait alors impactée. Cela dépend de la volonté des développeurs de séparer totalement ou non la partie graphique du reste du moteur.

Dans ces cas la, effectivement, jouer à plus de 60fps aurait un interet, malgré un écran limité à 60Hz

Je me permet d'intervenir parce que depuis le temps que je suis le topic je me suis rendu compte de ce dont vous parliez à propos de la limitation du framerate. J'ai vu un article similaire sur le site de Nvidia, ce serait déjà une piste pour le retrouver.

Mais de ce que j'ai conclu en vous lisant, c'est la synchronisation verticale qui limite les inputs et non la limitation pure et simple du framerate par la puissance de la carte graphique parce qu'avec la synchro, les images sont accumulées dans une mémoire tampon le temps qu'il y en ai assez pour en afficher 60 en 1 seconde et le temps que les images soit misent dans la mémoire tampon les commandes ont déjà été envoyée du coup il y a un délais entre l'action de la manette et ce qui apparait à l'écran.

Personnellement je préfère quand même jouer avec la synchro à 60fps, je ne ressens pas vraiment la latence que ça pourrait provoquer sur les inputs.

Maintenant je suppose que la mise en mémoire tampon provoque moins de latence des inputs sur des cartes plus puissantes.

Alors je ne suis pas certain d'avoir tout compris mais du coup je peux essayer de t'expliquer comment je vois la chose (sachant que je ne suis pas dev engine dans le jeu et que donc je ne fais que supposer):

en restant plus haut niveau (donc sans parler de buffer etc) et pour simplifier, on va dire qu'il y'a le graphic engine chargé de calculer le rendu, et le game engine chargé de tout le reste dont la gestion des input, calcul d'IA, position des asset dans l'espace etc.

Je pense qu'il est possible de séparer fortement ces deux moteurs, et que ce serait même une bonne chose. Mais que pour des problèmes de simplicité architecturale et pour éviter des problèmes de threading, les devs font parfois le choix de synchroniser ces deux parties.

Par exemple, si les 2 engines se rafraichissent à la même fréquence, le jeu peut dire a chaque tick:

• calcul la position des entities
• effectue un rendu de la scene

A l'inverse, si les engines ne sont pas synchrones, le rendu se fera potentiellement au milieu du calcul des positions. (toujours en prennant la même analogie, c'est quand t'es ni en adaptive sync, ni en vsync, et ca provoque du tearing). Donc pour éviter ces bugs qui peuvent être beaucoup plus grave qu'une simple erreur de position d'un mesh, il faudra faire en sorte que la scène soit validée par le game engine avant de calculer le rendu. Une solution pourrait être par exemple de stocker les valeurs validée par le game engine sur le dernier tick dans un buffer. (toujours sur la même analogie, cette solution serait basée sur le principe de la vsync).

Bref, on voit bien que la solution calquée sur l'adaptive sync est plus simple à mettre en place.

Mais cette solution a un désavantage, c'est que la gestion des inputs (et tout le reste) est donc dépendant du framerate. Il faut bien comprendre que le jeu vidéo est une succession d'image calculées à un instant t, et non un rendu d'une scene se déroulant en continue. C'est à dire que si une entité A se trouve à une position (x, y, z) à la frame 0, et qu'elle se déplace à la position (x', y', z') sur la frame 1, même si IRL elle serait passé par toutes les positions intermédiaires, dans le jeu vidéo, l'entité se téléporte. De la même façon, si tu fait une action début de frame, il faudra que tu attendes la frame suivante pour observer la réaction. Donc si tu es à 30fps, tu auras potentiellement 33ms de latence à ajouter à la latence de ta souris, ton écran etc.

Si le CPU pouvait tenir la charge de calcul pour 60 FPS par exemple, et que le game engine était désynchronisé de la partie graphique à 30FPS, alors le jeu pourrait calculer 2 scène pour 1 rendu. L'input lag baisserait donc à 16ms même si on ne verrait visuellement les conséquences de l'action que 33ms après. Cela augmenterait probablement le sentiment de fluidité, même à 30 FPS.

Maintenant effectivement, il est probable que la différence de sensation soit plus difficile à percevoir au dela de 60FPS (donc un retard de 8ms à l'affichage pour du 120FPS). Pour rappel, les téléviseurs ont souvent une latence de 40ms.

J'ai eu l'occasion de jouer à Overwatch sur un téléviseur 120hz et je voyais pas vraiment de différence entre le jeu réglé à 60fps et à 120fps.

Donc effectivement je pense qu'au delà de 60 fps on voit plus trop la différence visuellement.

Maintenant, cela est peut être du au fait que je jouait sur téléviseur avec la latence dont tu parles.

Hum… je ne suis pas tout à fait certain que les moteurs de jeu fonctionnent de cette façon (en "séparant" le "Game Engine" du "Render Engine") : tout à l'air d'être intégré au "Render Engine" qui s'occupe de tout faire "en même temps" (en fonction des infos qui lui sont données).

Quant à l'Adaptive Sync, c'est quelque chose "d'indépendant" du rendu car c'est un traitement qui se fait après en lissant le nombre de frames qui sont envoyées de la carte graphique vers l'écran afin d'éviter certains problème (tearing, stuttering, etc.) lorsque le framerate est trop faible… cf., en autre, ce dossier.

@Niko300 : à moins d'avoir jouer sur une TV compatible Adaptive Sync, le "120Hz" ou plus des TV n'a rien à voir avec la fréquence réelle de la TV : c'est un système pour améliorer la netteté des mouvements (c'est lui qui donne l'effet "caméscope" dans les films). Du coup, jouer sur une TV de ce type revient à jouer sur un écran @60Hz... avec tous les inconvénients de la TV (temps de réponse généralement trop élevé pour jouer, etc.).

Quand je parle de moteurs séparés je parle en réalité de librairies, ces librairies tournent généralement sur des threads séparés. Et en général, on a une librairie dédiée au rendering, une autre pour le online, une autre pour la ui, une autre pour le gameplay etc. Et ces librairies communiquent ensembles. Chaque librairie (ou engine) apparait de l'exterieur (donc pour les autres librairies) comme une boite noire qui expose une liste de fonctionnalités (par exemple la méthode "Tick").

Je simplifie à outrance et il est possible qu'un engine programmeur ait de grands yeux en lisant ca, mais je pense que l'idée est là.

Ainsi moins il y'a de lien entre les différentes librairies, plus elles apparaîtront comme séparées. Hors diminuer le nombre de liens, c'est mieux architecturalement parlant (ca permet entre autre de remplacer tout une librairie en cas de besoin sans avoir a repasser sur tout le code du jeu mais simplement sur les quelques liens), mais c'est plus complexe à mettre en place.

Je ne parlais d'adaptive sync (et autres options de sync) que pour illustrer mon propos avec une analogie. En réalité l'architecture d'un jeu et la synchro entre PC et moniteur n'ont absolument aucun lien.

très honnêtement je pense que ca dépend de chaque moteur, et que la plus part du temps, les devs ne font pas la désynchronisation entre les renderring et le reste car très contraignante.

Mais si un dev passe dans le coin pour nous dévoiler les secrets du moteur sur lequel il travaille...

@Niko300 :comme le dit S@m, un moniteur qui recoit un flux de 120FPS affichera 120FPS. Une TV n'est pas capable de recevoir 120FPS. La mienne par exemple ne peut recevoir que 50 ou 60Hz au choix via le port HDMI. Mais en activant une option, la TV peut retravailler l'image, en interpolant les positions des éléments en mouvement et réduire le blur.

J'en déduis (à confirmer) que:

option désactivée: la CG va envoyer la frame F0 à l'instant t0, la TV va afficher la frame F0 à l'instant t0 -> pas de latence

option activée: la CG va envoyer la frame F0, la TV va décomposer cette frame en 2 frames F'0 (affichée à l'instant t0) et F'1/2 (affichée entre la frame t0 et t1 donc à t1/2). Elle affichera donc la frame avec les positions finales de F0 à l'instant t1/2. Le délai entre les frames F'0 et F'1/2 étant de 1/120=8ms, on aura donc 8ms de délai en plus.

A voir si il est préférable d'ajouter une latence supplémentaire à l'affichage ou s'il vaut mieux rester à 60 vrais FPS. Pour un film, c'est sur qu'il vaut mieux du délai, mais pour du jeu, je pense que ca dépend de la sensibilité de chacun.

je reviens pour te donner les résultats sur the division 2. Tu me demandais quelles étaient les FPS sans la limite de framerate:

Je suis en Ultra DX12 AAx4 (donc pas x16) et j'oscille entre 55 et 75 FPS selon ou je me situe sur la map (à en croire le compteur de FPS intégré à UPlay).

J'essaierai de lancer un benchmark dans ce style ce soir si j'y pense:

https://www.youtube.com/watch?v=20isnhFmxac

-
Edité par fred1988 2 avril 2019 à 19:29:37