Est-il normal qu'un jeu utilise 100% de CPU?

Je viens d'implémenter la gestion des entrées multithread dans mon moteur de jeu où le code qui interroge le système d'exploitation pour en collecter les entrées et les horodater est dans un thread séparé et chaque image du thread principal je mange juste les entrées rassemblées jusqu'à un temps de jeu logique. Tout fonctionne, mais cette configuration utilise 100% de mon processeur. J'ai deux cœurs, et cela va jusqu'à 100% lors de l'exécution de mon jeu.

J'ai vérifié avec d'autres jeux pour voir s'ils le faisaient aussi. Par exemple, Skyrim et Doom 3 semblent bien avec un peu plus de 60% de CPU.

Est-il acceptable qu'un jeu qui utilise une entrée multithread utilise jusqu'à 100% de CPU? Sinon, quelles astuces ces jeux utilisent-ils pour réduire l'utilisation du processeur par le thread d'entrée?

Oui, c'est normal pour un jeu en temps réel d'essayer d'utiliser 100% CPU pour fonctionner aussi vite et aussi bien qu'il le peut. Ainsi, ce joueur voit autant d'images par seconde ou une bonne simulation physique ou toute autre chose que son PC peut fournir.

Dans votre cas - Non, cela ressemble à une conception inefficace, pour prendre un thread et le faire interroger pour les événements dans une boucle ( while true do CheckForEvents;). Corrigez-moi si je me trompe, mais OS interroge déjà les événements. Vous devez simplement les vérifier à partir de votre fil principal une fois par tick.

La boucle de jeu principale doit être suffisamment rapide pour fonctionner à plus de 30 ticks par seconde, ce qui est assez suffisant pour les commandes d'interrogation de nombreux jeux. Le joueur ne verra pas de différence si ses commandes sont traitées, par exemple 0-33 ms plus tard. D'un autre côté, vous auriez pu utiliser ce cœur de processeur supplémentaire pour des tâches plus bénéfiques, comme beaucoup plus d'intelligence artificielle ou de physique ou autre.

PS Comme demandé pour clarifier dans les commentaires, ne prenez pas aveuglément les chiffres ci-dessus pour tous les types de jeux. Alors que le jeu TBS pourrait avoir besoin d'un seul tick par tour et que le jeu RTS pourrait bien fonctionner avec 10 ticks par tour, d'autres genres, comme RaceSims, ont besoin de beaucoup plus. Et bien sûr, ne liez pas les tics logiques avec le framerate, ce sont deux choses distinctes.

Un jeu avec une actualisation constante de la fenêtre active sera principalement exécuté en mode plein écran et sera le seul (gros) programme de la machine géré par le système d'exploitation. Il est donc tout à fait acceptable d'utiliser 100% du CPU, car rien d'autre ne devrait en avoir besoin.

Cependant , cela ne signifie pas bien sûr que vous devez toujours utiliser 100% quel que soit votre état de jeu. La plupart des boucles de jeu utilisent une méthode de veille comme délimiteur de fréquence d'images si elles ont fini de rendre une image avant la limite de fréquence d'images, afin de ne pas utiliser le processeur pour rien.
C'est probablement ce qui se passe dans vos exemples: votre machine est plus rapide que Skyrim ou Doom 3 ne doit fonctionner, donc ils n'utilisent que ce dont ils ont besoin - mais tout ce dont ils ont besoin.

Comme l'a dit @KromSterm, le système d'exploitation interroge généralement déjà les événements pour vous, il n'est donc pas nécessaire de faire une boucle plus rapidement que celle du système d'exploitation. Si vous n'avez que deux cœurs, utiliser 100% du second uniquement pour la détection d'événements n'est pas une bonne idée, car si vous transférez uniquement des événements vers la boucle de mise à jour principale, son exécution est très rapide. Vous devriez essayer d'utiliser ce noyau pour une partie du travail de thread principal avec un autre thread à la place.

Il y a quelques inconvénients à viser à utiliser tout le temps CPU disponible dans un jeu PC ou mobile.

Configuration requise: si le jeu est jouable sur le PC sur lequel vous développez votre jeu, il peut ne pas être jouable sur un PC plus faible appartenant à quelqu'un qui a acheté votre jeu. Limiter l'utilisation du processeur gardera un jeu utilisable sur des machines que plus de gens sont susceptibles d'avoir déjà. Si vous voulez vraiment voir si vous limitez votre marché, testez vos jeux PC et ceux de vos concurrents sur un détachable alimenté par Atom tel que le Transformer Book, ou testez vos jeux mobiles sur un téléphone Android prépayé peu coûteux.

Consommation d'énergie: un ordinateur portable décharge sa batterie plus rapidement lorsque quatre cœurs sont utilisés à 100% de la fréquence maximale que lorsque, disons, deux cœurs sont utilisés à 60% de la demi-fréquence. Assurez-vous donc que votre thread d'interrogation de contrôleur, votre thread AI, votre thread physique et votre thread graphique sont bloqués jusqu'à ce qu'il soit temps de les exécuter à nouveau. Sauf dans quelques genres très capricieux, tels que les combats et le rythme, vous n'aurez pas besoin d'interroger les contrôleurs plus rapidement qu'environ 60 Hz, alors configurez votre fil d'interrogation pour qu'il s'exécute sur une minuterie de 60 Hz.

Variabilité physique: si la physique qui affecte le gameplay est plus détaillée sur des machines plus puissantes, la même action de joueur aura des résultats différents sur différentes machines. Cela signifie que le joueur peut tricher en utilisant une machine plus forte ou plus faible. Id's Quake III Arena est connu pour avoir une fréquence d'images affectant la hauteur de saut . Pour éviter cela, de nombreux jeux utilisent un pas de temps fixe pour la physique. Mais cela n'affecte pas la physique déconnectée du gameplay, comme les effets de particules ou les effets de tissu ou l'interpolation des coordonnées entre les images physiques pour rendre la vidéo à une fréquence d'images plus élevée que la physique. Concevez donc votre physique en utilisant une variante de modèle-vue-contrôleur l'architecture, où les choses essentielles (accélération, détection de coups, etc.) vont dans le modèle et les bonbons pour les yeux réglables vont dans la vue.

Variabilité de l'IA: si l'IA est plus détaillée sur des machines plus puissantes, les ennemis se comporteront différemment sur différentes machines. Par exemple, dans une implémentation Go ou Chess, l'adversaire sera plus faible sur un PC plus faible, et les joueurs peuvent tricher en jouant au jeu sur un PC plus faible ou en exécutant des processus d'arrière-plan tels que l'antivirus ou le transcodage vidéo ou les mises à jour du système d'exploitation.