Frame Rates, etc.

Started by
4 comments, last by hollowMedia 22 years, 5 months ago
I am pretty sure than I read a while ago that a target frame rate is around 30 fps, because that is the minimum the human eye can see streamlined. I wrote a very very very simple DirectX app that just blits (a color fill) and flips 4 times per render, and upon testing my fps it looked like it was averaging 18. Is this terrible? I am running a Celeron at 525 with 256MB of RAM. I just don''t know what to expect. Again, there is nothing external going on to my knowledge, I only [Blt, Flip] 4x. I know flipping is supposed to be expensive, but my frame rate drops insanely. I have ran it at both 800x600 and 640x480 and there is no difference. Thanks in advance.
[xian]
Advertisement
How many frames per second the eye can distinguish is a matter of some debate, that relies on a variet of things. For instance, movies are 24 fps, and look smooth, but they have motion blur and high contrast (because you watch in the dark) and the camera does not swing around quickly or at wild angles. Some computer game players will tell you they can see differences in shooter games up to 100 fps, but games (until recently) often have no anti aliasing or motion blur, and the movements and rotation of the camera can be very fast.

So what is an acceptable frame rate of your game on a computer is really a matter of what you are programming. If you are making a fast moving first person shooter, it may well look very jerky at 18fps. If you are making an isometric strategy game, with comparatively slow animation, then 18fps might be perfectly fine. You just have to play it and see if it feels smooth ot not.
Actually, televisions use a 48Hz interlaced structure, so that only half the picture is updated at a time, on every other scanline. This means that you seem to get a smooth picture, even though it is only 24fps.
If at first you don't succeed, redefine success.
4 * 18 == your refresh rate?

Just a thought
Anyway to answer your question, it waits till the end of the frame update to do a swap, so you dont have to flip after dawing every object, or it is going to run REAL slow, just draw all your stuff then flip. So in reality you are proably able to get 72ish fps, but as AP mentioned 72/4=18.

That makes sense, but my refresh is at 60 right now [and I have no idea why I set it there ]. My main issue came from as soon as I stuck some logic in the loop to try to lock in on a frame rate (like 30), even with one flip, it wasn''t very accruate. I thought there may be something I was overlooking since when I stuck some game logic in the loop, the best I could get was a LOT less than a friend of mine who wrote something similar and got around 480 fps with a flip. It could be that his processors are much better.

If I try to lock at around 30 fps like this

while( ( GetTickCount() - dwTime ) < 33 );
// Where dwTime is the tick count at the start of the loop.

It locks to around 24-25, without any game logic, just a straight loop. 1000/33 = 30 last I checked, and in all texts that I have seen so far on locking frame rate, it says that this is a valid method. I know that there should be some descrepencies due to the outside logic and moving back into the loop, but at a cost of 6 fps, it seems a bit stiff. Can I be certain that it will lock the same on other machines?

Thanks!
[xian]

This topic is closed to new replies.

Advertisement