Skip to main content
gamedev.net
🔒 Locked

Frame Rate Synching Problem

Started by joutlaw Jan 27, 2003 at 2:59 PM 12 replies 1.4k views
Original Post
joutlaw
joutlaw
I need help. Please look at the following code snippet: 

DWORD dwStart = ::GetTickCount();
DWORD dwFinish = ::GetTickCount();

// Game Loop code here, updates, collisions, frame rendering

while ((dwFinish - dwStart) < 33)
    dwFinish = ::GetTickCount();
On a hardware challenged machine ( AMD K6 2 366, 2MB Vid Card ) this makes my game run at almost precisely 30 FPS. However on a FAST machine ( P4 2.4 GHz, 64 MB GForce ) this makes my game run at around 23 FPS. If I change the 33 in the while loop to 20, it get back around my 30 FPS number consistently. FYI, I DO NOT have machines reversed the slower one runs at around 30 FPS and the faster run runs around 23 FPS. Any thoughts? Thanks Jeff
Jeff OutlawPresidentDigitalOutlawhttp://www.digitaloutlaw.com
nail85
nail85
Emmm... Heh.
What do you need? I think you organized your program main loop this way. But this method is strongly uncorrect. You should use main loops like loop in NeHe''s Lesson #1 .

Maybe i didn''t understand something in your question and you asked not about main loop, if so: the reason is that GetTickCount() is not high performance timer, it ticks every 55 (not 33), but this number may vary from system to system. Use the QueryPerformanceTimer instead
Punx409
Punx409
You have to limit the framerate to something or else it''ll run too fast to be playable. Some older games that didn''t limit framerate have this problem.
Roof Top Pew Wee
Roof Top Pew Wee
Be more specific on "run to fast to be playable"

I mean, if you handle all of your movement by modifying it to the frame time, a faster game means you''ll just get more frames and in the end just have objects move less each frame, if you do it all by accurate timing.

How could a game run " too fast"?

--Vic--
deal
deal
quote:
Original post by Punx409
You have to limit the framerate to something or else it''ll run too fast to be playable. Some older games that didn''t limit framerate have this problem.


thats where frame rate independent movement comes into play....
jermz
jermz
quote:
Original post by Roof Top Pew Wee
AHHHHHHH!!!!!

This is one question that I have asked myself OVER AND OVER AGAIN. Why would anyone want to limit the game's framerate!?!?!?!?!?!?!!

--Vic--



Because it's not 3D.
Because there's no sense in rendering the exact same scene multiple times.
Because the game does not need a rendering engine separate from its logic engine.
Because it's easier.


Joutlaw, I think you inverted the order of your game loop code and the dwFinish assignment. But regardless, GetTickCount() is too imprecise to use for timing in games. Use QueryPerformanceCounter() as nail85 said. And avoid the busy wait at the end of your loop. Instead of the while loop, use Sleep() to nicely wait until its time to process the next frame.

[edited by - jermz on January 27, 2003 5:30:54 PM]
Palidine
Palidine
yeah, you definitely do not have to limit framerate in order to have a game playable on all speeds of CPUs.

framerate independant movement means simply using basic physics to move your items.

S(t) = 1/2 * a * t^2 + v * t + s

S(t) = your position now

a = acceleration of object
v = velocity of object as calculated last frame
s = position of object as calculated last frame
t = time since last frame (getTickCount() - lastFrameTickCount)

if an object is accelerating you''ll also want to subsequently run:

V(t) = v * t + s
v = velocity of object as calculated last frame
s = position of object as calculated last frame (NOT THE NEW POSITION)

make life easy on yourself and extend the * operator for your vector class so you don''t have to write out that equation 3 times.

-me
Roof Top Pew Wee
Roof Top Pew Wee

Not trying to start a flame war here, but just wondering:

Because it''s not 3D.

I don''t see why this would matter. In fact, all of my games are 2D, and I don''t limit my framerate. I mean, Mario could still be played at 20 frames or 100. Just make him move a little less depending on the frame. It''s all just moving a rectangle around, so I don''t see why it matters if it''s 2D or 3D.

Because there''s no sense in rendering the exact same scene multiple times.

Well, there is a small difference in games that run 30 frames and some that run 60 frames a second. So why limit it to 30. There is a *little* sense in rendering stuff over and over, and it''s not the same scene. It''d be with small changes. Also, what does it hurt if you do render the same scene over and over. I don''t think the computer will wear out.

Because the game does not need a rendering engine separate from its logic engine.

This is not difficult to do. Just move the functions around. Besides, you wouldn''t have to split them. Anything that is frame dependant is usually movement and delays. So instead of having all of your logic dependant on frames, why not time? It''s 2 lines of code to time things. Something you have to do anyway when you want to delay framerate.

Because it''s easier.
Even this is debatable, but I guess that''s because I already have my framework set up for dynamic framerates.

--Vic--
Roof Top Pew Wee
Roof Top Pew Wee
Actually, Palidine, there are easier ways to do what you are saying:

Just do this:

ObjectXVelocity += ObjectXAcceleration * difference;
ObjectX += ObjectXVelocity * difference;

No need to get into quadradics for it

Hehe, i think I just made up a proverb:

"Why square and multiply when you can just add?"

Maybe not

--Vic--

joutlaw
joutlaw
Not to sound unappreciative but:

The objects in my game are NOT dependent on the frame rate. They move and update themselves independent of the actual or desired frame rate.

I was interested in limiting the frame rate to help aid in debugging.

From the replies I have seen I cannot depend on the number of times per second that GetTickCount updates its "ticks". Indeed the behavior I have seen as well points to this fact. The AMD K6 machine I mentioned above is running Windows ME. This again, is the machine that is giving me approximately 30 FPS. The P4 machine is running Windows 2000.

So it would seem that on Windows ME a delay of 33 ms roughly gives you 30 FPS ( actually 990 but close enough for this discussion ) and on Windows 2000 the same 33 ms delay yields 23 FPS. I conclude that on Windows 2000 GetTickCount is only updated every 50 or so ms.

At any rate I am going to change my timing routine to high performance counters.

Jeff
Jeff OutlawPresidentDigitalOutlawhttp://www.digitaloutlaw.com
Thunder_Hawk
Thunder_Hawk
quote:
Original post by Roof Top Pew Wee
I have found that timeGetTime is much more accurate than GetTickCount();

--Vic--


Actually, I think that is machine dependant. I use both frame limiting and time-based movement. Frame limiting is useful to prevent nasty slowdowns on machines that might be able to notice. Here''s my limiting function which I call once every frame:


  
void LimitFPS (DWORD fps)
{
	static DWORD dwFpsTimerCount = 0;
	DWORD evener = (1000%fps && !(rand()%int(float(1000)/(float(1000%fps)/float(fps)))/1000))? 1 : 0;
	/* Use lazy evaluater to protect against division by zero.  Expression uses rand to
	ensure the fps is accurate...fixes the accuracy problem introduced by the integer while
	loop below. */
	DWORD count = 1000/fps + evener;
	if( dwFpsTimerCount != 0 )
		while(timeGetTime() < (dwFpsTimerCount + count) );
	dwFpsTimerCount = timeGetTime();
}




_____________________________

And the Phoenix shall rise from the ashes...

--Thunder_Hawk -- ¦þ
______________________________
______________________________________________________________________________________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 Forma

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.