Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 17 Nov 2009
Offline Last Active May 31 2013 02:12 PM

Posts I've Made

In Topic: Flicker in Direct3D9 video

12 March 2013 - 06:53 AM

OK, I ran PIX and here are some results. First, I selected "Statistics for each frame, using counterset" with a custom counter set which displayed FPS and %Processor Time. I got this:



Yellow is %Processor Time, red is FPS. So if I understand correctly, virtually all of the frame time is consumed by the CPU. On the other hand, FPS oscillates wildly between 60 and below 25. That seems consistent with the flicker I experience (it doesn't happen all the time; it fluctuates).

Then I closed the test program and looked at the timeline:




So it would seem I'm CPU bound, which seems to be consistent with %Processor Time being at 100%.

First of all, is my analysis correct? Second, why does FPS vary so wildly? And then, how should I go about looking further into this? I thought of enabling draw timing and looking at a frame where instantaneous FPS is low, to see which calls consume more time.

In Topic: Flicker in Direct3D9 video

11 March 2013 - 01:13 PM

I got PIX working now; my test crashed on exit and it seems that messed up PIX's sampling. So now I'm learning how to profile and analyze the results properly, since I only used PIX's "Debug this pixel" feature before. I'll get back with results later.

In Topic: Setting world matrix on shader not working

08 March 2013 - 12:18 PM

In your code you have this line (although it might just be an example as you commented it out:

Now m_pEffect->setParameter( "g_matWorld", pNewVal );

Shouldn't pNewVal read &worldMatrix here?
Just my 2 cents


It does look inconsistent out of context, doesn't it? It's actually OK since that call is wrapped inside a setter-style method which receives pNewVal as a parameter. The others don't have that style because they received a local variable with that name.


My original problem is solved now; I didn't know that it was necessary to call CommitChanges if you changed effect parameters while rendering a pass. I'll now apply the performance tips the other guys gave me and see how it goes.

In Topic: Setting world matrix on shader not working

07 March 2013 - 10:40 AM

As I suspected, if you set an effect parameter while you're between Begin() and End() calls, you need to call CommitChanges for the effect to notice the change. So now that I call that function after setting the g_matWorld parameter, everything works fine again.


However, I now need to call CommitChanges for each of my texture quads. I'm gonna check with PIX, but isn't this inefficient? Is there another, more efficient, way to position my textured quads before drawing them?

In Topic: Present fails randomly on C++ Direct3D9 app

27 April 2012 - 07:31 AM

@Adam_42: It's an Nvidia quadro NVS 290, drivers version:
@Everyone: We made a little change and the error seems to have disappeared. When getting the viewport dimensions, we were using ::GetWindowRect instead of ::GetClientRect. Now that we're using the second function, the error seems to not happen anymore. We came up with this idea when we compared the differences between the client's software version and ours. If the error happens again, I'll try your suggestions, that is, updating graphic drivers first, checking debgu spew later.