# Do you ever have to release or free a D3DXHANDLE

## 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 on other sites

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 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 on other sites

You don't need to release it.

##### 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 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 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

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 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 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

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 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 on other sites
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.

Yea, D3DXHANDLE is a typedef of a const char*, but that doesn't mean it is a string. Just try it and read it as a null-terminated string, you won't get anything usefull.

It's done this way to allow you to use a string literal instead of the handle value found by some Get* call. Because the functions (for example Effect::SetVector) expect LPCSTR as the first parameter, you can directly write

SetVector("someName", &value)

or if you already have the handle, you can pass it instead of the string and it will also compile and work.

It's faster to get all needed handles once (at the start) and then just use them so the string comparisons and searching isn't done again and again. I repeat - the D3DXHANDLE value ISN'T actually a string, so using it does no string comparisons. As Squared'D said - Direct3D has a simple way how to distinguish the two cases (probably by some special bits), so it knows how to behave.

Edited by Tom KQT

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628345
• Total Posts
2982187

• 9
• 24
• 9
• 9
• 13