Share this post

Link to post

Share on other sites

I recommend determining the function ID one time only though, and not for every function call (if possible). GetFunctionIDByDecl() is quite expensive as the declaration has to be parsed, and then compared with the compiled functions to find the correct match.

It would also be possible to get the engine pointer and module name from the context.

Share this post

Link to post

Share on other sites

These values only change when you recompile the scripts in which the functions reside. Exactly how you store the values is up to you, it could be in global variables, or perhaps some script manager class.

I recommend that however you store the values, you update them just after compiling the scripts. This would be much like how you would manually load a dll and store the function pointers to the functions you wish to use.

Share this post

Link to post

Share on other sites

No, you don't want to keep too many contexts around, because they consume quite a lot of memory (depending on the stack size). You just need to keep the function ID.

If you have some particular function that is executed very frequently you may experiment with having a dedicated context just for that function. If you call asIScriptContext::Prepare(-1) the context will restore the state using the same function ID as the last time, saving a little time.

But in a game I don't think you'll find much use for this feature. I can't think of a script function that is executed that frequently.

You do not want to have to create a context for each script function call though, instead keep the context around and just call Prepare() on it again when executing another function. If you have the need to call more than one script function at the same time (e.g. a script function calling an application function that calls a script function), you could benefit from a pool of contexts.