> Dalai Felinto dfelinto at gmail.com > Thu May 26 16:22:39 CEST 2011 > > Hi Sjoerd, > > two quick questions:
> 1) any plans to license it in a non-viral license (e.g. BSD)? > 2) how well does it do in terms of performance? > 3) does it work for programmers as well? That's three questions :-) And very good questions, too. I am afraid that the answers aren't so quick... > 1) any plans to license it in a non-viral license (e.g. BSD)? In principle, yes. BSD is too promiscuous for my taste, but something like the LGPL would be an option. However, there are two big complications. The first is that any software that is designed to run on top of the BGE must be GPL because the BGE is GPL. I will work around this by making multiple backends, a GPL backend for the BGE and non-BGE backends for Panda3D, Python-Ogre, ... The second concern is that the hive system seriously blurs the distinction between code and data. The (L)GPL is not very well suited to deal with data. I have some ideas about a custom license, but some discussion would be in order. > 2) how well does it do in terms of performance? If I remember correctly one > of the good points of Benoit's proposal was the overall structure of C++ > code wrapped around Python but without necessarily running much Python > code(at least to reduce the overhead of dealing with python types for any > manipulation). Start-up time can be as much as ten seconds, because all nodes are connected before the hive is fired up. I have some ideas how to slash it, but a few seconds will always be there. As for run-time performance: I haven't tested it thoroughly yet, but I expect no problems, because the nodes call each other directly (no coordination engine). I don't expect much difference with a vanilla Python port of your game logic. Some overhead is added by the exception handling wrappers, but not very much. In any case, for both start-up and runtime, a JIT such as psyco or pypy should double or triple the performance. If pure Python isn't quick enough, I have some plans to interface with nodes implemented in C++, using boost and ctypes. Finally, compiling the whole hive in Cython should also be possible: the static typing of the connections should be very beneficial. > 3) does it work for programmers as well? > This layer of abstraction is also what permit programmers to access through > a programming API (i.e. Python, but it would be lovely to see Lua supported > as well) the same functionality that is available graphically . Yes! I also don't like toy systems that give you some nodes and that's it. Creating your own nodes and interfacing with existing Python code is essential. In addition, you can also create entire hives using the Python class statement, instead of visually. What would you like to have for Lua support? Modifying the node's internal state with a couple of Lua statements should be easy enough with a good Python-to-Lua bridge. I can add that to the system if you want. Making calls into a Lua engine that has direct bindings to the BGE (i.e. bypassing the hive system) would be much much harder. > > Thanks for sharing your project, it seems quite interesting (I need to look > at it properly later though ;). Thanks! :) If you have any questions, don't hesitate to ask! cheers Sjoerd > Dalai > -- > www.dalaifelinto.com > @dfelinto _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers