Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers. Visit Stack Exchange

Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.

Sign up to join this community

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

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?

\$\begingroup\$ So what you say, you basically have a thread with an endless while loop that constantly polls the OS for new events? while true do CheckForEvents; \$\endgroup\$ – Kromster Sep 25, 2015 at 5:19 \$\begingroup\$ If an application uses 100% of the CPU time regardless of usage and CPU speed, then it could rightfully be considered a bug. You shouldn't use more CPU time than needed to render a frame per monitor refresh cycle. \$\endgroup\$ – kasperd Sep 25, 2015 at 11:56 \$\begingroup\$ @TheLightSpark Does the polling thread not even sleep? If you are constantly looping and checking without sleeping you're probably gonna eat up a lot more CPU time than is necessary. \$\endgroup\$ – Luke Sep 25, 2015 at 15:35 \$\begingroup\$ Re @Luke: Even sleeping just a milisecond between polls will drastically reduce CPU usage. A while back, I wrote a GUI for a command line tool that took an input file and made an output file roughly the same size. To estimate the percentage, I read the file size of the output file and updated the progress bar (using while (true) ). Used 90%+ of one CPU to do so. Added a Thread.Sleep(5) to it brought CPU usage down to under 40%. Going to 25 milliseconds between polls brought it down to under 10%. \$\endgroup\$ – Cole Tobin Sep 26, 2015 at 5:34 \$\begingroup\$ @AlecTeal I think you did not pay enough attention to what I said. Rendering better graphics is not the same usage, and of course enabling better graphics will increase CPU consumption. But if switching to a faster CPU would cause your code to just spend more cycles producing the exact same result, your code is flawed. Automatically measuring what quality of graphics can be rendered with a specific CPU is a sensible default. But you should allow users to choose in case they are running on battery power or also need CPU for background jobs. \$\endgroup\$ – kasperd Sep 26, 2015 at 19:57 \$\begingroup\$

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.

\$\begingroup\$ I would upvote this question, but then I see you recommend 30 ticks per second. IMHO (and those of many other gamers), you should aim for 60 ticks (and thus 60 frames) per second. 60 FPS for many people looks more fluid, plays more responsive and is less likely to give a certain subset of users motion sickness. \$\endgroup\$ – Nzall Sep 25, 2015 at 20:48 \$\begingroup\$ @NateKerkhofs: I came from RTS background, where 10 ticks is usual. It's a broad world, I'll add details about that. Thanks for pointing out. \$\endgroup\$ – Kromster Sep 26, 2015 at 4:37 \$\begingroup\$ @KromStern: I can't speak for Nate entirely, but the third paragraph could be interpreted as "30hz should be your target" though it could also be interpreted as "30hz is the minimum you can tolerate" (which may be what you meant). \$\endgroup\$ – Sean Middleditch Sep 26, 2015 at 19:05 \$\begingroup\$ Using 100% CPU is terrible practice. You're screwing over laptop users for stuff that doesn't in any way, shape or form need to use 100% CPU. Code a proper game loop that can feed frames to the monitor efficiently. \$\endgroup\$ – Chris Dennett Jun 22, 2017 at 21:11 \$\begingroup\$

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.

\$\begingroup\$ "use a sleep method" - am I right in thinking that this is known as a framerate limiter? \$\endgroup\$ – Gusdor Sep 25, 2015 at 12:26 \$\begingroup\$ sleep is not accurate method of frame limiting, if the goal is to limit frames to monitor refresh rate, then the better is to use hardware-supported vsync (or nvidia's g-sync, if available) \$\endgroup\$ – Display Name Sep 26, 2015 at 6:59 \$\begingroup\$

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.

\$\begingroup\$ +1 for Power Use. Especially as you should consider the mobile and tablet industry, where this is extremely important. \$\endgroup\$ – akaltar Sep 26, 2015 at 12:08 \$\begingroup\$ Power use affects noise, too, even on desktops. It's common for modern desktops to keep their fans slow & quiet when the system is cool. Also, maybe the user is encoding a video (at low priority) while playing, so any spare CPU time isn't being wasted. Or for players streaming to twitch, leaving more cycles for video encoding is a big deal, and enables higher-quality video. (video encoding is a three-way tradeoff between CPU time, bitrate, and quality, so more CPU time means real-time encoding at higher quality at the same bitrate.) \$\endgroup\$ – Peter Cordes Jul 23, 2016 at 2:35 \$\begingroup\$ Power use should be the primary consideration, all other considerations secondary, IMHO. The only thing I would use 100% CPU for (if it really helped!) is VR stuff. \$\endgroup\$ – Chris Dennett Jun 22, 2017 at 21:13