What do you think?

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.

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.

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!

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

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

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

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

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 ~

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.

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^_^)

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

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