Thread: Releasing IDirect3D8 Type

Hullo hullo :-)

Just to let you know, after finishing typing this, I realized it's pretty long. :-)

I've recently moved to bigger and badder things, but not wanting to have to rewrite my entire D3D engine, I just made copies of my .cpp files and threw a new project together with the intent of editing the old ones to meet my new needs.

Unlike I expected, this actually went pretty smoothly.

But an error came up with my new code that wasn't coming up before, even though all I did was delete code (no additions yet).

Here's some really simplified code of my scenario (Just assume all links/headers I don't write in are included as well since that's not what the problem comes from):
Note: The key fact is that m_pD3DDevice in both classes point to the same thing

Code:

Main.cpp
int main(void)
{
	Class1 *MyClass1 = NULL;
	MyClass1 = new Class1();

	if(MyClass1 != NULL)
	{
		delete MyClass1;
		MyClass1 = NULL;
	}

	return 0;
}
The Two Classes
class Class1
{
public:
	Class1(void)
	{
		m_pD3DDevice = NULL;
		MyClass2 = NULL;

		MyClass2 = new Class2(m_pD3DDevice);
	}
	virtual ~Class1(void)
	{
		if(MyClass2 != NULL)
		{
			// This line, fired before the next if,
			// will cause MyClass1's destructor to
			// fire. I'm pretty sure this is what's
			// causing the error (more description soon)
			delete MyClass2;
			MyClass2 = NULL;
		}
		
		if(m_pD3DDevice != NULL)
		{
			m_pD3DDevice->Release();
			m_pD3DDevice = NULL;
		}
	}
private:
	IDirect3DDevice8 *m_pD3DDevice;
	Class2 *MyClass2;
}

class Class2
{
public:
	Class2(IDirect3DDevice8 *pD3DDevice)
	{
		m_pD3DDevice = pD3DDevice;
	}
	virtual ~Class2(void)
	{
		// This is the central problem I'm focussing on.
		// When these 5 lines are here (below) I get
		// the windows error when I'm trying to exit
		// (The "Send Report to Microsoft" thing).
		// If I take them out, it all runs smoothly...
		if(m_pD3DDevice != NULL)
		{
			m_pD3DDevice->Release();
			m_pD3DDevice = NULL;
		}
	}
private:
	IDirect3DDevice8 *m_pD3DDevice;
}

Okay, I think that should all be rather fine. It might look a tad confusing at first, but all it really is, is two classes pointing to the same address.

So, the problem, I delete and NULL m_pD3DDevice in the destructor of Class2. Then, the destructor of Class1 tries to finish what it's doing, and it hits the If statement about it's own m_pD3DDevice.

Now that should technically already be NULL shouldn't it? Because I think the problem that's arising is from this line, and for some reason the program is still trying to do something with that variable, which causes the "Send Error Report" from windows.

What I'm wondering...
1) Is it okay to just remove the whole If statement from Class2 since Class1 will eventually delete and NULL it anyways? Will there be any reprecussions to Class2's member variable?
2) Is there a way to keep them both in? Because in my last project (the one I'm taking this code from), it's always been like that, and I've never encountered this problem.
3) How come the If statement in Class1's destructor isn't catching that it's already NULL?


Thanks for reading this all, it seems like a minor problem not worth such a long question being asked.

Today I learned the pitfalls of trying to find a fast way around using existing code.

Opening an existing .cpp file in a new project, doing "Save As" to a new location, editing that new file, and saving it. Well, apparently, the initial .cpp file will also be altered.

What did I learn? Don't be lazy, create new .cpp and .h files in your new project, then copy/paste the code.

So much for having an engine. Ah well, it shouldn't take too too long before it's back to how it was supposed to be.

Sang-drax:
I think I see what you mean, I'm NULLing the pointer, not what it's actually pointing to right? (I hope)

Bubba:
You're right Hehe, who would've thought eh?

Thinking about this some more, there's no real reason for this second class to exist. I was trying to be more organized, but it's just not turning out to be worth it (performance and time wise).

