On Sun, 23 Jan 2000, Jon M. Taylor wrote:

> On Sun, 23 Jan 2000, Marco Confalonieri wrote:
> > I read the Jon's letter about LibGGI3D, downloaded the 2000-01-21
> > snapshot and tried to compile the LibGGI3d stuff.
> > I ran autogen.sh and tried to 'make' the thing, but gcc complains about
> > a missing file called matrix.h . 
>       This is from Meschach, the linear algebra library I use for 3D
> transforms and such.  The configure.in does not properly autodetect a
> Meschach install, nor a glib install which is also required.
> > Could I rewrite it? (Well... I am not a
> > marvelous developer, but if this file is only for basic matrix
> > transformation I think I can write it).
>       Sure, but Meschach is already available and it is quite good.
> Unfortunately the only distribution which packages it is Debian |-/.
> > Finally, I wish to use the full power of my old Mystique card under
> > Linux, but the GLX is very slow, so I would like to write a LibGGI3D
> > module for HW acceleration. I got the specs from Matrox, but I have two
> > problems:
> > 1) I'm trying to understand what this PDF is talking about!!! What
> > damned sort of cryptographic tech speech is that?! :-(
>       If you are referring to the old LibGGI3D RFC, I agree that it was
> not well explained.  I am rewriting it now to be more understandable.
> > 2) Is there a sort of skeleton module which I can use as a basis?
>       Not yet.  The best existing examples are the 'zbuffer' and 'debug'
> modules.  I'll try to get a real skel.c written soon.

But IHMO the way of implementation the module concept is bad. I think the
modules should be self-running programms and they use shared memory for
communication. This will have this advantages:

- better scaling on SMP-machines
- when a module crashs, the application will continue - without the
  functionality of the crashed module
- much less name space problems
- Debugging can be done much better
- LibGGI3D can be much easier ported to other platforms
- modules can be developed and tested indepently from the developing of
  LibGGI3D itself.

Christoph Egger

Reply via email to