• entries
    422
  • comments
    1540
  • views
    488809

I'm alive

Sign in to follow this  
jollyjeffers

177 views

Just a quick entry really... not been an update for a while due to being very busy. Having to hide away for those damned exams meant that other stuff got pushed to one side thus I now have to play catch-up [headshake]

I'm also off out to Ye Olde Trip to Jerusalem - the oldest Inn in England. It's an absolutely beautiful pub set into some of Nottingham's caves (yes, you get to sit in a cave and drink beer!). Oh, and it is indeed only 3.30pm.

Anyway, I just wanted to add two things.

Seems like the classic Z-Buffer help page, http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html, has gone offline. Which is a damn shame. Someone in the DX forum pointed towards a mirror/cache of it here. Phew - would be a real shame for it to disappear completely.

Also, I'm writing up a lengthy FAQ entry on Direct3D memory leaks. Oh the fun.

This DirectXDev mailing list thread was a pretty good resource - I remember reading it at the time and thinking it was useful. Now its in the FAQ.

Wessam's idea about using SetPrivateData() isn't new to me as such, but for whatever reason I've never bothered to check it out properly. I knocked up a simple clone of his post today - can't help but grin at how useful a trick it is. Think I'll probably push it further and write a full example for this journal/forum...

Anyone got any tricks for finding D3D memory leaks that they think are FAQ-worthy??
Sign in to follow this  


4 Comments


Recommended Comments

The "Break On AllocID" box in the DirectX control panel works well for finding what is leaked, providing you get the ID from the debug pane after your app closes, but I don't know if that's FAQworthy.

Edit: I would also strongly recommend using Boost "intrusive_ptr"s as smart pointers for wrapping COM objects, but you have to be careful since their default constructor adds a reference.

Share this comment


Link to comment
How are d3d memory leaks different from conventional ones? Couldn't you use mmgr or efence or MallocGuard or something like that to track 'em down?

Share this comment


Link to comment
Quote:
Original post by Ravuya
How are d3d memory leaks different from conventional ones? Couldn't you use mmgr or efence or MallocGuard or something like that to track 'em down?


Not necessarily. All D3D interfaces use the COM setup, so they keep reference counts of each instnace of every objects. Because of that, I think the VS output records what instances weren't deleted by spitting out the allocid at program close.

Share this comment


Link to comment
Thanks for the replies!

Quote:
The "Break On AllocID" box in the DirectX control panel works well for finding what is leaked, providing you get the ID from the debug pane after your app closes, but I don't know if that's FAQworthy.
That, as well as the D3DX regedit thing are mentioned already - but thanks anyway [smile]

Quote:
I would also strongly recommend using Boost "intrusive_ptr"s as smart pointers
I'm not familiar with boost's features. I've included references to ATL's CComPtr though - I gather that is similar 'smart pointer' technology.

Quote:
How are d3d memory leaks different from conventional ones?
As Cypher said - they're via the COM interface, so you dont actually "new" anything - its all via interfaces, factory methods and reference counting. mmgr and the default VStudio checks dont pick up on D3D memory leaks.

Cheers,
Jack

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now