I'm just wondering, now that I'm whittling it all down into one D3D class, there's no point in making the IDirect3DDevice public anymore is there? (I won't even mention making it global) ...(I still can't believe you used the G-word). And I have absolutely no clue what namespaces are, they've just never really come up. But I think I'll do some research just so I know what you're talking about in those few lines there.

Thanks alot for the pointers (no pun intended) ... (well, maybe just a little one) ... I've almost got the code back to how it was, with the latest improvements.

Global variables are not all bad. Especially when your engine requires them. For instance a global pointer to all objects is not a problem. It provides easy access by all who need it and it does not require a function call just to get at something that everyone and their mother needs.

However if not everyone needs the variable or it is part of an object then don't make it global. Making the planet sphere's a global object in my engine would be a very bad idea. Only the planets and objects that use the sphere need access to it. In fact no one else should even touch the object so I made it protected to the CPlanet class, just in case one would need to derive from CPlanet....but they shouldn't ever need to. CSphere, however,is derived from CPrimitive since it is indeed a 3D geometric primitive. Making these global would be ludicrous.

But I see no problem with placing the IDirect3DDevice interface pointer in a class as a public member or in a namespace.

namespace MyD3D
{
IDirect3DDevice9 *Device;
}

To access::
MyD3D::Device

But how I'm using it comes from some books I've read. I make a global pointer to an IDirect3DDevice9 interface, then I pass the pointer to the Direct3DCreate() (actually another function in the namespace, not the actual D3D API Direct3DCreate()). After this is created then everyone has access to this. I pass this pointer along to every class that may need it. So essentially it only has file scope as it pertains to the main module. It does not have true global scope because it is not in a header - that would mean I would have to include that header for every class that uses it which is something I don't want to do.

So 99% of my classe's Create() functions all take this form.

void <class_name>::Create(IDirect3DDevice9 *_device,......)

Each class in turn has a pointer to the device interface. The downside to this is that you could essentially destroy the interface by releasing it accidentally in a destructor, but as long as you do not do this only the pointer is destroyed when the object goes out of scope, not the interface the pointer points to.

My entire setup is more of an object-render setup. Each object is responsible for rendering itself. This works well except for complex systems that share textures and characteristics like particle systems, sprites, etc. These are handled much differently and are all drawn in one render function. But those are the exception, the rest are handled in the class's render function. Most of them simply need the timeDelta passed to them so they can base their movements and updating based on frame time's.

So far it all seems to work very well. The pointers will be turned into vector lists by the time the engine is done. The vector lists will be populated with the current object database for the current system. Based on that list, the actual rendering system will build a render list for objects that need to be rendered.

The only problem I'm having is finding a good way to implement pixel shaders w/o having them so tied into one object. After all you might want to share an effect among objects yet the way it is setup in D3D is a bit different than that approach. I'm looking into creating huge effect files that encapsulate one effect applicable to all objects if needed complete with low-res or low-end versions of the same effect. The effects framework in D3D is a very nice way to do this.

Perhaps we should join forces. Contact me via PM and I'll hook you up on my teamspeak program. It's far easier to discuss these things than chat about them.

Thanks for the tips, I'm definitely going to be having to move to a system like that eventually, but sadly, I have to put aside this current project for the moment.

I haven't been around these boards in about a week due to exams and (I know I'll get hassled by lots of people for this but...) a Visual Basic *Shudders at the looks of disgust he knows he's receiving right now* project. For the sake of not having to spend a month greating a GUI, it just made sense

But in just three solid days, I've made a ton of progress, so I'm hoping it's not too long before I can pick this back up and stun you all with the most intense 2D action ever! Heh (Or maybe something better). But seeing some of the screenies that Bubba's been posting, it'll still be a while before I'm anywhere near that level.

Just wanted to say thanks again for the tips though, they've been huge in converting a flicker I liked to call my refresh rate into smoothly displayed scenery (Actually, not so smooth...I have some issues I'll be bringing up in the near future)