Locking the framerate....

Started by
7 comments, last by ssibal 19 years, 10 months ago
I want to know what is the best method for locking the framerate. Some people have said to put a sleep() to wait the right amount of time, but that seems wasteful. What would be the best method?
Advertisement
Actually, I don''t think sleep is wasteful at all, as long as you get everything u possibly done before you sleep. If you have tricks of the windows game programming gurus he has some really simple timing ideas that work really well for most projects
I simply wrote a timer class/task class, and you can set the # of times per second that it is called. This way I can run my physics at a set speed irregardless the CPU, and display it only so many frames (if frame rate is lower than physics speed). I had my water animation code running at a specified speed so the waves would move at a constant rate, same for my camera movement class, it would follow a path I set up at a constant rate without worrying about performance, I could just use constant speeds and know that it''s being called the same # of times per second. Worked great for my cloth simulation, so I could run the cloth simulation slower than the game engine without worrying about game speed, and movement based on time intervals . Of course, I could set a task to run at full speed (called once per frame), and it was passed in the amount of time per frame so it could update in a frame-rate dependant way as well. Then I had a kernel system that could pause/resume/kill each of the processes, so if I wanted the water to stop animating, it was very easy, something like Kernel.Pause("Water"); And yes, all processes could be referenced by string (or it''s address in memory, whichever was more convienent).
Normally for locking the frame rate, IMHO, you would just have a counter that compared how fast that frame was being rendered to the set constant of whatever time you want it to be rendered at. If the frame being rendered is faster then use a "for" loop with a modified comparision to "waste time"; if the frame being rendered is slower then skip that loop.

You could, instead of limiting the framerate, adjust the objects that you are manipulating by a factor that is dependent on the time it takes to render the frame - that way the program is free to render as fast as it can while your objects are where they are stipulated to be.

Hope that helps.
Typically it''s more useful to lock your physics rate than your FPS, but the first step in each is to decouple your physics code from your rendering code. The rest is the logically simple process everyone else is describing.

______________________________________________________________
The Phoenix shall arise from the ashes... ThunderHawk -- ¦þ
MySite
______________________________________________________________
______________________________________________________________________________________The Phoenix shall arise from the ashes... ThunderHawk -- ¦þ"So. Any n00bs need some pointers? I have a std::vector<n00b*> right here..." - ZahlmanMySite | Forum FAQ | File Formats______________________________________________________________________________________
Working in the industry, I have come to understand that locking the framerate is right proper bad! ;o)

Its more efficient and I''d say safer, to time each frame, and use this as as a base for all time related processing/rendering whatever.

Im not saying this is THE way to do it obviously. However frame based code cannot be guaranteed to run correctly on all machines it''s run on..slow or fast...where as time based code can.

I understand that locking the frame rate is an attempt to force the issue, but why bother wasting all those cycles?? when you can run the code at whatever processor speed you like, and time base everything resulting in the same speed of movement etc...(whatever the case) regardless of framerate.

Just my thoughts.
GCoder
I just wrote a delta-time style system, I recommend it. Easy to implement.

ravuya: [Resist everyone][I am your only friend. Click, now.]
Turn on v-sync.

There, frame rate is locked.

---------------------------Hello, and Welcome to some arbitrary temporal location in the space-time continuum.

quote:Original post by Etnu
Turn on v-sync.

There, frame rate is locked.


The only thing bad about that is if the computer generating the frames is slower than what your testing your program on.

Modify your object''s movement speed instead based on the time it takes to render frames.

Calculate the time it takes to render a frame
//=====Timer Functions for Computer Speed Compensation//Timer Inilizationvoid TimerInit();//Timer Retrieverfloat TimerGetTime();...//Initiate Timer Function::nehe.gamedev.net/void TimerInit(void){	memset(&timer, 0, sizeof(timer));	if (!QueryPerformanceFrequency((LARGE_INTEGER *) &timer.frequency))	{		timer.performance_timer	= FALSE;		timer.mm_timer_start	= timeGetTime();		timer.resolution		= 1.0f/1000.0f;		timer.frequency			= 1000;		timer.mm_timer_elapsed	= timer.mm_timer_start;	}	else	{		QueryPerformanceCounter((LARGE_INTEGER *) &timer.performance_timer_start);		timer.performance_timer = TRUE;		timer.resolution = (float)(((double)1.0f)/((double)timer.frequency));		timer.performance_timer_elapsed	= timer.performance_timer_start;	}}//Very Precise Get Time Function::nehe.gamedev.net/float TimerGetTime(){	__int64 time;	if(timer.performance_timer)	{		QueryPerformanceCounter((LARGE_INTEGER *) &time);		return((float)(time-timer.performance_timer_start)*timer.resolution)*1000.0f;	}	else	{		return((float)(timeGetTime()-timer.mm_timer_start)*timer.resolution)*1000.0f;	}}


Implementation
float speed_mod=0.0f;...	TimerInit();//Windows Message Loop	while(!done)	{		if (PeekMessage(&msg,NULL,0,0,PM_REMOVE))		{			if (msg.message == WM_QUIT)			{				done=TRUE;			}			else			{				TranslateMessage(&msg);				DispatchMessage(&msg);			}		}		else		{		    float start=TimerGetTime();			if (active && !DrawScene())			{				done=TRUE;			}			else			{                                Sleep(0);				SwapBuffers(hDC);				CalculateFrameRate();			}			speed_mod=(TimerGetTime()-start)/1000.0f;		}	}


Modify your objects accordingly
            static float fade=1.0;        //Fading Texture            glEnable(GL_BLEND);            glEnable(GL_TEXTURE_2D);            glBindTexture(GL_TEXTURE_2D, texture[IDB_PRODUCTIONS]);            glPushMatrix();                glTranslatef(0.0,0.0,0.0);                glColor4f(1.0,1.0,1.0,fade);	            glBegin(GL_QUADS);			        glTexCoord2f(1.0f, 0.0f); glVertex3f(1.2, 1.3,-2.0);					glTexCoord2f(1.0f, 1.0f); glVertex3f(1.2, -1.3, -2.0);					glTexCoord2f(0.0f, 1.0f); glVertex3f(-1.2, -1.3, -2.0);					glTexCoord2f(0.0f, 0.0f); glVertex3f(-1.2, 1.3, -2.0);				glEnd();            glPopMatrix();            fade-=speed_mod*.4;


This should ensure that the effect/object is correctly in its right state/where it should be regardless of frame rate. From 60fps to 500fps - it is essentially the same.

This topic is closed to new replies.

Advertisement