Sign in to follow this  
_Engine_

Loading binding data

Recommended Posts

_Engine_    310

Hi!

 

Currently when we load scene in our engine we make lots of bindings. And this become huge bottleneck even on pc with iCore 5. So it is possible to save code bindigs and load this info like precompiled bytecode?

Share this post


Link to post
Share on other sites
WitchLord    4677

With bindings do you mean 'imported functions'? 

 

How many imported functions do you have? How big is this 'huge bottleneck' in seconds? 

 

Is the long loading times coming from the LoadByteCode method or from the BindAllImportedFunctions method?

 

It's not possible to save the bindings with the bytecode, but I can certainly look into optimizing the code if needed.

Share this post


Link to post
Share on other sites
_Engine_    310

After loading scene we are make bindings of c++ classes and do something like this:

 

Machine()->RegisterObjectType(class_symbol_inst, sizeof(NGUISymbolInstance), asOBJ_REF| asOBJ_NOCOUNT);
 
for (int i=0;i<prop.size();i++)
{
   prop[i]->EmbedingScript();
}
 
Machine()->RegisterObjectProperty(class_symbol_inst, "ref handle",offsetof(NGUISymbolInstance, script_handle));
Machine()->RegisterObjectMethod(class_symbol_inst, "bool IsVisible()", asMETHOD(NGUISymbolInstance,IsVisible), asCALL_THISCALL);
Machine()->RegisterObjectMethod(class_symbol_inst, "void Show(bool show)", asMETHOD(NGUISymbolInstance,Show), asCALL_THISCALL);
Machine()->RegisterObjectMethod(class_symbol_inst, "bool IsActive()", asMETHOD(NGUISymbolInstance,IsActive), asCALL_THISCALL);
Machine()->RegisterObjectMethod(class_symbol_inst, "void Activate(bool Active)", asMETHOD(NGUISymbolInstance,Activate), asCALL_THISCALL);
Machine()->RegisterObjectMethod(class_symbol_inst, "void SetTransformPos(Vector&in pos)", asMETHOD(NGUISymbolInstance,SetTransformPos), asCALL_THISCALL);
Machine()->RegisterObjectMethod(class_symbol_inst, "void GetTransformPos(Vector&out pos)", asMETHOD(NGUISymbolInstance,GetTransformPos), asCALL_THISCALL);
 
For our scene we are binding about 50 such types because we need register for each symbol entity his own class. And if we look at data that we are bind - this is static data because we are pairing declaration with offset. So this data looks like may be saved and loaded in manner like we are loading and saving bytecode (somehow related with ConfigGroup, before we are start binding we call BeginConfigGroup and call EndConfigGroup after finishing binding)
 
On PC binging time are various. On same PCs with core-i5 binding takes less 1 second on same binding times take about 35 seconds. On android devices and on iphones binding times take about 3-4 seconds.

So if it is was possible to not to call each times big amount of bindings and just call one function to load bindings from one file this may lead to huge speed boost.

Share this post


Link to post
Share on other sites
WitchLord    4677

OK, so the bottleneck you're facing is with the various Register methods. I'll see what I can do to optimize them so the registration is performed faster.

 

I don't think it is possible to serialize this, as there is no guarantee that the function addresses will be the same for each execution.

 

However, I don't see why you need to register this for every scene. Can't you just register the interface once at startup and reuse the same for every scene? What is it that differs from one scene to another?

Share this post


Link to post
Share on other sites
_Engine_    310

We are reproducing scene object binding in adobe flash manner i.e. scene objects may have child's and child have child's etc. and this relation we are binding into script. For example if scene object MainWindow have child Panel and Panel have child Button we can access to Button as follow:

 

ButtonType@ btn_ref = MainWindow.Panel.Button;

 

So for each scene object with child's we are bind his own type into script with properties that's allow access to his child's.

 

May be there are another way to do this but now such manner of binding leads to slow down of scene start up.

Share this post


Link to post
Share on other sites
AgentC    2352

Honestly this looks like misuse of the AngelScript interface registration. I'd recommend to register each scene object class once at startup, and provide accessor methods for each kind of child the scene objects can possibly have, like get_Panel, get_Button etc. If the corresponding child element doesn't exist, the accessor can return null.

Share this post


Link to post
Share on other sites
_Engine_    310

If i register something like GetChildButton("child_name") and so on for each type of object of course i do not need so many types. But this is ugly. I will stick witch start up problem rather then do such uncomfortable accessor because if i want to get access to child of the child i must remember not only name but also a type for each member and code will look like

 

ButtonType@ btn_ref = MainWindow.GetChildLabel("Panel").GetChildButton("Button");

 

This is not suitable.

Share this post


Link to post
Share on other sites
WitchLord    4677

I understand now what you're doing. It's a bit unusual, but it's not wrong. You'll always have an overhead with registering the interface dynamically like this, but I'll do what I can to optimize the code so the overhead is as small as possible.

Share this post


Link to post
Share on other sites
_Engine_    310

maybe it is possible to add of registering accessor with fixed return type (not for simple types) but with dynamic name?

 

For example i call something like this

 

void NGUIWidgetGetProp(asIScriptGeneric* gen) 
{
NGUIWidget* widget = (NGUIWidget*)gen->GetObject();
 
const char* str = &gen->GetFunction()->GetName()[4];
 
void* ptr = null;
 
for (int i=0;i<symbol->childs.size();i++)
{
SceneEntity* entity = symbol->childs[i];
 
if (String::IsEqual(str, entity->GetName()))
{
ptr = entity;
break;
}
}
 
gen->SetReturnAddress(ptr);
}
 
....
core->Script()->Machine()->RegisterObjectMethod("NGUIWidget", "NGUIWidgetButton@ get_xxx", asFUNCTION(NGUIWidgetGetProp), asCALL_GENERIC);
core->Script()->Machine()->RegisterObjectMethod("NGUIWidget", "NGUIWidgetLabel@ get_xxx", asFUNCTION(NGUIWidgetGetProp), asCALL_GENERIC);
core->Script()->Machine()->RegisterObjectMethod("NGUIWidget", "NGUIWidgetScroller@ get_xxx", asFUNCTION(NGUIWidgetGetProp), asCALL_GENERIC);
core->Script()->Machine()->RegisterObjectMethod("NGUIWidget", "NGUIWidgetPager@ get_xxx", asFUNCTION(NGUIWidgetGetProp), asCALL_GENERIC);
...
 
and AngelScript knows if somewhere in script someone accessesd to property of type NGUIWidgetButton than AngelScript not search accessor width such type and name but search accessor with only by return type.

This mechanism would save me from unnecessary type binding and also introduce mechanism to construct class types in runtime.

Share this post


Link to post
Share on other sites
WitchLord    4677
Would a syntax like the following be acceptable in your script?
 
ButtonType@ btn_ref = MainWindow.Get("Panel").Get("Button");
 
// or even like this
ButtonType@ btn_ref = MainWindow.Get("Panel.Button");
?
?
You could quite easily accomplish this by implementing a special object that can represent any of the possible NGUI types you wish to treat, i.e. Button, Label, Scroller, and Pager.

This special object would be created and registered similarly to the CScriptHandle generic handle add-on. It would then additional implement asBEHAVE_IMPLICIT_REF_CAST to each of the types.

Share this post


Link to post
Share on other sites
_Engine_    310

This syntax is not acceptable.

 

First reason - we use flash binding model and we can't do worse because we planned to release public version of IDE.

Second - currently if we accessed to non exist widget in script then we get compile error.

Third - we planned to add auto complete feature in our script editor. With suggested syntax auto complete wouldn't work correctly.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this