Sign in to follow this  
jagguy

initializing directX

Recommended Posts

1)I am confused with this bit of code to lock before a vertices copy. Why do a cast of void** and pass an address of a pointer. Why do you need to recast the void variable with **, why use a VOID variable? I don't underdstand this basically. VOID* pVertices; if( FAILED( g_pVB->Lock( 0, sizeof(Vertices), (void**)&pVertices, 0 ) ) ) 2) in directx you can declare pointer directx types like this, this is not the same as straight c++ as no dynamic space is allocated using new. Do directX types like this work differently to regular c++ so you dont need NEW LPDIRECT3D9 g_pD3D

Share this post


Link to post
Share on other sites
Quote:
Original post by jagguy
1)I am confused with this bit of code to lock before a vertices copy.
Why do a cast of void** and pass an address of a pointer. Why do you need to recast the void variable with **, why use a VOID variable?
I don't underdstand this basically.

VOID* pVertices;
if( FAILED( g_pVB->Lock( 0, sizeof(Vertices), (void**)&pVertices, 0 ) ) )

In that case, you don't need the cast to a void** actually. The reason Lock() takes a void** is that it can take any sort of input. If Lock() succeeds, then whatever you passed the address of in the last parameter (pVertices in your case) is set to point at the start of the buffer. Because a vertex buffer can contain several types of vertices, even more than one type at a time, D3D takes a void*, not a pointer to a predefined vertex structure. I tend do do the following:
Vertex* pVertices;
if(FAILED(g_pVB->Lock(0, sizeof(Vertices), (void**)&pVertices, 0))
(Assuming Vertex is my vertex structure) That way I don't have to do any extra casting, and I can access the vertices in the buffer by accessing pVertices, and I can do ++pVertices; to move to the next vertex.

Quote:
Original post by jagguy
2) in directx you can declare pointer directx types like this, this is not the same as straight c++ as no dynamic space is allocated using new. Do directX types like this work differently to regular c++ so you dont need NEW
D3D uses COM. You can think of it a bit like using new and delete behind the scenes. D3D will allocate the memory internally (E.g. when you call Direct3DCreate9()) and give you a pointer. Calling Release() on an interface (E.g g_pD3D->Release()) is effectively the same as calling delete on it. There's a bit more to it that that however, because COM interfaces are reference counted.
You should never call new or delete on a COM interface unless you're actually implementing one yourself.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil SteveIn that case, you don't need the cast to a void** actually. The reason Lock() takes a void** is that it can take any sort of input. If Lock() succeeds, then whatever you passed the address of in the last parameter (pVertices in your case) is set to point at the start of the buffer. Because a vertex buffer can contain several types of vertices, even more than one type at a time, D3D takes a void*, not a pointer to a predefined vertex structure. I tend do do the following:
Vertex* pVertices;

if(FAILED(g_pVB->Lock(0, sizeof(Vertices), (void**)&pVertices, 0))
(Assuming Vertex is my vertex structure) That way I don't have to do any extra casting, and I can access the vertices in the buffer by accessing pVertices, and I can do ++pVertices; to move to the next vertex.

D3D uses COM. You can think of it a bit like using new and delete behind the scenes. D3D will allocate the memory internally (E.g. when you call Direct3DCreate9()) and give you a pointer. Calling Release() on an interface (E.g g_pD3D->Release()) is effectively the same as calling delete on it. There's a bit more to it that that however, because COM interfaces are reference counted.
You should never call new or delete on a COM interface unless you're actually implementing one yourself.


1) I am unsure about what this means as you have a pointer to pointer of a address.
((void**)&pVertices)? this is unusual code as

2)so the directX types don't work like regular C++ typedef variables as correct syntax is done behind the scene, is this right?

Share this post


Link to post
Share on other sites
Quote:
Original post by jagguy
1) I am unsure about what this means as you have a pointer to pointer of a address.
((void**)&pVertices)? this is unusual code as
It's not that unusual. It's the only way of returning a pointer from a function without having it as a return value.
If a function took an int*, it can change what the pointer is pointing at (the int), but not the pointer itself (the int*). If a function took an int**, it can change what the pointer is pointing at (the int*), but not the pointer itself (the int**). It's the same idea with void pointers too.
It's a pointer to a pointer.

Quote:
Original post by jagguy
2)so the directX types don't work like regular C++ typedef variables as correct syntax is done behind the scene, is this right?
Pretty much, yeah. Just don't worry about them too much. So long as you Release() interfaces when you're done with them, and you don't try to create any interfaces yourself (E.g. with new), you'll be fine. You won't be able to use new to create D3D objects anyway, since they're just interfaces and contain pure virtual functions.

Share this post


Link to post
Share on other sites
It's perfectly normal C++, jagguy.

If you want a function to change a value, say an int, you'd define it as accepting a pointer to an int (for example f(int * v)). If that function is supposed to change a pointer, it gets a pointer to that pointer. For example:

void f(int** v) { *v = new int[5]; }

This function allocates an array of ints and returns that pointer inside v.

That's basically what Direct3D is doing. You pass it the address of a pointer variable, and it puts in it some data that it has allocated itself.

Ignore the deal with COM for now. It's not that different. All you have to remember is to use Release() instead of 'delete' when you're finished with your data.

(Heh, I should answer more quickly. :))

Share this post


Link to post
Share on other sites
Quote:
Original post by jagguy
maybe I need another example with an array to understand it better **
To be honest, if you're having trouble with pointers you might either want to start a seperate thread in For Beginners, or just take a few steps back and sit down with a good introductory C/C++ text [smile]

hth
Jack

Share this post


Link to post
Share on other sites

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

Sign in to follow this