I have 2 different solutions/projects. 1 has just the necessary code required to print the fps onscreen. The other has alot of other stuff like model loaders,displayers,textureloaing code, etc... Now when i display the fps from the first project, i get about 800-900 fps. When i do the same for my 2nd project,i get half the fps. Note that in the 2nd project, i do not display anything onscreen,neither do i even call any of the additional features in the display callback function. I only call the same FPS display code as in my first project. So can the mere presence of the additional .cpp files and header files cause such a drastic drop? Most of the .cpp files describe objects which i dont even instantiate for the test.

quote:

---

Original post by GamerSg
So can the mere presence of the additional .cpp files and header files cause such a drastic drop? Most of the .cpp files describe objects which i dont even instantiate for the test.

---

Not likely. You probably have your main loop set up differently, and/or are still doing extra processing in the second. Without looking at code, it''s hard to say.

THANK GOD I FOUND IT!

I would never have been able to sleep peacefully knowing that something in my engine was causing me a 400fps DROP!

The culprit it appears to be is the Depth Buffering.
I was not able to detect this earlier because i was not clearing the depth buffer in my first project.

So now my qsn changes, is there a better alternative to using OpenGL''s depth buffer? I have read somewhere that OpenGL is very slow in it''s depth buffering, but i never imagined it would be this slow.I have heard that Octrees can do the job.
But can octrees produce as accurate results as OpenGL''s depth buffering?

I may be wrong, but I think OpenGL''s depth buffering is fast. It would be simple enough to put a timer on it and see, comparing it to other things.

Don''t assume that dropping 400 fps by adding depth buffering to an empty loop means that depth buffering is slow. Read this article.

You said you went from 800 to 400 in fps.

Now... 800 fps is extreamly fast, so is 400.

Your eyes can only see things in about 30 fps, so there is not really any point in running it above 60 fps. it won''t make it run any smoother.

I still don''t see how people say your eye can''t see anything more than 30 fps, cause I sure can tell. I do agree with you about not being able to see anything more than 60 - 85 though.

FPS drop like that from a huge number to a huge number aren''t so bad.

For example, say it takes 1 ms to draw your scene. You have 1000 fps!

Now say that you add a little bit and now it takes 2 ms to draw the screen. 500 fps.

Add a little bit more and now it takes 3 ms to draw the screen. 333.33 fps.

Add a little bit more so that it takes 4 ms to draw the screen. Now you are down to 250 fps.

If it takes 5 ms now, you are down to 200 fps. See how the drop in fps decreases each time although each step we are adding the same amount of time to render?

So, you see, when you have a huge amount of FPS, a small slowdown in your program will deduct a large amount of FPS...

Tim

well, about the frame rate , think about the TV wich shows 24 frames/second

- But then again, most movies don''t do any quick camera rotation either. The only time you REALLY need that many fps is in a first person shooter (need fps for a FPS, bahaha). The reason is that the camera rotates much faster and the framerate is much more noticable.