Skip to main content
gamedev.net
🔒 Locked

FindNextValidTechnique, bad pointers

Started by kirennian Sep 7, 2010 at 7:51 AM 3 replies 1.5k views
Original Post
kirennian
kirennian
Greetings all, I'm a long time reader yet first time poster on the forums so thought I'd best start with a hello. :)

Alas, my first post does however come aside a question with regards to the HLSL. I have managed to get the HLSL working should I explicitly specify which techniques are to be loaded and when; the aim of my program however is based around strict component based design, allowing the users (other programmers) to modify and add to the engine thus, explicit specifications are a currently unwanted biproduct of my problem.

I currently have my effects stored as part of a vector of structs:

//Loaded effects objects and their associated parts.struct D3EFFECT_BUFFER{  LPD3DXEFFECT effect;                    //Main effects object.  string fileNameID;                      //Effects file location.  vector<D3DXHANDLE> *techniques;         //Techniques present for the effect object.  //Constructor for the struct.  D3EFFECT_BUFFER(){    effect = NULL;                        //Default the effect object to NULL;    techniques = new vector<D3DXHANDLE>;  //Default, create the vector for use.  }};  vector<D3EFFECT_BUFFER> *vpv_dbEffects;


I am then attempting to load a new effect via an 'add' method for the vector...the beginning code is as follows:

//Adds a new effect object to the 'vpv_dbEffects' vector.HRESULT DeviceGfx::dbEffectAdd(const string &fileName){  //Check to see if the vector is valid.  If not, create it.  if(vpv_dbEffects == NULL)    vpv_dbEffects = new vector<D3EFFECT_BUFFER>;    //Create the effect from file in accordance with the fileName.    D3EFFECT_BUFFER* newEffect = new D3EFFECT_BUFFER();    if(FAILED(D3DXCreateEffectFromFile(v_d3dDevice, fileName.c_str(), NULL, NULL, NULL, NULL, &newEffect->effect, NULL)))        return DDIS_ERR;    newEffect->fileNameID = fileName;



Following this, I have attempted to iterate through each effect technique in two different ways:

1:
D3DXEFFECT_DESC desc;newEffect->effect->GetDesc(&desc);for(int x = 0; x < desc.Techniques; x(plusplus...code tags don't like the symbol here :())  newEffect->techniques->insert(newEffect->techniques->end(), newEffect->effect->GetTechnique(x));


2:
HRESULT hr = D3D_OK;D3DXHANDLE tech;hr = newEffect->effect->FindNextValidTechnique(NULL, &tech);while(hr == D3D_OK){  newEffect->techniques->insert(newEffect->techniques->end(), tech);  hr = newEffect->effect->FindNextValidTechnique(NULL, &tech);}vpv_dbEffects->insert(vpv_dbEffects->end(), *newEffect);




Both of the above attempts respond by returning a bad pointer...the first with the description will find two techniques and iterate correctly yet return a bad pointer for each, the second will get stuck in an infinite loop as the HRESULT is always S_OK.

Does anyone happen to have any ideas of where I'm potentially going wrong or for alternative workthroughs for the problem?


Thanks for your time...
Original prototype - The Small Step Engine. www.tssengine.com
Gage64
Gage64
This probably isn't related to your problem, but I wanted to mention/ask a couple of things:

1) Why are you allocating the vectors on the heap? It would be simpler to store them by value.

2) Instead of using insert() like that, you can use push_back():

newEffect->techniques->push_back(newEffect->effect->GetTechnique(x));

3) ++ is not visible only in the preview, it will show up in the post.

BTW, how do you see that the pointers are bad? Also, do you get any error messages from the debug runtimes?
kirennian
kirennian
1)I presume you mean dynamically creating the object during runtime of the program rather then at the beginning of class creation? I'll be the first to admit my lack of technical understanding in this area... in all honesty, in this case, the vector allocation isn't supposed to be during the add method call, it was down to allocation in this way in other parts of my program which I copy/pasted and modified...e.g. when vectors are needed to be null when empty. This habit was more akin to my earlier programming days where I used to be 100% certain the vector was created... which in itself, has a number of pitfalls.

2)Again, probably a performance issue overlooked, I should change more then just this vector if I'm honest. ;)

3)Thanks. :)

4)I insert a break point just after the command then use visual studio lookup (run the mouse over it) and navigate to the technique in question, showing a 'bad ptr' instead of the LPCSTR the D3DXHANDLE is supposed to equate to.
Original prototype - The Small Step Engine. www.tssengine.com
Evil Steve
Evil Steve
Quote:
Original post by kirennian
4)I insert a break point just after the command then use visual studio lookup (run the mouse over it) and navigate to the technique in question, showing a 'bad ptr' instead of the LPCSTR the D3DXHANDLE is supposed to equate to.
A D3DXHANDLE isn't necessarily a string at all, which means you may well see "bad ptr" if the debugger tries to interpret it as a pointer. From the Documentation:
Quote:
If you view the header files, you'll notice that handles (D3DXHANDLEs) are technically string pointers.

The handles that you pass into functions such as GetParameter[ByName|Element|BySemantic] or GetAnnotation[ByName] can be in three forms as follows:

1. Handles that were returned by functions such as GetParameter[ByName|Element|BySemantic].
2. Strings such as MyVariableName, MyTechniqueName, or MyArray[0].
[snip]
kirennian
kirennian


Okay, I originally tested that they were working through supplying the program with the technique name, then removed this call for loading it automatically. The bad ptr messages threw me and really, I should have tested it despite the error; this is however, the first time I've seen an item display an apparent error yet had it run without the said fault rearing its ugly face. I guess I learnt something today. I did only upgrade from VS2005 to VS2010 yesterday though so perhaps I should have been a little more pessimistic... or maybe optimistic, whichever way you view it. :)

Thanks guys, much appreciated and Steve, your name prefix of Evil doesn't hold true. :D
Original prototype - The Small Step Engine. www.tssengine.com

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.