Frame limit.

Question: WHY limit the framerate?

so shit doesn''t play too fast

-eldee
;another space monkey;

Game speed should be independent of framerate.

eldee, ever played quake 1, 2, or 3? Ever played Unreal or UT? Ever played any game using a half decent engine, or made by half decent coders? The games run at the same speed no matter what the framerate is. It isnt hard to do at all, infact is it INCREDIBLY simple.

then maybe you can help me?

I wrote a tutorial and submitted it to gamedev.net on making movement independent of frame rate but i guess they lost it. The basic idea is to find out how much time has elapsed between your last frame and your current frame. If it is .0125 seconds, then your demo is running 80 frames a second since 80 frames times .0125 seconds is 1 second. If you know how much time has elapsed between frames, the next thing you need to know is how far to move each second. If you want to move 2 units a second, multiply 2 by the time between frames to get how much to add to your position. If your at 0,0,0 and want to move 2 units in the x direction every second, then multiply 2 by the time between frames for every frame you render and then move the position by this amount. So at 80 frames a second, the distance to move is the .0125 seconds between each frame multiplied by 2 which is .025. Thus you are adding .025 units to the position every frame. After 1 second, all the movements will add up to 2 units so you are looping 80 times a second.

Maybe you have some code that i can look at?
thanks for oyur help

For the tutorial i modified nehe''s lesson 23. I could send you that if you like.

Sorry for the multiple posts. I''ve been having a lot of difficulty posting on this board and it seems to do that sometimes.

yes yes please

add me on ICQ
36189448

or send it to my mail
moname@tjock.com

thank you!

Edited by - ShiningKnight on December 1, 2001 10:38:32 PM

Check out this thread for a quick rundown of what to do (includes code) that I posted for someone else.

Maximus, in your approach you''re drawing frames as much as the CPU can handle. That can lead to very high frame rates, even higher than the monitor''s display rate. What''s the use? Wouldn''t that be better to limit the max frame rate to the monitor''s current vsync? This way you''re performing less calculation and avoid to slow down to much other running applications (saying you''re not in the context of a game, where you don''t need other applications to run a the same time).

In a single buffered app, not sure off the top of my head how you would query directly.

In a double buffered app (which should really be just about every app), when you do a swap or a flip, the video driver doesnt return until the swap or flip is complete. While its waiting, its usually polite enough to not hog all cpu time in a busy wait loop.

In a tripple buffered app when you do a flip/swap, if there isnt already a frame buffered and waiting to be shown the call will queue the frame up to be displayed and return immediately. This happens when your frame rate is below refresh rate. If there is a frame buffered already, the call behaves as it does in a double buffered app (not returning until complete). This happens when your frame rate is above (not counting the time you wait for vsynch) refresh rate.

to the two AP above:
openGL is not only used in games where we don''t care about the other apps. I think the smartest wait loop is the one that displays at maximum a frame per vsync and no more. To do that, I guess the way to go is:
- query the system for the vertical refresh rate at the begining of the app (ex: 80Hz)
- compute the time elapsed between now and the last displayed frame
_ if < 80hz, do nothing
_ if >= 80hz, compute the frame and display it right in sync with the vertical refresh rate (apparently this is done automatically as you''re saying).

This might not be sufficiant to have an optimal frame rate -> in the case the elapsed time is < 80hz, we give control to the message loop that may give us control back long after another vsync, so we would not be optimal.

what do you think?

To LordKronos:

quote:

---

In a double buffered app (which should really be just about every app), when you do a swap or a flip, the video driver doesnt return until the swap or flip is complete. While its waiting, its usually polite enough to not hog all cpu time in a busy wait loop.
[\quote]

I''m not sure how the stuff is working internally, what I''ve noticed with Nehe examples is that they take 100% of the CPU all the time even though he''s using a swap buffer. Do you know why?

---

Okay, I get the stuff about multiplying the speed per second times elapsed time, but how can you get the time in milliseconds? i am quite a newbie programmer and the stupid MSDN documentation is a bunch of NO HELP!

Either use timeGetTime, or QueryPerformanceCounter/QueryPerformanceFrequency.

Both of them has pros and cons. If I remember correctly, timeGetTime has less resolution, but better response time.

Using VS, You can simply call GetTickCount(), look it up on MSDN

timeGetTime as far as I remember uses slightly more resources. The fastes way to my knowledge is getTickCount (You will get into trouble, if you don't watch out, since it resets after 40 days or something like that)

-- Sturm


---------------------------------------------------
Life after death? No thanks, I want to live NOW
--- Sturm 2001

Edited by - Sturm on December 6, 2001 12:38:56 PM

I doubt any gaming Windows system will have an uptime of 40 days, and anybody who''s risking playing games on a server doesn''t deserve better than a system halt.