Jump to content
  • Advertisement
Sign in to follow this  
Alexander Orefkov

Register system function after build

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

I was try create app function, which dinamically register global function, whith name, signatures and address sended as arguments.

And than return created function as funcdef handle. Function registered without error, but programm is crashed after calling that from script.

I was investigate - for created function not called PrepareSystemFunction. After I was call it, its work correctly. But PrepareSystemFunction call only from PrepareEngine, and after build first module, all added after that app function stay unprepared?

Share this post


Link to post
Share on other sites
Advertisement

Hi Alexander,

 

I haven't designed the library with this case in mind. Currently it is possible to register new functions and object types after the first script has been build, and they will be prepared upon the next request to build a script.

 

To work around your current situation you can simply build an empty module right after registering the new function. That will prepare the function and allow it to be called from the script that registered it.

 

 

However, I'll investigate what can be changed in the library to make this case work without the need to do the 'fake' build.

 

 

 

May I ask how your script know how to register application functions? Can't you register the function even before building the script the first time?

Share this post


Link to post
Share on other sites

Thanks for reply, Andreas.

I will try some redisign my architecture for it.

I create some extention/plugin programm for some commercial app, which not have public documented api, and their "liver" little changed from version to version.

And users may have and worked with any different version of that app, sometimes even at the same time.

At first I wrote in C++, but now support interoperability with multiple versions at the same time - has turned into hell - changed func address, signatures, virtual table order, offsets in structs and many others.

So I decided to port my software to the AngelScript.

Now core of my programm first created some intermediate layer for call native function from extending app, and than run script on AngelScript.

And intermediate layer partially prepared with module on AngelScript too - I was simply register in script engine some of their "RegisterNNN" func :)

 

For example:

int registerObjectType(const CStringMy& objectName, unsigned size, unsigned typeFlags)
{
    return asEngine->RegisterObjectType(CStringA(objectName), size, typeFlags);
}
AS_FUNC(regType_as, "int registerObjectType(const string& in,uint,uint)", &registerObjectType);

int registerMethodByAddres(const CStringMy& object, const CStringMy& method, unsigned addr, unsigned cc)
{
    if (object.IsEmpty()) {
        return asEngine->RegisterGlobalFunction(CStringA(method), asFUNCTION(addr), cc, 0);
    } else {
        asSFuncPtr p(3);
        *(unsigned*)p.ptr.dummy = addr;
        return asEngine->RegisterObjectMethod(CStringA(object), CStringA(method), p, cc, 0);
    }
}
AS_FUNC(regMetAddr_as, "int registerMethodByAddress(const string& in,const string& in,uint,uint)", &registerMethodByAddres);

First I created "compatible" module and run it, it register API functions depending on version of running parent app, and than I create main module, which do main work.

But now I have developed some kind of declarative description for the creation of an intermediate layer for different versions, and the need for such a decision unnecessary.

Share this post


Link to post
Share on other sites

It's good to know you've worked around the problem. :)

 

I will still look into changing the code to support doing what you tried originally.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!