Jump to content
  • Advertisement
Sign in to follow this  
moleary

When are Game Object Run

This topic is 4868 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How do typical games structure when their objects are run? For example, does physics, AI, input, .... get run every frame? Or are some objects run more frequently? Also, do games typically run as fast as possible and hog CPU cycles? If not, do they specify a certain percentage of time to sleep per second? I just don't see how to let the card render everything as many times per second without either being a CPU hog or specifying some sleep time per second. Thanks for any help.

Share this post


Link to post
Share on other sites
Advertisement
It really depends on the game. Some commercial games will split various things into threads (Such as the rendering, physics, input, networking, etc.). This will allow each thread to run as fast as possible. This means that if your GPU can only output 4 FPS, the game canstill send networking packets and check input at a higher rate.

Most games that I know of will probably just try to eat up as much CPU time as possible. Of course, you could enable vsync (some games may artiicialy limit as well).

Share this post


Link to post
Share on other sites
Typically, if vsync is off, the game will run as fast as possible to get the highest possible frame rate. If vsync is on, the game will only run the main loop 60 times per second (or whatever your rate is), but the CPU will instead be spent inside the graphics driver, polling for the vblank status while waiting for a swap.

Some games don't implement interpolated rendering, and thus can only render once per physics step, and with a fixed physics step, there's a fixed maximum FPS. Some of these games will detect if there's time "left" in a time slot, and may attempt to sleep by calling ::WaitForMultipleObjectsEx() (so it's alertable), or ::usleep() (on Linux).

There are some problems with sleeping, though:

* If you're on a laptop, calling Sleep signals the CPU to slow down, which leads to sucky performance for the game -- you may want to sleep a little bit, but the CPU may slow down to 1/4 of the regular speed.

* If you're on DOS-based Windows (ME or 98), sleeping has really horrible actual resolution. You may easily find yourself waking up 40 milliseconds later, even if you asked for only 7 milliseconds of sleep.

* If you call ::Sleep() (instead of WaitForMultipleObjects with alertable sleep) then response to user stimuli (mouse input, etc) may be sluggish.

* Even on NT-based Windows, some low-priority compute-bound process may be given the CPU, and take a while to actually rescind the CPU, because the scheduling quanta is much coarser than your typical timer quanta.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!