Hi Sergey, I believe most devs are busy with other businesses. On my end sorry for the lack of feedback.
Regardless of multi-threading during execution it would be really interesting to find a solution for some of the current bottlenecks. Namely file/scene conversion (i.e. game actuator, scene actuator, libload even). Would you be interested in pursuing this further? If so we can have a ge-branch for that once there is some code as a start point. To start with a strong code design (as it seems was the direction you were going) may be the way as well. Thanks, Dalai Note: I personally have no knowledge in multi-threading. But this seems an important discussion I wouldn't like to see fading away. 2011/9/5 Sergey Kurdakov <sergey.fo...@gmail.com> > Hi All, > > some time ago there was a discussion on approaches to implement multi > threading for Game engine > ( if there are plans to keep BGE developed as it is) > > found nice implementation for the idea, I tried to describe > > > in simplest case ( three times memory overhead plus copy state overhead) > - > > there could be three containers (lists or maps etc ) for simulated > objects. > > > > physics and logic thread updates thirst container, then after update - it > is > > swapped with second container ( though current state is copied if object > > state is changed so that, ex position is continuously updated with > relevant > > current state in physics code), render takes info from third container - > > just before rendering it swaps third and second container ( not sure for > > copy - but some check so that old data from second container does not go > to > > third might be needed ). > > here is implementation: > > > http://code.google.com/p/osgbullet/source/browse/trunk/include/osgbDynamics/TripleBuffer.h > > http://code.google.com/p/osgbullet/source/browse/trunk/src/osgbDynamics/TripleBuffer.cpp > > instead of naive implementation in accordance with my descriptiion it > is possible to employ tested approach to implement multi threading for > BGE > ( and if also to use OpenMP for loops ) > > then BGE engine might become quite multiprocessor scalable without > much coding pain. > > ( the other idea was to use approach from > http://software.intel.com/en-us/articles/smoke-game-technology-demo/ > - but it is more difficult to replicate) > > Regards > Sergey > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers