Jump to content
  • Advertisement
Sign in to follow this  
davepl1968

Do you ever have to release or free a D3DXHANDLE

This topic is 1752 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

If I have a piece of code such as this:

 

    D3DXHANDLE hTechnique = _pEffect->GetTechniqueByName("ExplosionTechnique");

 

When I'm done, or exiting, or an error occurs, what do I do with hTechnique?  

 

I'm -guessing- that the handles don't increase a ref count on the effect and that it's just up to me to make sure i use the handles within the lifetime of the effect itself.  But I can't really find any docs on it, and no sample code shows them being released.

 

Still, I'm one of those folks who doesn't like my code to leak anything under any reasonable scenario, so I'd like to make sure I'm doing the right thing!

 

Thanks,

Dave

Share this post


Link to post
Share on other sites
Advertisement

GetTechniqueByName provides a pointer to existing memory for you to use, it is just a pointer= a 32bit or 64bit local variable. In the code you have written, the variable that stores the address, namely hTechnique is just local, so you treat it like you would treat

float hTechnique=0.0f;

no need to manage hTechnique itself, But in case you want to drop the technique as a complex resource of dx, call release on it, and make sure that the technique will not be used anymore ofcourse. (this leads to good code, you do not attach technique to mesh or such abstraction, but to your own shader object, freeing a technique of a shader means you actualy want to free a shader, and if shader is your own class, you can smart it up, since it is a shared object).

Share this post


Link to post
Share on other sites

But how do you call release on it?  It's not a COM object or pointer, it's an opaque handle.  Is there a special release function for D3DXHANDLEs that I'm not seeing?

 

Thanks!
Dave

Share this post


Link to post
Share on other sites

Every Effect has multiple techniques, as promit said, no point in releasing some of them and use the effect. If you want to free them. free the entire effect.

Share this post


Link to post
Share on other sites
From the function declararion, it looks like you are using DirectX 9. Am I correct? In Direct X 9, those handles are merely a way to identify the technique so you can set it. Setting the technique using a handle is faster than using it's name each time because string comparisons can be slow. The method GetTechniqueByName is used so you can get the handle once and just use it. It's only an identifier. As far as I know, you can't release or delete a technique without freeing the whole effect. Here's more info http://msdn.microsoft.com/en-us/library/windows/desktop/dd607390(v=vs.85).aspx

Share this post


Link to post
Share on other sites

From the function declararion, it looks like you are using DirectX 9. Am I correct? In Direct X 9, those handles are merely a way to identify the technique so you can set it. Setting the technique using a handle is faster than using it's name each time because string comparisons can be slow. The method GetTechniqueByName is used so you can get the handle once and just use it. It's only an identifier. As far as I know, you can't release or delete a technique without freeing the whole effect. Here's more info http://msdn.microsoft.com/en-us/library/windows/desktop/dd607390(v=vs.85).aspx

 

Actually, from d3dx9shader.h:

typedef LPCSTR D3DXHANDLE;

A D3DXHANDLE is just a string.

 

I believe that the MSDN page you've linked is slightly misleading; what should be the slower part is all of the Get* calls, as they would require parsing the effect and searching for the name.  Doing them upfront at creation time rather than at runtime should mean that once you have the handle - I'm assuming (i.e. I haven't seen the source code for D3D9 Effects so I don't actually know...) that Effects is using a hash table or similar container to map each handle to it's register slot - it's actual underlying register can be retrieved more quickly and without all of the parsing/searching.

 

The fastest way of all is of course to bypass all of this and just call Set{Vertex|Pixel}ShaderConstant directly yourself, but if using Effects that's not necessarily going to be the most practical.  This is what all of the Effect::Set calls ultimately end up doing, however, as you can observe for yourself if you attach an ID3DXEffectStateManager to your effect.

 

Neither the debug runtimes nor PIX will report a D3D resource leak on handles.  It seems reasonable to work on the basis that the ID3DXEffect owns the memory used for them and that memory is destroyed when the Effect is Released.

Share this post


Link to post
Share on other sites
I would definately set them to NULL (in the destructor, if it's a member of your class).
Just to be sure.

Say you create/ load a new 3d scene with different shaders (in the same application), it would help you if you forget to set the handle (because it would be null, and won't crash without knowing where to look)

Share this post


Link to post
Share on other sites

 

From the function declararion, it looks like you are using DirectX 9. Am I correct? In Direct X 9, those handles are merely a way to identify the technique so you can set it. Setting the technique using a handle is faster than using it's name each time because string comparisons can be slow. The method GetTechniqueByName is used so you can get the handle once and just use it. It's only an identifier. As far as I know, you can't release or delete a technique without freeing the whole effect. Here's more info http://msdn.microsoft.com/en-us/library/windows/desktop/dd607390(v=vs.85).aspx

 

Actually, from d3dx9shader.h:

typedef LPCSTR D3DXHANDLE;

A D3DXHANDLE is just a string.

 

I believe that the MSDN page you've linked is slightly misleading; what should be the slower part is all of the Get* calls, as they would require parsing the effect and searching for the name.  Doing them upfront at creation time rather than at runtime should mean that once you have the handle - I'm assuming (i.e. I haven't seen the source code for D3D9 Effects so I don't actually know...) that Effects is using a hash table or similar container to map each handle to it's register slot - it's actual underlying register can be retrieved more quickly and without all of the parsing/searching.

 

 

Actually in DirectX 9, the handles can be strings or the values returned by the Get*ByName methods. You can use either when you call Set*. The Get*ByName functions return handles using string pointer types, but they are not real pointers. They are not real memory addresses. I don't remember exactly, but when looking at the value in a debugger a year or so ago, they set the high order bits to 0xff or some other special code so the functions know the handles coming in are not strings but these special handles that they use.

Basically, when you set techniques or textures or matrices, etc using the DX9 effects methods, the handle can be a real string, or the value returned by the Get*ByName funtions.

Edit: The Get*ByName functions should be called only once after the effect has been loaded. You should just save the handles somewhere and use them when you need them as using the handles returned from the Get*ByName functions will be faster than using the actual string name every time.

Edited by Squared'D

Share this post


Link to post
Share on other sites
I use them exactly as that, when you make a smart function using semantics you can have handles to the minimal neccessary shader constants in your shader class.giving flexibillity and preventing mistakes. This is what I do myself and in both the constructor and the destructor I set them to null.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!