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.