[OT] This feels wrong (pthreads question)

Steve smorrey at gmail.com
Mon Jan 29 12:07:31 MST 2007

The SceneGraph object turned out to be the easiest thing to code :D
Essentially, it's a std::map objects called xline (originally there
were yline and zline as well but as you'll see it turned out to not be

When we want to find out what objects are within x,y,z of another
object first we search the xline map for all objects within n meters
of our object.

We then check the entitys y and z against each other for range (x,y,z
coords are stored on the entity and the graph is indexed by x).

If the objects turn out to be in range of one another, we create a new
mini scenegraph and add all the objects that pass these 3 tests and
return the new mini graph.

The client handler can then do simple comparisons against it's old
copy of the graph, and the changes are propegated.

I love single file solutions.
On 1/15/07, Levi Pearson <levi at cold.org> wrote:
> Steve <smorrey at gmail.com> writes:
> > In this model the whole system becomes event driven.
> > When my scenegraph recieves an event, it searches itself once for all
> > objects in scope of the event.  It then notifies all the Sender
> > objects (we'll call it a client handler for clairty), in scope of the
> > event, which then take the task of passing it on to the client.
> Now this sounds like a reasonable design, though as you say, it will
> require some thinking about your data structures (especially the scene
> graph) to do efficiently.  I actually did some thinking about this
> exact same design problem, and stopped somewhere around this point, as
> I had stopped caring enough about MUDs to progress any further.
> Anyway, I was thinking along the lines of storing the objects in a
> kind of fractal tree structure in order to simplify finding the
> objects within a range, but I didn't get any details worked out.  I'm
> sure there's plenty of literature in the 3-d game programming field
> regarding this sort of thing.
> It starts getting complicated when you consider walls, trees,
> boulders, doors, and other such things.  Depending on how realistic
> you want to get, you'd probably have to roughly 3-d model everything
> and do some sort of ray-casting to see if an object that is in range
> should actually be viewable/hearable/etc.
> I concluded that it wasn't worth the trouble that it adds to world
> building and server coding, and that the 'room' paradigm was good
> enough.  I think good writing is more important to MUDs anyway, but
> what you're trying to do is definitely cool and is a good programming
> exercise anyway, so don't let me discourage you. :)
> > I believe that this would be much more efficient than the current
> > model, because it eliminates the overhead of a context switch, as well
> > as the overhead of having each client handler, query the scenegraph on
> > it's own whether or not an event has taken place.
> Stick with this design and make your threading model such that there
> are only a few threads, and I think you'll be in good shape.  Hundreds
> of thousands of kernel threads is just a bad idea, though.  It will
> simply not scale well.  I wouldn't go past the hundreds of threads
> level at all, and I would definitely try to keep the number of threads
> in a small multiple of the number of CPUs, preferably 1 per CPU.
>                 --Levi
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */

More information about the PLUG mailing list