Thanks for all your comments, I made some test for compare single vs. multiple.
This test add some hundreds of fishes to Avatar's scene, using two techniques discussed here. add_dyn.js ( http://pastebin.com/knpit5H3 ), Fish.js ( http://pastebin.com/8AnFdB9p ), and GlobalFish.js ( http://pastebin.com/RhNB9jLe ) You can change technique in line 3 of add_dyn.js. Change How many fiches add by line 2 (n*n fish will be added) . Using scene.txml from Avatar examlple, some fiche will fall (need to make bigger floor). Added second avatar for demo purposes. Start Tundra in command line with param --run add_dyn.js. Or use console... Some observation: Adding 10x10 fish is ok by two method. But adding 20x20 fish with Fish.js (many instance of javascript) will fail with error "Could not allocate register file N" where N is different 2, 33. I would like to know what this mean? Using GlobalFish.js - we add single js, but instantiate many instance by EC_SCRIPT, as Jonne explained. This method permit add as many as 50x50 fish without problems... I have also question about how to know when scene is ready for manipulation. I used some sort of tentative every 1 sec... It is correct or i can use more clean approach? Thanks. Vik Vik On Mar 30, 2:18 am, Jonne Nauha <[email protected]> wrote: > Yes you will want live realoding. You will go crazy if you need to restart > client/server all the time when you save file. Script live reloading is the > best feature Tundra has for devs :) > > This other approach that simpleavatar.js uses gives you the same kind of " > this.me" == entity the script is attached to feeling (you need to assign > this.me as youll see in simpleavatar.js ctor). Without running huge number > of script engines. So really, its how you like to program. I like to make > more these separate apps that run in their own entities and keep their data > component (EC_DynamicComponent) in the script entity. Then internal logic > modifies/creates/removes entities/component how it needs. So I'm used to > going "me.something" only for my data component, and for that I always make > getter inside the app this.DataComponent(); :P > > Another neat thing if you want "real object" in your scripts is class.js > that ships with Tundra. I basically use this in all my scripts. I haven't > used it in the example scenes I've made as they should be kept simple. But > the browser ui js I made shows this quite well. This also has some advanced > UI stuff if you want to learn that :) > > Defining > classhttps://github.com/realXtend/naali/blob/tundra2/bin/jsmodules/browser.... > You define init: function() that gets called when the class is new'ed, its > little bit like python __init__. Main intance owns other > objectshttps://github.com/realXtend/naali/blob/tundra2/bin/jsmodules/browser.... > Booting up the > apphttps://github.com/realXtend/naali/blob/tundra2/bin/jsmodules/browser... > > Best regards, > Jonne Nauha > Adminotech developer > > > > > > > > On Fri, Mar 30, 2012 at 9:02 AM, Toni Alatalo <[email protected]> wrote: > > On Thu, 2012-03-29 at 11:57 -0700, Vik wrote: > > > I will go with single EC_Script ( normal programming :) ) > > > Even if ScriptEngine is performant, load hundreds of EC_Script may be > > > painful ( as Jukka said in issue 439 > >https://github.com/realXtend/naali/issues/439 > > > No the point was that using the Script *Application* mechanism with > > multiple EC_Scripts is performant -- then you again only get a single > > engine. The same thing that Jonne mentioned and indeed the reference > > Avatar app uses. > > > But yep I think a single EC_Script can still be nice. > > > > And I don't think in this case live reloading will be useful... > > > I think it's always useful when developing :) > > > And you do get that with a single Script component too, it just resets > > the whole app then. > > > > Vik. > > > ~Toni > > > > On Mar 29, 1:49 pm, Toni Alatalo <[email protected]> wrote: > > > > On Thu, 2012-03-29 at 09:41 -0700, Vik wrote: > > > > > 001,...door.099), i can attach to each object javascript for actions > > > > > (say "OpenDoor"). Or I can attach one script to scene and in this > > > > > script distinguish door by name at run time. > > > > > Which solution is better. I mean 'better" from architectural point > > > > > of view of Tundra in terms of performance and memory consumption. > > > > > I tend to make with one master JS and one EC_Script for the whole > > > > application. I like normal programming, and also that used to be way to > > > > make it efficiently (minimal mem use as there's only one ScriptEngine). > > > > Have that in an invisible entity called MyGame or so. > > > > > The system is however made so that using a Script component in each > > > > scripted entity can be nice. For example for a non-programming level > > > > designer to put a script to an object. And nowadays there's the > > > > ScriptApplication system, which basically allows you to make several > > > > script components to be executed with a single engine, so you get the > > > > same optimally minimal memory usage. I think it's well suited for > > > > instanciating several entities that use the same script, basically > > > > declaring a class in JS and then marking entities in the scene as > > > > instances of that. Similar to the RexScript IronPython system in old > > > > realXtend with Linden based viewer and Opensim which is there in > > ModRex. > > > > > One cool upside of using several EC_Scripts can perhaps be that the > > live > > > > reloading may work less instrusively as only one script engine is > > > > reseted and not the whole app. For example if you make AI for a > > predator > > > > and it's prey, can modify either code, just save the file so it gets > > > > reloaded in Tundra, and at least the other animal keeps working cleanly > > > > from the old state as it was untouched. It's possible to make a main > > app > > > > support restart too, quite easy perhaps even if keep the data in EC > > > > attributes (script's can create their own so-called DynamicComponents > > > > for custom data). The attribute values are ofc untouched when the > > script > > > > engine is reseted, so that state can always stay (position of the > > > > objects etc., but if you put e.g. some AI mode or tracking target in > > own > > > > DynamicComponent, that stays too.) > > > > > > Vik. > > > > > ~Toni > > > -- > >http://groups.google.com/group/realxtend > >http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
