Sign in to follow this  
yahastu

DirectX FPS

Recommended Posts

yahastu    154
I measured that I am getting 50-55 FPS in my game. I am measuring the FPS by looking over the last 200 frames, computing it using clock() and time(), both give the same answer. I thought this was a bit low because I'm not doing too much...rendering some text, a few thousand points, mesh, fog, thats basically it. Well, I did some profiling...and it turns out that I get the exact same FPS when I remove EVERYTHING from my render loop leaving just: dxDevice->Clear(0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, D3DCOLOR_XRGB(154,168,214), 1.0f, 0); dxDevice->BeginScene(); //nothing dxDevice->EndScene(); dxDevice->Present(NULL, NULL, NULL, NULL); Literally, theres nothing else in the timing loop. Yes, I am running in Release mode, and every single speed optimization that Visual studio can do is turned on. If I comment out dxDevice->Present, then it jumps up to like 600 FPS, and then if I turn off the others it goes up to practically infinity (as expected). What I dont understand is...why is this the bottleneck? And rendering a large mesh with 1024 tex + text overlays + dynamic generation of point sprites...none of these things even make a noticeable increase in the FPS. So it seems that 50 is the BEST possible fps I can achieve under any circumstances then....yet I have seen higher FPS reported to me in games and demos that other people have compiled! Im using: Geforce 6600GT 128MB 3 GB ram Athlon 3800+ 2.01 GHz dual core proc

Share this post


Link to post
Share on other sites
boersch    122
You probably have v-sync enabled (meaning that your frame rate is limited to your monitor's refresh rate) - you'll want to check what your presentation interval is set at under your D3D device settings. To force v-sync off you'll want to set the presentation interval to 'immediate' - search your DX SDK docs for presentation interval and everything should be there :)

Share this post


Link to post
Share on other sites
supamike    319
Hey, have you got your presentation parameters set to vsync by any chance?

i.e. (in MDX for example)

D3DPresentParameters.PresentationInterval = PresentInterval.Default; //this will vsync it to your monitor refresh rate (around 60Hz).

D3DPresentParameters.PresentationInterval = PresentInterval.Immediate; //this will throw frames out as fast as it can (eg much > 60Hz).

[edit]: snap boersch :) i was way to slow on that one

Share this post


Link to post
Share on other sites
jollyjeffers    1570
Just to add to this - the presentation interval parameters tend to be more of a hint than a requirement. Look in your hardware's control panel applet and you'll probably find a "always off"/"application preference"/"always on" switch.

The point being that it's best not to rely on V-SYNC being enabled or disabled.

hth
Jack

Share this post


Link to post
Share on other sites
Naku    151
Not alot of point in turning it off really though. Sure it helps to give a rough indication of the preformance without any real profiling but apart from that what does it matter if you're window refreshes 50 times a second or 200 if you're monitor is onlt refreshing at 50 anyway? Hopefully you're not relying on any peticular frame rate for timing otherwise its not going to run the same on your system as on another one.

Share this post


Link to post
Share on other sites
yahastu    154
Naku,

When I set PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE; as suggested, my framerate jumps up to around 215. I suppose there is no way to know for sure if the screen is really refreshing that fast...but there is a very noticeable improvement. My monitor refreshes at 75 Hz anyway, not 50 Hz!

JollyJeffers,

Interesting...I have the nVIDIA display desktop manager thing in my system tray, but I was unable to find the setting you are talking about.

Share this post


Link to post
Share on other sites
yahastu    154
Naku,

When I set PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE; as suggested, my framerate jumps up to around 215. I suppose there is no way to know for sure if the screen is really refreshing that fast...but there is a very noticeable improvement. My monitor refreshes at 75 Hz anyway, not 50 Hz!

JollyJeffers,

Interesting...I have the nVIDIA display desktop manager thing in my system tray, but I was unable to find the setting you are talking about.

Share this post


Link to post
Share on other sites
yahastu    154
Naku,

When I set PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE; as suggested, my framerate jumps up to around 215. I suppose there is no way to know for sure if the screen is really refreshing that fast...but there is a very noticeable improvement. My monitor refreshes at 75 Hz anyway, not 50 Hz!

JollyJeffers,

Interesting...I have the nVIDIA display desktop manager thing in my system tray, but I was unable to find the setting you are talking about.

Share this post


Link to post
Share on other sites
orphankill    122
I was calculating my fps similar to that until I thought of a much better way:

(not exact code off the top of my head)
static int fps = 0;
SetTimer(0, 1000);

gameloop()
{
fps++;
if (WM_TIMER == msg.message)
{
DisplayFPS();
fps = 0;
}

}

Share this post


Link to post
Share on other sites
yahastu    154
There is no difference mathematically between waiting 200 frames and then dividing by the elapsed time and waiting 1 second and counting the number of frames.

The only difference is that your method will give you a less accurate measure of the FPS as your FPS approaches 0, whereas my method will increase in accuracy.

Share this post


Link to post
Share on other sites
boersch    122
Time elapsed per frame is a better measure of your performance - it scales linearly. If you have a framerate independant simulation, you're probably calculating it anyway. And if you really need to know your fps, just calculate 1/elapsedTime...

Share this post


Link to post
Share on other sites
Zipster    2359
I'm with the Coalition Against Spastic Framerate Counters (CASFC). If you do calculate the FPS per-frame, it would be nice if you didn't display it at the same framerate, making it look like a spastic, jumbled mess of numbers where no one can make out the least-significant digits. Keep a running average over every 0.25 or 0.125 second interval, and display it at that rate (4 or 8 times a second).

Share this post


Link to post
Share on other sites
yahastu    154
Clock ticks have a finer granularity than frames, so your FPS will be more accurate if you measure FPS by a constant number of frames divided by the time elapsed.

If your true FPS is 50.2 the best you can measure by counting the number of frames over 1 second is 50. Of course you could wait 10 seconds and that would allow you 1 decimal point of accuracy, but thats still not much. Also when you check for 1 second being elapsed it is likely more like 1.1 or 1.2 seconds or something so unless you divide by true time elapsed, it will not be accurate. Furthermore as your framerate goes down the division is based on less numbers and therefore is less accurate, as we know the sample mean converges to the true mean as the number of samples goes to infinity from statistics.

The better way to calculate framerate is to wait for a fixed number of frames and then divide by the time elapsed. At any point in time you can get the number of clock ticks and since clock ticks have a finer granularity, your number will be off by a fraction of a clock tick rather than a fraction of a frame-rate, so you wont have the problem with calculating 50.2 FPS. In fact you can have many digits of precision this way using a shorter window of time. Furthermore as framerate degrades you still have the same number of frames to deal with, so your number stays accurate...actually gets slightly more accurate because it starts to eliminate the fractional error of a clock tick.

As Zipster points out this should be computed as a running average so that you can display an updated estimate on every frame. However, he is wrong to say that you should calculate your running average over a fixed window of time. For the reasons I have explaiend above, it is better to calculate it over a fixed window of frames.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this