Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

kovacsp

Direct3D debugging in VS.NET

This topic is 5155 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, You know, there is the Start with Direct3D debugging option in the Debug menu of Visual Studio after installing the dx9 SDK. I tried it, but most of the time, it is unable to show me the render targets and the textures. I think it showed me only once, it was when steeping through a vertex shader (as far as I remember). What does it need to be able to show these? FYI: -I''m using the debug version of dx, and -I''m between BeginScene and EndScene what else does it need? Thanks for your help, kp

Share this post


Link to post
Share on other sites
Advertisement
I think you need to use the reference rasteriser - you can''t debug with hardware acceleration (I know, it sucks).

-Mezz

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Insert breakpoints in your render loop and see if that helps to view the surfaces.

Share this post


Link to post
Share on other sites
I think I have the solution...

From http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/graphics/Tools/ShaderDebugger.asp

"The Visual Studio .NET debugger supports debugging of multiple program types at the same time. Typical C++ debugging uses the "Native" program type. Direct3D debugging uses the "Direct3D" program type. When the application you are debugging stops in C++ code, the current program will be set to Native, and the call stack, watch window, and other debug windows will reflect the state of the Native program. Similarly, when the application you are debugging stops in shader code, the current program will be set to Direct3D, and the debug windows will reflect the state of the Direct3D program. To switch between program types, use the Program combo box on the Debug Location toolbar. Note that when the application you are debugging is stopped in Native code, >>most of the state of the Direct3D program will be unavailable.<< The reverse is not true, however. If you stop at a breakpoint in a shader, for example, you can switch to the Native program and see the C++ call stack that caused your shader to be invoked."

And true, if I break in a shader, I can see both the surfaces and textures, but if I''m not in a shader, just my directx code, all is "unavailable".

Correct me if I''m wrong, I would be very happy if this was not true.

kp

Share this post


Link to post
Share on other sites
If you choose "Start with DirectX debugging", the NORMAL debugging process (for NORMAL C/C++ code) is treated as it is under normal debugging.

Basically, star with DirectX debugging is only really useful for Shader debugging - however you also have to use refrast (or at least software vertex processing for vertex shaders).





Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!