Hi Does Direct3D have FPS control builed in? I mean my game has allways 60FPS no matter what... it's 60 when displaying black screen and it's 60 when rendering a lot of stuff. Do you know how can i change it?

It was Vsync indeed :)

Now it's 170FPS not bad, but i expected more form blank screen "game" :D

Thanks

Quote:Original post by Error98
It was Vsync indeed :)

Now it's 170FPS not bad, but i expected more form blank screen "game" :D

Are you using the debug drivers, or release drivers?

Hmmm to be honest .. i don't know :)

I compiled it in "relese" mode if that what you're asking.

Since then i rewrite some parts of the code and it's 270FPS now

170 and 270 are not meaningful framerate values. At any framerate above your refresh rate you will receive absolutely no extra benefit, and the sorts of optimizations that get you from 170 to 270 on a blank screen are probably not the same optimizations that will get you from 20 to 40 on a full screen. Don't waste your time on trying to bump up the framerate until your frame rate is actually too low.

As a newb i don't know yet how FPS will react on some things.
I want to know how far i can push it :)

For example (and a realy dumm one ;)) i want to know



Will affect my fps rate and it's realy hard to say if no matter what you have 60 of them ;)

And i found which line drawing algorithms are more expensive then others.

Thanks for all your replys!! :D

Quote:Original post by Sneftel
170 and 270 are not meaningful framerate values. At any framerate above your refresh rate you will receive absolutely no extra benefit, and the sorts of optimizations that get you from 170 to 270 on a blank screen are probably not the same optimizations that will get you from 20 to 40 on a full screen. Don't waste your time on trying to bump up the framerate until your frame rate is actually too low.

Uh-oh, I'm going to comment against a moderator. ;-)

You're right about not bothering with the framerate for optimizations until it is actually too low. But figuring out how to get the highest possible framerate with release code and drivers is a very useful tool.

As one example, it can help beginners learn what operations are slow, and just how slow they are.

When experienced people tell you "Don't change rendering targets, it is very slow", you can use your nearly-blank-screen rendering to watch it drop a few thousand FPS, letting you learn that it really can take a few milliseconds to switch rendering targets on year-old hardware, or can be (relatively) fast on a brand new card.

Similarly, you can draw a few textured quads and (with that framerate measuring in the thousands) figure out that texture changes are not free, see how long it takes to load in new textures, compare keeping meshes on-card versus drawing primatives, look at the time required to read or write to an on-card mesh, or various other timing-related things.

frob.

Quote:Original post by frob
Uh-oh, I'm going to comment against a moderator. ;-)

It would be a very bad thing if nobody disagreed with moderators. I'm wrong far too often. [wink]

Quote:You're right about not bothering with the framerate for optimizations until it is actually too low. But figuring out how to get the highest possible framerate with release code and drivers is a very useful tool.

As one example, it can help beginners learn what operations are slow, and just how slow they are.

When experienced people tell you "Don't change rendering targets, it is very slow", you can use your nearly-blank-screen rendering to watch it drop a few thousand FPS, letting you learn that it really can take a few milliseconds to switch rendering targets on year-old hardware, or can be (relatively) fast on a brand new card.

I definitely think it's valid to test out rendering techniques for optimization purposes, even when a scene isn't fully loaded. The danger, though, is that you'll end up wasting time trying to optimize a portion of the pipeline that, ultimately, isn't going to be a bottleneck one way or the other. Example: when drawing an empty scene, on certain cards, it's possible that the bottleneck will be the time it takes to clear the depth buffer. When someone sees that, they might think to themselves, "damn, clearing the depth buffer makes my framerate drop from fifty kajillion to only twenty kajillion. The depth buffer clear must be a MAJOR inefficiency." Then they spend time trying to come up with tricks to accelerate the depth-clearing process (which, in reality, is an extremely cheap operation compared to just about everything else in the pipeline).

On a tangent: I think a much better number to compare than frames per second is seconds per frame. Frankly, I find it downright bizarre that it's standard to think about optimization in terms of FPS instead of SPF. For instance, what does a change from 170 to 270 FPS actually mean? It means that rendering a frame takes you two milliseconds less. In contrast, a change from 20 to 120 FPS means that rendering a frame takes you 42 milliseconds less. 100 FPS change either way, but I think the SPF representation makes it much clearer which optimization is better.

So I think we're pretty much on the same page here. You CAN get valid information out of scenes that aren't fully loaded, but you have to be careful, and keep in mind that you might be seeing a bottleneck that ultimately won't matter.

msPF perhaps? Otherwise we start to create the impression of games running VERY slowly ;)

(I have seen that happen, though. A friend of mine was once playing Baldur's Gate 2 on a laptop, and apparently it had some memory leak issues and was swapping like crazy... IIRC I clocked it at 18 SPF during one transition animation - when the user had no control over the app and the only options were wait it out or quit forcibly. Plus the animation was a set number of frames apparently >_< )