This is my first post
You could also have two (or more) threads, one for rendering the game and one for moving players, checking for collision, etc. If the rendering thread starts dropping below the desired FPS it won't slow down the "processing" thread as much as it would've. This is just a guess, but it makes sense in my head.
Anyway, I'm also making a game at the moment and I use this to prevent slowdowns:
#include <time.h>
double fpsDelayFix;
double playerVelocityX;
void DarkGDK(void)
{
SYSTEMTIME time;
while(LoopGDK())
{
GetSystemTime(&time);
float start = time.wMilliseconds;
//do player movement, et cedera, here.
//if W is being pressed, speed the player up.
//else slow them down.
if(dbKeyState(17) == 1) playerVelocityX += 0.1 * fpsDelayFix;
else playerVelocityX *= pow(0.85, fpsDelayFix);
//player velocity is to 85% to the power of fpsDelayFix.
//everything that has movement needs to be affected by 'fpsDelayFix'.
//even animation speeds will need to be adjusted in order to keep up
//when FPS gets low.
dbSync(); // refresh screen
GetSystemTime(&time);
float total;
//the 'total' variable will tell us how the this entire frame took to process
//since the wMilliseconds only tells us the ms in the current second, and not
// the ms since last called, we have to do this...
if(time.wMilliseconds > start) total = time.wMilliseconds - start;
else total = 1000 - start + time.wMilliseconds;
fpsDelayFix = 60 / (1000 / total);
// if the fps is 60, this variable will be set to 1, if it is 30 it will
//be set to 2. Meaning that the game will need to go twice as fast in order
//to run at normal speed. If the FPS is 2, the game will need to go 30 times
//as fast to make up for the lack of processing occurring each second.
}
}
if(awesome) return true;
