Is it normal for a game to use 100% CPU?

Question

I just implemented multi-threaded input handling in my game engine where the code that polls the OS to gather input from it and time stamps them is in a separate thread and each frame in the main thread I just eat up the gathered input up to a logical game time. It all works, but this set up is using 100% of my CPU. I have two cores, and its going up to 100% while running my game.

I have checked with other games to see if they do that too. For example Skyrim and Doom 3 seem to be fine with just over 60% CPU.

Is it acceptable for a game that uses multi-threaded input to use up 100% CPU? If not, what are some tricks such games use to lower cpu usage by the input thread?

Answer 1

Yes, this is normal for a real-time game to try to use 100% CPU to perform as fast and good as it can. So that player sees as much frames per second or as good physics simulation or anything else as his PC can provide.

In your case - No, this looks like an inefficient design, to take a thread and make it poll for events in a loop (while true do CheckForEvents;). Correct me if I'm wrong, but OS already polls the events. You should just check them from your main thread once every tick.

The main game loop should be fast enough to run at 30+ ticks per second, which is quite enough for polling commands for many games. Player wont see a difference if his commands get processed e.g. 0-33ms later. On the other hand you could have used that extra CPU core for more beneficial tasks, like MUCH better AI or physics or whatever.

P.S. As requested to clarify in comments, do not take above numbers blindly for all kinds of games. While TBS game could need just 1 tick per turn and RTS game could be fine with 10 ticks a turn, other genres, like RaceSims need much more. And of course do not tie logic ticks with framerate, these are two separate things.

Answer 2

A game with a constant active window refresh will mostly be ran in full-screen mode and be the only (big) program of the machine managed by the OS. So it is totally acceptable to use 100% of CPU, because nothing else should need it.

However, that doesn't means of course you have to always use 100% whatever your game state. Most game loops use a sleep method as a framerate delimiter if they finished to render a frame before the frame-rate limit, in order to not make the CPU used for nothing.
This is probably what happen in your examples: your machine is faster than Skyrim or Doom 3 need to run, so they only use what they need - but all of what they need.

As @KromSterm said, OS usually already poll events for you, so there is no need to make a loop faster than the OS one. If you have only two cores, to use 100% of the second one only for events detection is not a good idea, because if you only transfer events to the main update loop, it is very fast to execute. You should try to use this core for a part of the main thread job with another thread instead.

Answer 3

There are a few drawbacks of aiming to use all available CPU time in a PC or mobile game.

System requirements: Even if a game is playable on the PC where you develop your game, it might not be playable on a weaker PC owned by someone who bought your game. Limiting CPU use will keep a game usable on machines that more people are likely to already have. If you really want to see whether you're limiting your market, test your PC games and those of your competitors on a low-end laptop with a Pentium Silver CPU, or test your mobile games on an inexpensive prepaid Android phone.

Power use: A laptop computer drains its battery faster when four cores are used at 100 percent of full frequency than when, say, two cores are used at 60 percent of half frequency. So make sure your controller polling thread, AI thread, physics thread, and graphics thread are blocked until it's time for them to run again. Except in a few very twitchy genres, such as fighting and rhythm, you won't need to poll the controllers faster than about 60 Hz, so set your polling thread to run on a 60 Hz timer.

Physics variability: If physics that affect gameplay are more detailed on stronger machines, the same player action will have different outcomes on different machines. This means the player may be able to cheat by using a stronger or weaker machine. Id's Quake III Arena is notorious for having frame rate affect jump height (as described in "UpsetChaps Quake3 Guide - Why Your Framerate Affects Jumping"). To avoid this, a lot of games use a fixed time step for physics. But this doesn't affect physics that are disconnected from gameplay, such as particle effects or cloth effects or interpolation of coordinates between physics frames to render video at a higher frame rate than physics. So design your physics using some variant of model-view-controller architecture, where essential things (acceleration, hit detection, and the like) go in the model and adjustable eye candy goes in the view.

AI variability: If the AI is more detailed on stronger machines, enemies will behave differently on different machines. For example, in a Go or Chess implementation, the opponent will be weaker on a weaker PC, and players can cheat by playing the game on a weaker PC or by running background processes such as antivirus or video transcoding or operating system updates.