DirectX app topping out at 60fps

Started by
5 comments, last by Bacterius 11 years, 8 months ago
I have created a simple racing game in DX. When I run on a variety of sytems (with varying hardware configs) the frame rate tops at 60 fps on all systems. This is not a problem as its simplified the timing of some elements within the game for me. I am just curious why this actually happends as some of my test systems should be able to produce much higher framerates for such a simple game. Is there some setting within DX that aims for 60fps? or is something else happening within my app that I am unaware of? Thanks in advance Uni
Advertisement
Your game is most likely locked to the refresh rate. When you set up your PRESENT_PARAMETERS structure, you've currently got the PresentInterval set to DEFAULT or ONE - set it to IMMEDIATE instead to achieve the maximum possible frame rate.

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

Ahhh, thats what it was thanks for the info :)
w00t! I was having a similar problem, and was stuck trying to find it through 'research'. I was about to post virtually the same question, lol.

Gotta love framerate going from 60 to 2100+ ;)

Question on this though, my game logic looks like this...

float time_since_last_frame = 0.0f;
while(true){
time_since_last_frame = get_new_time();
update(time_since_last_frame);
render();
}

Does this mean, then, that if you set the parameter to default or one, that when you call the directx render functions it will actually pause the entire program for an amount of time based on current refresh-rate?
Quote:Original post by trick
Does this mean, then, that if you set the parameter to default or one, that when you call the directx render functions it will actually pause the entire program for an amount of time based on current refresh-rate?
The only time Direct3D will block your program - ignoring things like Lock() calls - is when the CPU is getting too far ahead of the GPU. When that happens, Present() will block while the GPU catches up.

What's happening is this: pretty much every D3D call you make goes into a queue for the GPU to execute later. That includes calls to Present().

When your present interval is IMMEDIATE, then the GPU will perform the present as soon as it hits it. The buffers swap, you might get some tearing, but the GPU never stops burning through the queue.

When your present interval is ONE (or DEFAULT, which is the same as ONE) then the GPU can only perform the present during the vertical retrace. So, if it gets to the present while the monitor is still in the middle of things, it has to sit and twiddle its thumbs while it waits for the monitor to get to the end. While it's waiting for the monitor, the CPU is still queueing up new work... eventually the monitor gets to the end and the GPU performs the present - and because it happens during the vertical retrace, there's no tearing - but the queue's filled up something rotten while you were waiting for it.

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

[font=lucida sans unicode,lucida grande,sans-serif]My search for this is over now ... cool.png[/font][font=lucida sans unicode,lucida grande,sans-serif] [/font]

[font=lucida sans unicode,lucida grande,sans-serif]My search for this is over now ... cool.png[/font][font=lucida sans unicode,lucida grande,sans-serif] [/font]

Yeah, it only took you five years sleep.png

Please check the age of the topic before leaving a reply... the last activity in this thread dates from April 2007.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

This topic is closed to new replies.

Advertisement