Fps problem in windowed mode

Started by
9 comments, last by Deficite 21 years, 4 months ago
Hello, I''m just asking you guys what a reasonable fps for a windowed mode direct3d application would be? I''m running it on a P4 1.7Ghz with 256Mb RAM on a GeForce 3, desktop resolution is 1024x768x32 the app is 640x480x16. It seems to be a problem somewhere since it''s only running at 1100 fps when nothing is on the screen. Shouldn''t that number be much higher? What can I do to make it faster? Regards, Deficite
Regards,
Deficte
Advertisement
i think the slowest operation in all of direct3D is present. so it makes sense. in ut2003 there is one present call per frame, that takes .3 milliseconds on average, yet 100s of texture stage states which take a total of maybe .01 milliseconds
Thanks for the reply,

But when I test the SDK sample skinned mesh with a 3000+ polygon file it runs, on my system, at 1500fps. Isn''t that strange? I can create an application that runs a single window with nothing in it at 1100fps but when the sdk runs a sample with several thousand polygons it''s much faster. What am I doing wrong? What bottle necks are there?

I''m just creating a window, creating d3d and d3d device and start a message handling loop. All the application does is render a window using Clear, Begin, End, Present.

Thanks in advance!

Regards,
Deficite
Regards,
Deficte
did you test sdk samples also in 640x480x16?
Unfortionateley they are 400x200x16 I think, well the standard size of the "Progressive Mesh" sample program. But should that make such difference?

Regards,
Deficite
Regards,
Deficte
that might as well make the difference between 1100 and 1500 fps if you''re fillrate limited.

if you press F2, you can see the sdk samples in fullscreen.
Thanks alot for the replies!!

But 1100fps with nothing rendered and 1500fps (given that it''s a smaller resolution) with thousands of polys? Still seems weird

Regards,
Deficite
Regards,
Deficte
if you''re fillrate limited, time it takes to draw pixels in your window is significantly more than time it takes to move geometry to graphics card, send renderstates, etc. thus, drawing or not drawing a thousand-poly model won''t make much difference in framerate. however, resizing the window will make a difference.

640x480 = 307,200
400x200 = 80,000

when your app is running, gpu needs to draw almost four times as many pixels. use F2 to run the sdk sample in fullscreen at 640x480 and compare its performance with your fullscreen app.
Once again thanks!

Didn''t really consider that fact, but is sure is obvious. I believe that could be the trick. Will look into it.

I''m kinda new to D3D(as if you couldn''t guess) and would much appreciate help. You got any ideas of how to make a very simple yet robust d3d application. It only need to encapsulate creation of windows, d3d and such. The reason i ask is that I read somewhere that someone thought that the microsoft CD3DApplication framework was too slow, and that is was much better to create one yourself. Is this the case?

Regards,
Deficite
Regards,
Deficte
ms common framework represents a good balance between performance and readability. sure, it's not the fastest framework possible, but that's because it wasn't designed to be one. CD3DApplication is built for the following goals:

- provide a reasonably easy to understand framework so that you can get started with using it right away.

- provide a generic enough framework to satisfy requirements of various *simple* samples, such as the sdk and msdn ones.

- be easy enough to use for a programmer new to directx. since the samples use the framework, it should be understandable with only beginning knowledge of dx.

after using my homegrown mfc-based framework for a while i came to the conclusion that ms's design is better than my own. my present framework uses ideas and basic structure from ms common samples, but implements them in a somewhat different way (that i think is more efficient/extensible).

overall, ms sample framework is a very good start.

also, keep in mind that performance of the windows framework hardly affects overall framerate. concentrate on writing cleaner code than on faster code, it will pay off in the long run when you decide to improve your framework architecture.

[edited by - niyaw on December 10, 2002 4:49:55 AM]

This topic is closed to new replies.

Advertisement