Destroying DX8 objects in VB

Hi.

DirectX looks a lot like COM because it uses COM, so all the usual rules apply:

1. Provided you destroy all the base structures, everything will be destroyed for you, but the debug runtime will warn you, as it assumes you want to destroy everything manually. It is good programming practice to destroy every object you create (so DX4VB is breaking convention there) in order to help you track down memory leaks that may appear later:

2. When you no longer require a resource, particularly one resident in video memory (textures, shaders, VBs, IBs) you should release it. Imagine a scenario where your app creates textures as you enter parts of the world that needs them. If you don't release the textures as they go out of range, but your player traverses the whole world, he's looking at a D3DERR_OUTOFVIDEOMEMORY (or poor performance in the managed case). If you release an DirectX object without releasing one of its children, the debug runtime will warn you of the 'memory leak' (even though it isn't necessarily or strictly a leak). The idea is that if you release everything you are aware of, on termination you'll be alerted of any outstanding resources.

3. No. Ever since Windows 3.1 (and equivalent versions of other operating systems), usermode apps have been launched in protected mode. The idea is that no app is aware of other apps' memory space (without going via the API) and if anything untoward happens, then entire process can be terminated without affecting anything else. Naturally, this means upon closure, all allocated memory is released. Unless you are using some funky interfaces (DX doesn't qualify here), services, drivers or anything else below ring3, system-wide memory leaks are not a possibility.

The DX runtime debug-spew ends up in Visual Studio's 'Output' window in C++, but I'm not sure how you can capture it from the VB IDE. The interface used is OutputDebugString(), which I think redirects to the 'Immediate' window in VB6. I haven't the foggiest when it comes to VB.NET.

Regards
Admiral

Thank you very much. Now in practice, I assume that in VB to "release" means that I can:

1. For a local object variable (not static) in a procedure, allow it to fall naturally out of scope as my procedure ends.

2. For a static object variable in a procedure, set it to nothing.

3. For a module level variable set it to nothing.

Is 1. proper or should I set it to nothing before the procedure ends?

Thanks again!

Hmm. I seemed to have forgotten that VB takes care of reference counting and calling Release(). I figured that you'd have to call IDirect3DWhatever8.Release as I'm so used to in C++ but it seems DxVBLibA doesn't expose that function [rolleyes].

So perhaps it isn't quite as critical as I made out then. Indeed, your action plan on how to treat resources is right on the money. If you need to though, setting a local resource to Nothing will free up all the memory immediately: It won't cause any problems when the sub/function returns.

Regards
Admiral

I see what you mean. I have actually typed in MyObject.Release in all small letters and VB capitalized the "release", like it knew what I meant, but was unwilling to perform it and I'm pretty sure it gave me a compile error. So the set to nothing appears to be the most explicit way I can do it. As an experiment I tried setting to nothing before setting the variable to a whole new object, and got a very very slight speed decrease. Because I may or may not trust VB in this case, I think I'll want to set to nothing rather than merely rediverting the variable.