É normal que um jogo use 100% da CPU?

Acabei de implementar a manipulação de entradas multithread no meu mecanismo de jogo, em que o código que consulta o sistema operacional para coletar as entradas e os carimbos de data e hora está em um thread separado. hora do jogo lógico. Tudo funciona, mas esta configuração está usando 100% da minha CPU. Eu tenho dois núcleos, e está subindo para 100% durante a execução do meu jogo.

Eu verifiquei com outros jogos para ver se eles fazem isso também. Por exemplo, Skyrim e Doom 3 parecem estar bem com pouco mais de 60% da CPU.

É aceitável que um jogo que use entrada multiencadeada use 100% da CPU? Caso contrário, quais são alguns truques que esses jogos usam para diminuir o uso da CPU pelo thread de entrada?

Sim, é normal que um jogo em tempo real tente usar 100% da CPU para executar o mais rápido e bom possível. Para que o jogador veja o máximo de quadros por segundo ou a boa simulação física ou qualquer outra coisa que seu PC possa fornecer.

No seu caso - Não, isso parece um design ineficiente, para pegar um encadeamento e fazê-lo pesquisar eventos em um loop ( while true do CheckForEvents;). Corrija-me se estiver errado, mas o SO já vota os eventos. Você deve apenas checá-los no seu thread principal uma vez a cada tick.

O loop principal do jogo deve ser rápido o suficiente para rodar a mais de 30 ticks por segundo, o que é suficiente para pesquisar comandos em muitos jogos. O jogador não verá diferença se seus comandos forem processados, por exemplo, 0-33ms depois. Por outro lado, você poderia ter usado esse núcleo extra da CPU para tarefas mais benéficas, como MU melhor IA ou física ou o que quer.

PS Conforme solicitado para esclarecer nos comentários, não tome os números acima cegamente para todos os tipos de jogos. Enquanto o jogo TBS pode precisar de apenas 1 tick por turno e o jogo RTS pode ser bom com 10 ticks por turno, outros gêneros, como o RaceSims, precisam de muito mais. E, é claro, não vincule os ticks lógicos à taxa de quadros, essas são duas coisas separadas.

Um jogo com uma atualização constante da janela ativa será executado principalmente no modo de tela cheia e será o único (grande) programa da máquina gerenciada pelo sistema operacional. Portanto, é totalmente aceitável usar 100% da CPU, porque nada mais precisa disso.

No entanto , isso não significa, é claro, que você sempre deve usar 100%, independentemente do estado do jogo. A maioria dos loops de jogo usa um método sleep como um delimitador de taxa de quadros se eles terminarem de renderizar um quadro antes do limite da taxa de quadros, para não fazer com que a CPU seja usada para nada.
Provavelmente, isso é o que acontece nos seus exemplos: sua máquina é mais rápida do que o Skyrim ou o Doom 3 precisam executar, portanto, eles usam apenas o que precisam - mas tudo o que precisam.

Como o @KromSterm disse, o SO geralmente já realiza pesquisas para você, portanto, não há necessidade de fazer um loop mais rápido que o do SO. Se você tiver apenas dois núcleos, usar 100% do segundo apenas para detecção de eventos não é uma boa ideia, porque se você transferir apenas eventos para o loop principal de atualização, é muito rápido executar. Você deve tentar usar esse núcleo para uma parte do trabalho de thread principal com outro thread.

Existem algumas desvantagens de tentar usar todo o tempo disponível da CPU em um PC ou jogo para celular.

Requisitos do sistema: se o jogo puder ser reproduzido no PC em que você desenvolve o jogo, ele poderá não ser jogável em um PC mais fraco, de propriedade de alguém que comprou o jogo. Limitar o uso da CPU manterá um jogo utilizável em máquinas que mais pessoas provavelmente já possuem. Se você realmente deseja saber se está limitando seu mercado, teste seus jogos para PC e os de seus concorrentes em um destacável equipado com Atom, como o Transformer Book, ou teste seus jogos para celular em um telefone Android pré-pago e barato.

Uso de energia: um laptop consome a bateria mais rapidamente quando quatro núcleos são usados ​​a 100% da frequência total do que quando, digamos, dois núcleos são usados ​​a 60% da meia frequência. Portanto, verifique se o encadeamento de polling do controlador, o encadeamento AI, o encadeamento físico e o encadeamento gráfico está bloqueado até a hora de executar novamente. Exceto em alguns gêneros muito contorcidos, como luta e ritmo, você não precisará pesquisar os controladores mais rapidamente do que cerca de 60 Hz, portanto, configure seu segmento de polling para rodar em um timer de 60 Hz.

Variabilidade física: se a física que afeta a jogabilidade for mais detalhada em máquinas mais fortes, a mesma ação do jogador terá resultados diferentes em máquinas diferentes. Isso significa que o jogador pode trapacear usando uma máquina mais forte ou mais fraca. A Arena Quake III da Id é notória por ter a taxa de quadros afetada na altura do salto . Para evitar isso, muitos jogos usam uma etapa de tempo fixo para a física. Mas isso não afeta a física desconectada da jogabilidade, como efeitos de partículas ou efeitos de tecido ou interpolação de coordenadas entre os quadros da física para renderizar o vídeo com uma taxa de quadros maior que a física. Portanto, projete sua física usando alguma variante do model-view-controller arquitetura, onde coisas essenciais (aceleração, detecção de ocorrência e similares) entram no modelo e visual candy ajustável é visualizado.

Variabilidade da IA: Se a IA for mais detalhada em máquinas mais fortes, os inimigos se comportarão de maneira diferente em máquinas diferentes. Por exemplo, em uma implementação de Go ou Chess, o oponente fica mais fraco em um PC mais fraco, e os jogadores podem trapacear jogando o jogo em um PC mais fraco ou executando processos em segundo plano, como antivírus ou transcodificação de vídeo ou atualizações do sistema operacional.