Last entry I mentioned about the use of IDirect3DResource9::SetPrivateData() and its ability to do auto-magical memory leak reporting. Take the following example:
LPDIRECT3DTEXTURE9 pTex = NULL;CreateTextureWrapper( pd3dDevice, 128, 128, 0, 0, D3DFMT_X8R8G8B8, D3DPOOL_MANAGED, &pTex, NULL );SAFE_RELEASE( pTex );
Shouldn't be a problem, and all thats changed is pd3dDevice->CreateTexture() becomes CreateTextureWrapper( pd3dDevice, ...). Simple use of #define's means that it resolves to the "native" call in a release build but in debug it'll "tag" it with memory tracking information.
The above example generates the following output when the application closes:
INFO: 1 resources were tracked, the following were not correctly released:INFO: NO tracked resources were leaked!
Now, if we instead choose to comment out the SAFE_RELEASE() call and introduce a memory leak, we get:
INFO: 1 resources were tracked, the following were not correctly released: Texture Details: Dimensions: 128x128, 0 mip-map levels in format 22 Usage: 0, pool 1 Texture was created on line 188 of 'OnCreateDevice()' [k:\internet\gamedev.net\directx forums\testbed\testbed.cpp]
Which I think is a whole lot more useful than the 2500 lines of debug output of memory addresses and stack traces [grin]
I've got to do some proper testing and I need to add handlers for other resources and functions (currently only textures are trackable), but the core concept is working well.
I'll see about posting up a proper explanation of this code as a longer journal entry next week when I've got it finished. Code will be available to anyone who wants it.
I'll probably be integrating it with XML logging technology for my personal projects - so I get a nicely printed message to the log file along with other general stack-trace type information that I normally get. Within reason there would be no reason why you can't tag it with other information that'll help you track down when/where/why it was created.
Stupid monsters hiding under the sink...