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?

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.

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

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?

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.

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.

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.

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.

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

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.