Jump to content
  • Advertisement
Sign in to follow this  
adder_noir

Odd clean-up error in class with DirectX9.

This topic is 2948 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

Within this class:

class load_soldier
{
//////////////////////////////////////////////////////////////
///DATA MEMBERS

....unnecessary code removed

public:
LPDIRECT3DINDEXBUFFER9 i_buffer;
LPDIRECT3DTEXTURE9 texture1;

....unnecessary code removed

}


I have made the two above pointers. I know I should really use auto pointers but I had some trouble getting them to work with native directX variables. For now I just want this to work with old fashioned pointers. Then I'll move over. My question is, given that I clean up these two pointer variables, and all available resources are present, why do I get the "Encountered a problem and needs to close" thing show up? I've carefully checked everything and I've narrowed it down to these two variables. Even wrote a function in the class to clean these two variables up.

Normally the only time I see that error screen on program close is if something didn't get cleaned up or a resource was missing. Yet I've carefully done it all. Is this some kind of scope issue? Has anyone any ideas, please just throw them out. Thanks, as always I'll rate people up who reply.

Share this post


Link to post
Share on other sites
Advertisement
how do you clean them up? you just need to call ->Release() on those directx objects when you quit the program or don't need them anymore (or if you use default pool when you reset your device but that's a different story).

did you activate directx debug in directx control panel?
it usually tells you which resources aren't released (among many other useful debug infos).

Share this post


Link to post
Share on other sites
Quote:
Original post by adder_noir
I know I should really use auto pointers but I had some trouble getting them to work with native directX variables. For now I just want this to work with old fashioned pointers. Then I'll move over.
Do you mean auto_ptr? Then no. This particular type of pointer cannot be adapted to work on pointers to COM objects (which is what DirectX objects are). Instead you need either CComPtr or shared_ptr (can also be done with intrusive_ptr but I don't have an example at hand).

Share this post


Link to post
Share on other sites
Yes sir I did do that. I'm probably borking something else. I don't know how to use this directX debug you mention. I am a n00b though (you'd better believe that one).

I could post the whole class (minus member functions of course) if that will help, but I don't want to waste forum space and annoy people (I do that well enough as it is).

I am also using vectors though and I'm fairly sure they complain if you do something odd with them. I can't for the life of me though think how these two pointers are tied up to anything that relates to a vector's size though. Hmm...

I need to learn how to use this directX debug thing. Any ideas? Sorry for n00b question but it is in the beginner's section ;o)

Share this post


Link to post
Share on other sites
Quote:
Original post by dmatter
Quote:
Original post by adder_noir
I know I should really use auto pointers but I had some trouble getting them to work with native directX variables. For now I just want this to work with old fashioned pointers. Then I'll move over.
Do you mean auto_ptr? Then no. This particular type of pointer cannot be adapted to work on pointers to COM objects (which is what DirectX objects are). Instead you need either CComPtr or shared_ptr (can also be done with intrusive_ptr but I don't have an example at hand).


Thank you also for your reply sir/madam.

Share this post


Link to post
Share on other sites
Fancy a laugh at my expense? Here goes.

If I add the two variables, load a texture and create an index buffer I get no run time error. If I run the function to clean them up I get an error. Go figure. Sounds like the destroy function is tyring to operate on variables that aren't there. How can they go out of scope when they're defined as data members in the same class?

Share this post


Link to post
Share on other sites
You can activate the debug in the directx control panel (dxcpl.exe). It comes with the SDK. Compiling your app with d3d9d.lib gives you even more debug output.

Here's a suggestion. Wrap your vertex and index buffers (and most likely all other directx interfaces) into custom classes.

Then you can use them without having to worry about cleaning up (+ better usability).

Here's a template for the vertex buffer. You could extend it with more functionality.


class VertexBuffer
{
public:

VertexBuffer(void)
{
vBuffer = NULL;
};

~VertexBuffer(void)
{
release();
};

void release()
{
if(vBuffer)
{
vBuffer->Release();
vBuffer = NULL;
}
}

void onResetDevice()
{
// handle device reset here
}

void onLostDevice()
{
// handle device loss here
}

void create(UINT _num_vertices, DWORD _fvf, D3DPOOL _pool = D3DPOOL_MANAGED)
{
release();

num_vertices = _num_vertices;
fvf = _fvf;
pool = _pool;
fvf_size = D3DXGetFVFVertexSize(fvf);

DX::device->CreateVertexBuffer
(
num_vertices * fvf_size,
0,
fvf,
pool,
&vBuffer,
NULL
);
}

void lock(UINT start, UINT count, void** ptr)
{
vBuffer->Lock(start * fvf_size, count * fvf_size, ptr, 0);
}

void unlock()
{
vBuffer->Unlock();
}

void fill(void* verts, UINT num_verts)
{
writeRange(0, num_verts, verts);
}

void writeRange(UINT start, UINT count, void* verts)
{
void* ptr = NULL;

lock(start, count, &ptr);

memcpy(ptr, verts, count * fvf_size);

unlock();
}

LPDIRECT3DVERTEXBUFFER9 getBufferPtr()
{
return vBuffer;
}

void set()
{
DX::device->SetFVF(fvf);
DX::device->SetStreamSource(0, vBuffer, 0, fvf_size);
}

UINT getNumVertices() { return num_vertices; }
DWORD getFVF() { return fvf; }
UINT getFVFSize() { return fvf_size; }

private:

LPDIRECT3DVERTEXBUFFER9 vBuffer;
UINT num_vertices;
UINT fvf_size;
DWORD fvf;
D3DPOOL pool;
};



From what you say you might try to call Release() on the objects twice but it's hard to tell. Post all relevant code which is involved in creating and destroying your class objects.

[Edited by - scope on August 26, 2010 6:03:54 PM]

Share this post


Link to post
Share on other sites
For the Direct X debugging output setting...go to Start->All Programs->[where ever direct X is install]->DirectX Utilities->DirectX Control Panel

Set use debug runtimes to true, set debug output to max...then check the output when you run / debug via VS

Share this post


Link to post
Share on other sites
That's great code. To be honest what I should really do is stop hassling people on here and buy a damn book on game engines and just follow the author's lead.

I'm really not going to get any further like this. I'd love to use someone else's engine but I find the documentation is always too poor and there's *always* a bug somewhere which no-one gives support for.

I'd be too embarassed to post up my code even though it's not too bad. Latest thing is the binary file (the .exe end product) is corrupted each run. I have to delete it to get the program to compile again. I'm going to have to accept I've outlived my skillbase's lifetime and do some proper acquisition of real textbooks on engine's. I see Morgan Kaufman do one. I'm also looking at an OU Computer Science degree. Might be a better way than picking through the darkness like I am here.

I'm very gratfeul for the help but for now I'm going to leave this one alone. Dodgy .exe files (switched to 'read only' for some reason) mean I don't know what I'm doing so I'll leave it for now :o)

Thanks mate.

Share this post


Link to post
Share on other sites
Quote:
Original post by GregMichael
For the Direct X debugging output setting...go to Start->All Programs->[where ever direct X is install]->DirectX Utilities->DirectX Control Panel

Set use debug runtimes to true, set debug output to max...then check the output when you run / debug via VS


Thanks to you too ;o)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!