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
> 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
