🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Problem with global property
Author
I have registered a global property, which is a pointer to a C++ object. The script is calling the class method but the object members have corrupted data and this tells me the object pointer must be invalid.
I register the class object and method like so:
CScriptManager::RegisterObjectType( "Object", 0, asOBJ_CLASS);
CScriptManager::RegisterObjectMethod( "Object", "void ScriptGameObjectTest()", asMETHOD( CObject, ScriptGameObjectTest ), asCALL_THISCALL );
And the global property is registered like so:
RegisterGlobalProperty( "Object GameObject", &mGameObject );
where mGameObject is a class member and the pointer to the CObject object. CObject* mGameObject;
Everything is registered without errors. This is then the test script:
void Test()
{
GameObject.ScriptGameObjectTest();
}
Before the script function is called I set the value of the mGameObject variable to the CObject object.
What am I doing wrong here since the CObject is not valid when it gets to the ScriptGameObjectTest() method?
This is the class method:
void CObject::ScriptGameObjectTest()
{
...
}
In other words, the "this" pointer is invalid.
Thanks
The this pointer is invalid because you passed a pointer to a pointer to AngelScript when registering the property, but you told AngelScript that you wanted to register only a pointer to an object.
Two solutions:
Alternative 1:
Alternative 2:
Since you want to change the address that GameObject property holds, you'll want the second alternative. For this to work you'll need to make sure the Object type accepts object handles, by having the ADDREF and RELEASE behaviours set.
Regards,
Andreas
Two solutions:
Alternative 1:
RegisterGlobalProperty("Object GameObject", mGameObject);Alternative 2:
RegisterGlobalProperty("Object @GameObject", &mGameObject);Since you want to change the address that GameObject property holds, you'll want the second alternative. For this to work you'll need to make sure the Object type accepts object handles, by having the ADDREF and RELEASE behaviours set.
Regards,
Andreas
Author
Does the second alternative mean a copy of the object is passed to the script? I would like to avoid the penalty of copying it if possible. But since the class is registered with a size of zero I'd think it can't make a copy...
If I add the ADDREF and RELEASE behaviors, what does that mean exactly? I'd like to understand what it does "behind the scenes".
Slowly I'll get the hang of how AS works and how to use it :)
If I add the ADDREF and RELEASE behaviors, what does that mean exactly? I'd like to understand what it does "behind the scenes".
Slowly I'll get the hang of how AS works and how to use it :)
Author
Adding the ADDREF and RELEASE behaviors and alternative 2 does indeed work. However now I'm unsure about what's exactly going on. Is a new object allocated and byte by byte copied or is it just using the pointer to the original object? I assume the ref count is incremented for the call and then again decremented at the end so the ref count should be back to 1.
Do I need to worry about this ref count at all, ie could I just have empty addref and release functions? The script is not supposed to create any objects or delete any on its own. The application should have full control over this. For now at least...
Thanks
Do I need to worry about this ref count at all, ie could I just have empty addref and release functions? The script is not supposed to create any objects or delete any on its own. The application should have full control over this. For now at least...
Thanks
When passing an object around by its handle, it is the pointer that is being passed around, no copies are being made. The ADDREF and RELEASE behaviours are called acording to how many variables are referencing the object.
You don't have to do anything in the functions registered for the ADDREF/RELEASE behaviours if you don't want to keep track of how many places a variable is holding a pointer to the object. However, then your application will be responsible for making sure the life time of the object is always longer than any of the variables that may be referencing it.
You don't have to do anything in the functions registered for the ADDREF/RELEASE behaviours if you don't want to keep track of how many places a variable is holding a pointer to the object. However, then your application will be responsible for making sure the life time of the object is always longer than any of the variables that may be referencing it.
Author
Thanks for the info! Yes, I handle all that in the app and the script is destroyed before the object so it's not a problem.
It's working now and I learned a bit more about how it works. :)
It's working now and I learned a bit more about how it works. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
