IDirect3D9 Necessary?

In the past, I've used classes for a Direct3D object to handle all necessary D3D calls, but now that I'm moving away from that, I'm curious...

During initialization, the IDirect3D9 variable is necessary in order to create the IDirect3DDevice9 device. However, following that, it becomes rather un-necessary (as far as my experiences go).

So, is there any real problem with just making the IDirect3D9 a local variable of a function, to be discarded once the IDirect3DDevice9 is created and initialized? It seems to me that the IDirect3DDevice9 is the only one I actually care about...

However, I have always read that I should de-allocate these object in the order I allocate them...

I.e. Make the IDirect3D9, followed by IDirect3DDevice9 means that the IDirect3DDevice9 should be released before the IDirect3D9. I guess, in simplest form, my question is, should I really have to follow this suggestion? (Or is it more than just a suggestion in this case?) :)

Thanks

Well I wouldn't release the IDirect3D9 interface until the engine shuts down, but you are right - it only serves to get you an interface pointer to IDirect3DDevice9. That is probably the only interface you will need as far as the base Direct3D object is concerned.

Just leave IDirect3D9 alone and release it when the game is over or shut down.

I disagree, the IDirect3D9 interface is useful. There are many methods which you should consider calling.

You can get the list here:

http://msdn.microsoft.com/library/de...idirect3d9.asp

But when you start writing non-trivial applications, you need to make sure your program will run on as many different configurations as possible, not just the development box.

All that is setup stuff. It should be done prior to anything else. So when he is all done with that, he should still leave the interface alone and not release it.

Quote:

---

Originally Posted by Bubba

- it only serves to get you an interface pointer to IDirect3DDevice9

---

I was responding to that part. That's not the only purpose of IDirect3D9 inteface.

I see. Well it does more than that, but I rarely use it after the setup for the engine is done.

Thanks for the comments guys.

It still seems to me though that once setup/enumeration's out of the way, it becomes meaningless to have around.

Sorry if I seem picky, but is there a concrete example of some issues that could arise down the road due to releasing the IDirect3D9 variable once you have your IDirect3DDevice9 created?

It seems to me a bit like when making a linked list. You have to create the temporary node variable, initialise it, then set a pointer to it. And once you have that, you don't need that temporary variable anymore and you can let the end of the function just clean it up since you'll never see it again, and you have what you needed from it. In this case, losing access to that temporary variable will never hurt you down the road.

Reasons for keeping it: I would understand if I needed access to an IDirect3D9 variable later, and its member functions. It would be redundant to create/initialise one for enumeration, and then create another one for my IDirect3DDevice9, and then another when I needed something else.

This however isn't the situation I'm in at the moment.

Not a reason for keeping it: I was told that it should stay until the end, back when I started DX. Everybody else does it too. So there must be a reason, just go with it. :)

I'm trying to avoid this reasoning and understand the situation a bit more in-depth.

I'd be happy to hear any more comments on this.

After looking around I found this quote on in the DirectX9 faq on msdn.

Quote:

---

Originally Posted by MSDN

Does it matter in which order I release DirectX interfaces?

It shouldn't matter because COM interfaces are reference counted. However, there are some known bugs with the release order of interfaces in some versions of DirectX. For safety, you are advised to release interfaces in reverse creation order when possible.

---

If releasing the interface in the beginning makes you sleep better at night, then do so.
Personally, I'd keep it.

I don't think a 4 byte pointer is worth all this debate in systems that usually have over 1 gig of RAM. If you want to keep it then do so. Release at your own risk.

It does matter what order the COM interfaces are released and I'm not sure why MS would put out two documents that contradict each other. Several DX SDKs and several DX books state that you should attempt to at least release the interfaces in the reverse order that you created them. I'm sure this has something to do with destruction and cleanup of memory and perhaps stack.

I know there are bugs in COM however and I think I've found one in DirectMusic when I attempt to release a sound segment. I get a first chance exception in debug mode but my C++ code checks out and should not cause the exception. I believe that the reference count is incorrect inside of IDirectMusicSegment9 for one reason or another or the SDK does not tell me that I should decrement/increment the reference count after using some of it's interfaces.

To be honest I haven't seen COM really do that much to the stability of the system. Nowadays games can crash and crash and crash, have COM resource leaks, etc, etc. and it doesn't seem to affect anything. You can run all 4 of my engines with the sound code and even though it generates that exception, you can play any game you want after the code is run with no frame rate issues. I think Windows XP does a very good job of keeping each program in it's own 'fence.'

Mkay, well thanks for all the input. I've decided to go back to the "Class" way of doing things again, which inherently tosses this problem out.

The reason I was curious before was because I was having difficulties keeping my D3D class independent of everything else (I.e. if I wanted to render a sprite, it had to be from the D3D class, and so on for everything else.) I've figured out a way to avoid this and now I'm back to working from the main() function, which is what I was shooting for when this problem came up:

Code:

---

int __stdcall WinMain(/*I forget what goes in here*/)
{
        IDirect3DDevice9* MyDevice;

        create_device(hWnd, &MyDevice);

        //Clean up the IDirect3DDevice9
}

int create_device(HWND *hWnd, IDirect3DDevice9** Device)
{
        //Create the IDirect3D9

        //Initialise/Create the IDirect3DDevice9

        //Toss away the IDirect3D9
}

---

Of course that's a simplified (maybe over-simplified, but I hope you get the idea) version of it. It was just so I wouldn't have that IDirect3D9 sitting around in the WinMain() function to be used once at the beginning, and then cleaned up at the end. It just seemed un-organized to me.

But now that it's all in a class, even though I don't use it, I guess I can handle it just sitting there since it's sitting there in a nice little package :) (Plus the whole avoiding bugs thing mentioned in the MSDN article).

Thanks again.

I'd make the device pointer global in your main game module. Then pass this to your classes and clean it up when the game is done.