I'm going through this book called "Introduction to 3d Game Programming with DirectX (by Frank Luna). And I've noticed that my applications, no matter what I write, take up all the CPU (to 99%).. The thing is, I'm not sure why.. I'm also using the utility code provided with the book. The first thing I thought, was the message proc., since the function of getting the time (timeGetTime();) between the frames ("timeDelta") has to run many times in one second (depends on refresh rate). So I erased the time getting functions in the utility codes (got rid of "timeDelta"). Then I got it compiled again (the testing app.), and surprisingly almost nothing changed - well, except it couldn't sync the animation translations in right timing, since i got rid of "timeDelta" :P. I'm nothing near pro, which is why I'm already out of ideas why could it be.. A) Cause that's the way DirecX works..? (I really don't think it's this one, when I was working with openGL, it took CPU only for mathematic calculations or user input - which makes sense to me) B) Something about the Utility code provided with the book..? (This is more likely.. but what could it be..? :)) ..any idea..? C) Something else..? _________________________________________.

Your program is just a big loop that processes input, does rendering, etc with each itteration of that loop and therefor will use up as much cpu time as the OS will give it.

DirectX does allow you to set the rate of rendering to the refresh rate of the screen which will usually lower the amount of processing the program will use.

Darren

I believe there are two things.

1) To avoid 99% CPU usage, though I'm not sure if it will work, try calling sleep(0). This will let the OS know that other threads may process as well.

2) To make correct animations, using time differences (timeDelta) is the best method.

Oh.. yeah.. that's it!
The reason why it didn't take the cpu on my openGL app.s is because glut has this two separate functions. One is glutDisplayFunc() and glutIdleFunc().
Everyone talks how easier is to write openGL than DirecX.. The only reason is the utility toolkit.. I think everyone should have noticed that already, in which case the question goes to.. Microsoft! :) Why the hell can't you write toolkit good as the one from openGL..? (I've seen some DXUT files inside DX SDK, but how good is that..?)
+ If I remember right, the glut is not open source, so I won't be able to see the trick.. so.. sh#%&! what now..? :)

okay.. this is the msg loop func. in the utility.cpp:
----------------------------------------------------------------
int d3d::EnterMsgLoop( bool (*ptr_display)(float timeDelta) )
{
MSG msg;
::ZeroMemory(&msg, sizeof(MSG));

static float lastTime = (float)timeGetTime();

while(msg.message != WM_QUIT)
{
if(::PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
{
::TranslateMessage(&msg);
::DispatchMessage(&msg);
}
else
{
float currTime = (float)timeGetTime();
float timeDelta = (currTime - lastTime)*0.001f;

ptr_display(timeDelta);

lastTime = currTime;
}
}
return msg.wParam;
}
----------------------------------------------------------------

I was thinkin of going with the sleep(0); first, but I'm not sure how..

I think that this issue sources from the general architecture of a game application.As one of the users says above,in the heart of the game lies an infinite loop.It must check for user inputs and render the screen when needed to,as quickly as possible..It is not a standard event-driven Windows program which sits and waits for Windows messages to do something meaningful..

I just made an experiment with this code:

int main(int argc, char *argv[])
{
while(true)
{
int x=5;
int y=6;
int z=x+y;

}
return EXIT_SUCCESS;
}

It is just an infinite loop,doing trivial calculation in every iteration and it eats %90 of my CPU time according to Task Manager.I use here an antiquated P4 1.7 Ghz.With one of those new multi-core processors, it would possibly take something near to %(100/number of processor cores).I have a hyperthreaded P4 2.8 Ghz at home and such loop-programs take %45-50 of the CPU for example..If used with good implemented multithreading,these things can create miracles,I believe..(Never tried it,tough)

And lasty,I think this is not a big problem,when running a serious game application,fullscreened, the system should spend the vast majority of its potential to it.Because what the user expects to run smoothly is "the game" at that moment,not the msn messenger at the background for example..

Quote:Original post by Sc4Freak
In a game, taking up 100% CPU time is common and desired in most cases. The user probably won't be doing something else while running your game, but will want as much performance he can get. Intentionally making your game run slower to decrease CPU usage seems silly, IMO.

Yeah.. When I think about it, makes sense..
I think I got my answer then..

Thanks everyone for taking your time.