Archived

This topic is now archived and is closed to further replies.

What do you think?

This topic is 5873 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, Do you think that locking the fps or updating all your physics, positions, etc. with a delta time variable is better/more appropriate. Any suggestions would be appreciated.

Share this post


Link to post
Share on other sites
Please repeat after me: "Locking physics and movement to the frame rate is evil. I will never ever rely on the frame rate as a timing mechanism in my game."

Its very easy to make your own timer with QueryPerformanceCounter and QuerPerformanceFrequency. You may be able to limit the upper framerate of your game but you will almost never be able to guarantee a minimum frame rate.

Share this post


Link to post
Share on other sites
Yes, locking the framerate is evil. You should let your program run at its full potential. To find the delta variable I like to use timeGetTime() (You must include winmm.lib, I think). It works on all machines and its efficient enough that you don''t need to mess around with QueryPerformanceCounter. Mind you, it doesn''t matter which function you use, as long as you DON''T lock the frame rate.

If you get really stuck for code I would be happy to give you some that I use.

Share this post


Link to post
Share on other sites
Ok, thanks, I was just wondering since I saw this other person''s code and they locked the FPS; just wanted to know the more efficient way to get your graphics to run at about the same speed on most machines.

Thanks for telling me that you would give me some code Moe, but I already have my own functions that are encapsulated in a GLTimer class.

Thanks you two!

Share this post


Link to post
Share on other sites
Can you also do this with ticks...I mean if you know there are X ticks per second(getTicks()), you allocate X/framerate_desired ticks per frame and thereby allow it to generate the same amount of frames per second on any machine......hmmmm it sounds different saying it out loud...anyways

Share this post


Link to post
Share on other sites
QueryPerformanceFrequecy/QueryPerformance has much higher resolution. On my 1.4gHz athlon, performance frequency is 3579545, one one tick about every 300 nanoseconds. timeGetTime is measured in milliseconds. There are several orders of magnitude in difference between the two. Although I suppose if you don't have stringent timing requirements, timeGetTime is ok, and easier to use.

Edited by - invective on November 14, 2001 3:18:37 AM

Share this post


Link to post
Share on other sites
quote:
Original post by Floppy
Hi,

Do you think that locking the fps or updating all your physics, positions, etc. with a delta time variable is better/more appropriate.

Any suggestions would be appreciated.
I prefer to do neither. I let the framerate be as high as it can be on the machine the program is running at. Then I choose a minimum framerate, say 30 or 35, that I deem an appropriate compromise between responsiveness and "lowest-common-denominator-cpu/graphics-speed" and lock the phyics to that framerate. I interpolate to accomodate higher _graphical_ framerates, but don't update forces or anything at a higher resolution than the minimum framerate I chose.

This way, you avoid having to use a variable time difference in your calculations, which can make things like reactions to collisions and retracing routes especially tricky. The exception, of course, is if you're running on a slower computer that simply cannot maintain your minimum fps.. you can either dynamically set the constant time interval at the beginning of the program, or just start using changing time intervals and hope for the best.

- riley


Edited by - rileyriley on November 14, 2001 7:06:25 AM

Share this post


Link to post
Share on other sites
I use a method inspired by WizHarDx in one of my previous posts...

Assign objects a velocity in pix/sec - rather than controlling things frame by frame, control them second by second. As each frame is drawn I make a note of how long it took, then in the processing for the next frame I adjust the positions thus:

double dFractionOfASecond = dwLastFrameRate / 1000.0;
x += (cos(dTrajectory) * m_dVelocity * dFractionOfASecond);
y += (sin(dTrajectory) * m_dVelocity * dFractionOfASecond);

I store the coordinates as double to ensure the accuracy, then just plot them as integer values in x,y coordinates on the screen.

With this, all objects travel at the same velocity although just jerkier on slower machines.

I also apply the same principle to acceleration, increasing the velocity as a function of time rather than framerate with acceleration being measure in pix/sec/sec rather than pix/frame/frame.

It works for me anyway

Share this post


Link to post
Share on other sites
I just lock the framerate as I find it easier to do. Just set the frame rate high enough to make it run smoothly, and you''re done. Plus, if you have lots of time left at the end of a loop, you might want to use that extra time to do other things, such as (yawn) error-checking.

~ There''s no substitute for failure ~

Share this post


Link to post
Share on other sites
Thats probably not a very good idea. You really should look into making a delta type variable. It doesn''t take long to do and it is really easy to do.

Share this post


Link to post
Share on other sites
I like to use a delta with a limit. For example:
frameTime = thisTick - lastTick;
delta = (frameTime > 50 ? 50 : frameTime) / 1000.0f; //minimum 20 fps
That way, there''s no frame rate limit, but it will slow down rather than move large amounts every frame when the frame rate gets low.



-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

Share this post


Link to post
Share on other sites
Here''s a link discussing this topic. It was a "tip of the day" a while back on FlipCode. It''s pretty long, with lots of code, and the people talk about lots of different aspects:

Main Loop with Fixed Time Steps.

Alistair Keys

"There are two kinds of people, those who finish what they start and so on."
-- Robert Byrne

Share this post


Link to post
Share on other sites
I was developing a game on a Pentium 90. I locked everything - physics, game loop - to the framerate.

I then gave a copy to a friend who had a P3 800. He played it, and hit me.

Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net

Share this post


Link to post
Share on other sites