Quote:Original post by AntiGuy
Update: Well I reduced both and no go. It's almost as if I didn't change anything. I'd like to say it's all the vertex buffer issue but if I simply skip drawing I still get hit hard. I'm stumped.

You're rendering all the geometry in one batch using a single vertex buffer, and have taken all your textures down to a reasonable size (no bigger than 512x512) with mip-mapping enabled (right?) and it's still running slowly? Something is amiss.

I don't follow that second sentence in my quoted text. Do you mean that it runs slowly even if you don't submit the geometry to the video card? Changing state very frequently is highly detrimental to otherwise fast performance, but it shouldn't have too much effect when nothing is being drawn. Maybe the problem is more fundamental. I trust you have the debug runtimes enabled, with maximum debug spew, and are looking for performance warnings. If not, this comes before anything else on the to-do list [smile].

If things are no better after all that, then we'll need to see some code. And I don't mean to patronise, but are you sure the problem is in your render process and not something external clogging up your CPU?

By the way - sorry about the terminology. You translated correctly. For some reason, I always tend to assume people are using C++ [rolleyes].

Admiral

Your code looks fine to me.

You can maximise debug output by opening 'DirectX' in the control panel and putting the corresponding slider up to maximum. Now, when you run a DirectX program that's compiled with the debug libraries from VS++EE, the API will report anything it thinks you should know in the 'Output' window. You should keep an eye on this every time you test-run. It can save you a lot of time and a lot of headaches.

I must ask. If you comment out the calls to DrawLimb and DrawCharacter (and further, any other graphic-related calls) do you get the performance back? It's looking more and more like you're trying to fix the wrong problem [rolleyes].

But now that we've reached the point where the bottleneck isn't obvious, it's time to bring out the most powerful optimisation tool you'll ever need - the profiler. I don't have much experience with C#, but I've heard some good things about Ants. Language-independent alternatives would be VTune if you have an Intel processor or CodeAnalyst for AMD. Profile a few seconds of execution and look to see where most of the CPU time is being spent. If it's in your program then use the profiler to find out where, and fix it. On the other hand, if the time is being wasted in a device driver or a DirectX DLL then you'll need a different, graphics-oriented, profiler. Luckily for you, the DirectX SDK comes with PIX, with which you can isolate the bottleneck in no time.

So they are your orders. Report back with your findings [wink].

Admiral

Quote:All my textures are no greater than 200x200 and mip-mapping is enabled.

Now you do realize your card likely isn't a fan of non-power of 2 textures right? I took a quick look online at your card and couldn't find if it supported them or not. But make sure all your textures are like 32x32, 64x64, 128x128, 128x256, 256x128, 256x256, etc. Any combo of power of 2.

I know it doesn't seem to be the bottle neck but when I seen your 200x200 quote I worried :)