quote:
You shouldn''t have 1 VB per triangle strip / fan. You should have 1 VB for all objects of the same FVF and type (static / dynamic). Calling SetStreamSource() and setting all the render states for each draw call is very expensive. You''ll really notice it when you start drawing 10+ objects.

This is a bit off topic of the original thread. As for the FPS I went with the QPC, it''s nice becuase the frequecy is in seconds so it works out really nicely.

But this post caught me eye... So say your drawing a sky and terrain etc... As long as the vertex type is the same I should stick to one buffer? And the only time I would change it is if the vertex types chage? I''m just trying to understand the rule of thumb here. Also then with that in mind... Should I attempt to render Meshes the same way to keep my frame rates up other than useing the D3DXMesh helper class? I am going to be using skined meshes, so any feed back on this would be great. Or should I just start a new thread?

Hi! this is my first post here, i''ve been on a project for 3 weeks now and i happened to had that same problem... fps wouldn''t go above 85 fps....

so let''s retake the thread ontopic again
the problem isn''t the calculation itself, i use timeGetTime()for mine, and works fine if you''re not looking for precision

now, you should know that the FPS calculation is limited to screen refresh rate (in Hz) yes, try changing the refresh rate of your monitor and give it a run, you''ll see what i mean.

if you want to get the correct fps count, the parameter "PresentationInterval" of your PresentParameters structure must be set to D3DPRESENT_INTERVAL_IMMEDIATE

hope it helps

One more quick note on timeGetTime(), particularly to those that mention unpredicatable delays.

I consistently get 1 ms precision with it, verified by QPC. To quote a short article on this that I wrote some time ago: "Windows 95 and 98 (and possibly Me) actually default to 1ms precision for timeGetTime without the extra calls. NT/2000/XP have the lower default precision."

The extra calls in question are timeBeginPeriod and timeEndPeriod, which set the precision of timeGetTime within a thread.

If despite this you actually NEED QPC (or just WANT to use it), then more power to you. But don''t say timeGetTime is unreliable, as it is quite solid, and generally more than precise enough with these calls.