Jump to content

  • Log In with Google      Sign In   
  • Create Account

DirectX app topping out at 60fps


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • This topic is locked This topic is locked
6 replies to this topic

#1 cstony   Members   -  Reputation: 436

Like
0Likes
Like

Posted 24 April 2007 - 02:01 AM

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

Sponsor:

#2 superpig   Staff Emeritus   -  Reputation: 1825

Like
2Likes
Like

Posted 24 April 2007 - 02:03 AM

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.

#3 cstony   Members   -  Reputation: 436

Like
0Likes
Like

Posted 24 April 2007 - 02:11 AM

Ahhh, thats what it was thanks for the info :)

#4 trick   Members   -  Reputation: 139

Like
0Likes
Like

Posted 24 April 2007 - 07:34 AM

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?

#5 superpig   Staff Emeritus   -  Reputation: 1825

Like
2Likes
Like

Posted 24 April 2007 - 03:54 PM

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.

#6 TheOrestes   Members   -  Reputation: 270

Like
-3Likes
Like

Posted 12 August 2012 - 01:56 AM

My search for this is over now ... Posted Image

#7 Bacterius   Crossbones+   -  Reputation: 9286

Like
1Likes
Like

Posted 12 August 2012 - 06:52 AM

My search for this is over now ... Posted Image

Yeah, it only took you five years Posted Image

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

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS