J'écris actuellement un jeu en utilisant C ++ et SDL2 et il y a une chose que je me demande - est-il judicieux de limiter mes images par seconde (FPS) et / ou mes mises à jour par seconde (UPS)?
J'ai l'idée que si vous limitez l'onduleur, vous contrôlez essentiellement la vitesse du jeu - si le joueur se déplace de 1px par mise à jour et que vous le mettez toujours à jour 30 fois par seconde, il se déplacera à une vitesse de 30px / s et vous va probablement aussi soulager le CPU car le nombre de calculs par seconde diminue. Si vous limitez le FPS, le nombre d'appels par seconde diminue, vous soulagez donc votre GPU. J'espère avoir bien compris tout cela, sinon, n'hésitez pas à me corriger.
Ma question est - que suis-je censé limiter dans mon jeu? FPS? UPS? Tous les deux? Ni? Existe-t-il une autre meilleure approche? Comment cela se fait-il dans la plupart des jeux et pourquoi?
Les réponses sont grandement appréciées!
Réponses:
Oui, cela a du sens.
Comme vous l'avez dit, cela fera moins de charge sur le système, ce qui est bon pour les thermiques et d'autres applications.
Cependant .... La logique de vos jeux ne devrait PAS dépendre des mises à jour par seconde. Par conséquent, je vous recommande de jeter un œil à deltatime, ce qui rendra votre jeu indépendant des mises à jour par seconde.
Je vous recommande de jeter un oeil à cette question. Il explique assez bien comment le calculer et l'utiliser. Comment obtenir et utiliser le temps delta
J'espère que cela a aidé!
la source
La meilleure réponse est: cela dépend .
Vous n'avez pas à limiter ni l'un ni l'autre
Mises à jour : si vos mises à jour ne sont pas liées à une limite supérieure, la logique du jeu doit dépendre d'une durée delta , pour éviter d'exécuter le jeu plus rapidement ou plus lentement selon la machine sur laquelle il est exécuté. C'est une approche très courante utilisée par de nombreux jeux, mais ce n'est pas la seule.
Rendu : si le rendu n'est pas lié à une limite supérieure, le tampon d'image peut être présenté dans un état incomplet ou erroné, provoquant des artefacts de déchirure . C'est pourquoi de nombreux jeux utilisent la synchronisation verticale (v-sync)
Vous pourriez limiter les deux
Mises à jour : Certains jeux utilisent des pas de temps fixes pour tout ou partie de ses systèmes de jeu. Cette approche fonctionne exactement comme vous l'avez décrit. Le nombre de mises à jour par seconde est limité à une limite supérieure pour garantir que les choses ne bougent pas trop vite sur une machine de premier ordre. Cela supprime le besoin de synchronisation delta. Certaines applications sont meilleures avec des pas de temps fixes, d'autres avec un timing delta. Le choix de l'approche dépendra entièrement de ce que vous essayez exactement de réaliser. Le livre en ligne GameProgrammingPatterns comporte un chapitre consacré aux boucles de jeu qui touche aux deux architectures.
Rendu : les images par seconde doivent être définies sur une limite supérieure pour éviter le problème de déchirement mentionné ci-dessus, cependant, votre application ne doit pas tenter de le faire manuellement avec un certain verrouillage du processeur. Activez plutôt v-sync et laissez le matériel sous-jacent se synchroniser avec le taux de rafraîchissement du moniteur. En faisant cela, votre jeu sera compatible avec les futurs moniteurs qui pourraient fonctionner sur une fréquence beaucoup plus élevée que les 60 Hz actuellement courants. Il convient également de noter que de nombreux joueurs, en particulier ceux qui utilisent le benchmarking, préfèrent toujours s'exécuter sans v-sync pour permettre la fréquence d'images la plus élevée possible. Il est donc judicieux d'autoriser ou de désactiver la fonctionnalité pendant l'exécution.
Ce que vous ne devriez pas limiter
Si votre jeu utilise une approche basée sur l'interrogation pour l'entrée utilisateur, par exemple: appelle une
getInput()sorte de mise à jour des états du contrôleur pendant l'étape de mise à jour, alors c'est mieux sinon limité. Ou s'il est limité, définissez ensuite une limite supérieure très élevée. Plus vous interrogez les utilisateurs et agissez en conséquence, plus le jeu sera réactif et fluide. Les soi-disant jeux à 60 Hz dont nous entendons parler de nos jours ne mettent pas à jour l'IA et tous les états du monde à ce rythme, certains ne rendent même pas aussi vite, mais ils interrogent l'entrée du contrôleur au moins 60 fois par seconde et mettent à jour l'avatar du joueur en conséquence. Certes, cela n'est vraiment pertinent que pour les jeux d'action rapides.la source
Il y a deux articles que vous voudrez peut-être consulter:
Fixez votre Timestep
Rendu physique interpolé
Je trouve les discussions sur les messages vraiment inestimables, mais à mon avis, cela a le plus de sens quand il y a une quantité importante de simulation physique dans le jeu. En résumé, l'idée est que la simulation devrait avoir un pas de temps fixe (sinon la physique pourrait exploser à un moment où le delta est trop grand), tandis que le rendu devrait avoir la liberté de fonctionner à la vitesse maximale possible. Afin de synchroniser les deux (la simulation et le rendu), l'état de rendu est interpolé par un facteur qui dépend de la distance entre la simulation et la mise à jour suivante (rappelez-vous que la simulation est fixe).
J'espère que cela aide.
la source