Issue with framerate limiter (inaccurate) - c

Question

The framerate limiter for this game I'm doing some coding on is having some pretty irritating accuracy issues at certain framerates. I've been scratching my head trying to think of a better way to write this, but the best I've came up with is still fairly inaccurate. I was wondering if someone could give me a couple ideas on how to rewrite this short portion to be more accurate.
//g_dwLastfps & currenttime are equal to timeGetTime()
float fFrameLimit = 0;
if (g_nFrameLimitValue > 0) //g_nFrameLimitValue = user defined
fFrameLimit = 1000 / g_nFrameLimitValue;
while ((currentTime - g_dwLastTime) < fFrameLimit)
{
// -1 = wait an extra ms. seemed to help accuracy some
Sleep((float)fFrameLimit - ((currentTime - g_dwLastTime)) - 1);
currentTime = timeGetTime();
}
g_dwLastTime = currentTime;

Answer 1

I can think of a pretty simple solution:
uint64_t last_time = 0;
uint64_t current_time = time();
uint64_t frame_limit_ms = 17; // 60fps = 16.666... ms/f
uint64_t frame_diff = frame_limit_ms;
sleep(frame_limit_ms);
while(running){
last_time = current_time;
current_time = time(); // get frame start time in milliseconds
frame_diff = current_time - last_time; // get time since last frame in ms
if(frame_diff < frame_ms_limit){
sleep(frame_ms_limit - frame_diff);
// need to do a re-calculation for accuracy
current_time = time();
frame_diff = current_time - last_time;
}
do_physics(frame_diff);
draw_scene();
swap_buffers();
}
Which looks a lot like what you have, but doesn't use float so should be faster and is accurate up to one unit of time (milliseconds in this case).
If you want it to be more accurate, use a more accurate unit (nanoseconds) and convert it back to milliseconds if you need to.

Answer 2

One issue with the example code, is that last_time get updated to current_time which gets updated to time(), which can lead to drift over time. To avoid this, last_time should be based on an original reading of time(), and advanced by the desired delay for each frame. The following windows based code is similar what is used in games to keep a thread running at a fixed frequency with no drift. uRem is used to deal with frequencies that aren't exact multiples of the clock frequency. dwLateStep is a debugging aid that gets incremented each instance where the step time is exceeded. The code is Windows XP compatible, where a Sleep(1) can take up to 2 ms, so it checks for >= 2 ms delay pending before using Sleep(1).
/* code for a thread to run at fixed frequency */
typedef unsigned long long UI64; /* unsigned 64 bit int */
#define FREQ 400 /* frequency */
DWORD dwLateStep; /* late step count */
LARGE_INTEGER liPerfFreq; /* 64 bit frequency */
LARGE_INTEGER liPerfTemp; /* used for query */
UI64 uFreq = FREQ; /* process frequency */
UI64 uOrig; /* original tick */
UI64 uWait; /* tick rate / freq */
UI64 uRem = 0; /* tick rate % freq */
UI64 uPrev; /* previous tick based on original tick */
UI64 uDelta; /* current tick - previous */
UI64 u2ms; /* 2ms of ticks */
UI64 i;
/* ... */ /* wait for some event to start thread */
QueryPerformanceFrequency(&liPerfFreq);
u2ms = ((UI64)(liPerfFreq.QuadPart)+499) / ((UI64)500);
timeBeginPeriod(1); /* set period to 1ms */
Sleep(128); /* wait for it to stabilize */
QueryPerformanceCounter((PLARGE_INTEGER)&liPerfTemp);
uOrig = uPrev = liPerfTemp.QuadPart;
for(i = 0; i < (uFreq*30); i++){
/* update uWait and uRem based on uRem */
uWait = ((UI64)(liPerfFreq.QuadPart) + uRem) / uFreq;
uRem = ((UI64)(liPerfFreq.QuadPart) + uRem) % uFreq;
/* wait for uWait ticks */
while(1){
QueryPerformanceCounter((PLARGE_INTEGER)&liPerfTemp);
uDelta = (UI64)(liPerfTemp.QuadPart - uPrev);
if(uDelta >= uWait)
break;
if((uWait - uDelta) > u2ms)
Sleep(1);
}
if(uDelta >= (uWait*2))
dwLateStep += 1;
uPrev += uWait;
/* fixed frequency code goes here */
/* along with some type of break when done */
}
timeEndPeriod(1); /* restore period */