Grand FPS vs FPS cohérent

Lors de l'optimisation de la fréquence d'images d'un jeu, quand dois-je me concentrer sur un grand FPS et quand dois-je me concentrer sur une fréquence d'images cohérente.

C'est souvent un problème très contesté, alors veuillez noter que je ne demande pas lequel est le meilleur.

Quels sont les avantages et les inconvénients de chacun?
Dans quelles situations est-on préféré à l'autre?

Notez également: mes taux d'interrogation / traitement d'entrée, de physique et de mise à jour du jeu sont indépendants de ma fréquence d'images. La seule chose que le FPS affecte est la fréquence de rendu d'un écran.

C'est subjectif, bien sûr, mais je pense que la cohérence est beaucoup plus importante pour le jeu que la vitesse.

Fondamentalement, les joueurs toléreront une fréquence d'images plus lente si le jeu est cohérent, amusant à jouer et sans secousses. Cependant, même si le jeu bascule totalement, s'il donne aux gens des maux de tête à regarder parce qu'il éclate et / ou qu'ils ne peuvent pas contrôler les choses, ils deviendront agacés et arrêteront de jouer.

Donc...

Concentrez-vous sur un FPS cohérent tout au long de la conception et du développement.

Concentrez-vous sur des FPS plus rapides (mais toujours cohérents) lorsque le jeu est presque terminé, et vous avez le temps d'améliorer les performances sans vous soucier des corrections de bugs, etc.

Une façon d'obtenir de meilleures performances consiste à utiliser des rappels / délégués / interruptions (selon votre langue / plate-forme) plutôt que d'interroger.

Ce que tu devrais faire:

• Verrouillez la logique du jeu sur une fréquence d'images fixe
• Rendez les graphiques aussi rapidement que possible

De cette façon, si le taux de rafraîchissement diminue, vous n'obtenez pas de décalage d'entrée (je vous regarde, Just Cause 2), et si le taux de rafraîchissement devient trop élevé (pensez aux jeux des années 90), le jeu ne devient pas injouable.

Voici comment je le fais:

s_PhysicsCurrent = GetTickCount();
float delta = (float)(s_PhysicsCurrent - s_PhysicsStart);
s_PhysicsStart = s_PhysicsCurrent;

s_PhysicsTime += delta;

while (s_PhysicsTime > ONEFRAME)
{
    // Update
    Game::Tick(ONEFRAME);

    // Clear input
    Keyboard::Clear();
    Mouse::Clear();

    s_PhysicsTime -= ONEFRAME;
}

s_Window->Clear();

Game::Render();

s_Window->Swap();

Vous collectez essentiellement une "pile" d'images pour faire la logique et vous pouvez interpoler parfaitement entre elles.

Il semble que vous ayez au moins deux threads d'exécution, avec votre rendu sur son propre thread. Si tel est le cas, vous devez vous inquiéter de deux fréquences d'images. Vous voudrez que les deux soient aussi rapides que possible. Cependant, cela dépend aussi du type de jeu que vous construisez.

Construisez-vous un jeu de tir à la première personne, où de petites baisses de la fréquence d'images pourraient donner un avantage à un adversaire? Si oui, alors vous voudrez vous assurer que votre fps moyen est suffisamment élevé, mais vous inquiétez également de vos temps de trame dans le pire des cas. Construisez-vous un jeu de société? Si c'est le cas, le pic de temps d'image occasionnel ne va pas tuer l'expérience utilisateur.

Dans mes propres jeux, mon processus ressemble généralement à ceci:

• Exécutez un profileur sur le code
• Regardez la fréquence d'images moyenne. S'il est trop bas en moyenne, augmentez les fps moyens en optimisant les choses lentes.
• Une fois que les images par seconde moyennes sont suffisamment élevées, recherchez les temps de trame les plus défavorables (les trames où vous voyez de gros pics de temps de calcul ou de rendu). Essayez d'optimiser ces scénarios dans le pire des cas pour améliorer la durée de trame dans le pire des cas.

Si vous êtes à 30 ips la plupart du temps, mais que vous montez à 200 ms toutes les 10 secondes, cela va causer des problèmes. Mais si vous êtes en moyenne de 15 fps, augmentez d'abord votre fps moyen.

Donc, la réponse courte serait probablement: optimiser tout ce qui apporte la plus grande amélioration à l'expérience utilisateur en premier.

Verrouiller votre FPS sur un nombre cohérent vous permet de:

• Maintenir une apparence visuelle fluide
• Gardez les animations en cours d'exécution dans le temps linéaire, les objets physiques tombant à un taux constant entre les images, etc.
• Cependant, la partie la plus utile du verrouillage de votre FPS est que sur les images où vous avez un certain temps d'arrêt, vous pouvez effectuer d'autres travaux - collecter les ordures, travailler sur la diffusion dans la prochaine zone de la carte, etc. et vous aurez une certaine marge lors du rendu quelque chose de grand et brillant ou en faisant tomber une pile de boîtes.

Tous les deux. Je dirais idéalement, toujours plus de 60 images par seconde. De façon réaliste, toujours plus de 30 images par seconde. Moins de 30 images par seconde et cela commence à affecter la performance du joueur (je pense d'ailleurs aux jeux basés sur FPS / twitch, les jeux de stratégie peuvent probablement se débrouiller plus bas).

Si vous deviez vraiment dire l'un ou l'autre, j'irais avec cohérence. Si vous pouvez garantir une fréquence d'images, vous pouvez vous concentrer sur l'augmentation de cette fréquence d'images garantie.

Plus grand est toujours mieux, mais:

Un taux de rafraîchissement incohérent peut entraîner le mal des transports.

(Nous avons fait vomir un testeur interne lorsque son débit d'images a sauté entre 20 et 60 pendant 10 secondes.)

Je pense que vous voudriez à la fois un FPS cohérent et plus grand. Plus les graphismes sont fluides (en raison du taux de rafraîchissement), mieux c'est. S'il commence à descendre en dessous de 30FPS, vos utilisateurs vont commencer à remarquer la nervosité et seront frustrés par le manque de temps de réponse aux actions.

Si vous voulez éviter les déchirures , vous devez utiliser V-sync qui verrouillera le FPS au taux de rafraîchissement du moniteur, ou plus bas (si vous allez plus haut, il ne sera pas visible, donc ce serait un gaspillage).

Il n'y a qu'une seule réponse, et c'est .. toujours aller haut pendant le développement et lorsque votre duvet le ramène au pic le plus bas, cela amènera le jeu dans un flux régulier et malade. Je suis assis sur le code, et il y restera parce que c'est ma façon secrète de coder le dragon. / Eyhe