   Better message than D3DERR_INVALIDCALL
  Is it possible to debug/step into a directx function call, such as DrawPrimitive(), or get cause of error (i.e., forgot to call SetFVF() ) rather than a bland D3DERR_INVALIDCALL?Would the 'symbolic constant' you can download along with the SDK help? Thx   
  Check the "DirectX Debugging" section of the FAQ.  The D3D Debug runtime was created just for this - to give detailed messages about errors that have occured.  It also gives a lot of warnings, which may hint at performance problems.  Otherwise, we would need about 15 billion HRESULTs for D3D alone [wink]   ;  Thx. The NeXe link works.The FAQ and NeXe only point out steps to link debug libs, compiler flags, etc., which is already set up by the SDK samples. Unless I missed key sections, I haven't found an example demonstrating what I need:Take DrawIndexPrimitive() for example, if D3DERR_INVALIDCALL is returned, many things could be the culprit:didn't call SetFVF()buffer overflowincorrect offestetc.It d be very helpful if instead an indicator mapping to one of the above scenario is returned or displayed somewhere.I remember there is a commercial tool for OpenGL that do the above. Wonder if MS already provides one.   ;Quote:Original post by parasolstarsThx. The NeXe link works.The FAQ and NeXe only point out steps to link debug libs, compiler flags, etc., which is already set up by the SDK samples. Unless I missed key sections, I haven't found an example demonstrating what I need:This is exactly what you need to do (a brief version of the Nexe article):(1) Enable Debug Runtime(2) Link the Debug Libs(3) Debug your application, step past the call that fails, and look at the D3D error messages in the Output window.This will give you detailed information about why the certain call failed.   ; Dustin's already covered the important parts, but a quick suggestion if you're new to the debug output...You'll quickly find out that it can generate lots (and I mean LOTS) of data... Thus working out which message comes from where can be a bit tedious. So, the tip of the day - when a function fails stick a OutputDebugString() in with a unique identifier. You can then run a search on the debug output for that unique identifier - whatever debug message is immediately above it refers to the call that failed [grin]Doesn't work too well for the V() and V_RETURN() macros used by the SDK, but it can be useful to remember.hthJack   