If you're curious, the code we use for limit is here:
void sub__limit(double fps){
if (new_error) return;
static double prev=0;
double ms,now,elapsed;//cannot be static
if (fps<=0.0){error(5); return;}
ms=1000.0/fps;
if (ms>60000.0){error(5); return;}//max. 1 min delay between frames allowed to avoid accidental lock-up of program
recalculate:
now=GetTicks();
if (prev==0.0){//first call?
prev=now;
return;
}
if (now<prev){//value looped?
prev=now;
return;
}
elapsed=now-prev;//elapsed time since prev
if (elapsed==ms){
prev=prev+ms;
return;
}
if (elapsed<ms){
int64 wait;//cannot be static
wait=ms-elapsed;
if (!wait) wait=1;
if (wait>=10){
Sleep(9);
evnt(0);//check for new events
}else{
Sleep(wait);
}
//recalculate time
goto recalculate;
}
//too long since last call, adjust prev to current time
//minor overshoot up to 32ms is recovered, otherwise time is re-seeded
if (elapsed<=(ms+32.0)) prev=prev+ms; else prev=now;
}
Looking it over, I can't see anything which would fail to compile and work properly on Windows Server 2016.
If you're proficient in c, you can c that the routine basically does as I mentioned above: automatically calculates the delay necessary to obtain a maximum fps equal to your _LIMIT. If your program runs too slow to go over your set limit, it basically does nothing to pause operation (that's our call to Sleep, if it's needed at the end of the routine).
I'm not sure why a _LIMIT 5 might be getting ignored, without seeing the code itself. Could it be that your program is using multiple _LIMIT statements in it, and tossing off those internal static variables? (Such as a _LIMIT in the main loop, and then one in an input loop to check keypresses elsewhere?)
If you can share the problem code, that'd help a lot with trying to debug the issue.
