since the forums a bit quiet at present ill ask a non urgent question, wheres the best place to stick a pause function in the loop, so my app doesnt takeup 100% of cpu cycles.
with readpixels it seems to be after i call swapbuffers (looking at some comments in my code, i dont call readpixels anymore so im not 100% certain if this is correct)
there are 4 options that i can see
before/after swap
before/after clear
ta zed
After swapbuffers should be the best, as it takes advantage of the CPU/GPU parallelism :
-send a lot of commands to the card
-swapbuffers = implicit glFlush = returns but forces the GPU to work
-pause CPU
-loop.
Just curious, how long of a pause are we talking about here?
-SirKnight
Originally posted by SirKnight:
Just curious, how long of a pause are we talking about here?
-SirKnight
Typically not very long! For a game that gives several
tens of frames per second, and the frame rate is
constant, the maximum waiting time is just shorter
of the inverse of the frame rate. This is almost
never the case – because it takes time to render –
and it should be well under the maximum it can be
for a game that is heavy on graphics. If the frame
rate drops below the pre-specified number, that
waiting time is obviously zero!
I am sorry I am not in a position at this momment to
get some numbers for you, but they would depend on
the amount of rendering and the hardware I use, let
the coding aside…
Note, that if you are under Windows and use Sleep (1), this will be the same as Sleep (10). Windows is not very precise about that, so if you put a Sleep in your code, you will get a maximum framerate of 100.
Jan.
Why don’t you setup MM timer to trigger for example 50Hz or 60Hz. On trigger do all work…Something like this:
#define TARGET_RESOLUTION 1 // 1-millisecond target resolution
static UINT wTimerRes;
static TIMECAPS tc;
static HANDLE hEvent;
static int TimerID;
void InitTimer()
{
int ret = timeGetDevCaps(&tc, sizeof(tc));
if (ret == TIMERR_NOERROR )
{
wTimerRes = min(max(tc.wPeriodMin, TARGET_RESOLUTION), tc.wPeriodMax);
timeBeginPeriod(wTimerRes);
}
else HandleError();
}
static HANDLE SetupTimer(int ms)
{
hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
TimerID = timeSetEvent(ms, wTimerRes, (LPTIMECALLBACK)(HANDLE)hEvent, 0, TIME_PERIODIC | TIME_CALLBACK_EVENT_SET);
}
.. somewhere in your code...
InitTimer();
SetupTimer(20); // 1000/20ms = 50Hz
while( !g_bQuit )
{
// wait for timer
WaitForSingleObject(hEvent, INFINITE);
Update();
Render();
SwapBuffers(hDC);
ResetEvent(hEvent);
}
timeKillEvent(TimerID);
yooyo
Originally posted by Jan:
[b]Note, that if you are under Windows and use Sleep (1), this will be the same as Sleep (10). Windows is not very precise about that, so if you put a Sleep in your code, you will get a maximum framerate of 100.
Jan.[/b]
You get a better resolution sleep in Windows if you issue a “timeBeginPeriod(1)” in your apps startup function, and a “timeEndPeriod(1)” in your apps exit function.
what is it with this recent obession with not using 100% CPU time? 
I don’t think it’s so much about not using 100% cpu time, more to do with getting control over how much time to devote to rendering. If you make a decision to render at 60hz, then if your scene is of modest complexity and your hardware is of modest power, you’re not going to be using 100% of the cpu. So, by throttling your render loop to 60hz you’re freeing up the cpu to do other things, such as physics, haptics blah blah blah. Whereas if you let your render loop run full pelt, with vsync disabled, without any kind of sleep to give other threads cpu time…
Originally posted by bobvodka:
what is it with this recent obession with not using 100% CPU time?
in my case, the summers finally arived, 30+ degrees inside (prolly lots higher inside the cupboard i keep the computer in) thus as im a fully paid up member for spcc (society for provention of cruelty to computers) i dont wanna cause here undue suffering