On Sun, 21 Jan 2001, Tijs van Bakel wrote:
> [EMAIL PROTECTED] (Christoph Egger) writes:
>
> > IIRC libggi2d is dead. libxmi is the new one...
>
> ouch. it's hard for newbies to find out what they can and what they
> cannot use. at least i could understand what '2d' and '3d' meant.
> the cryptic 3 letter library names make no sense to me.
And you use Linux? |->. Man, you must be hurting....
> i couldn't
> find a document describing what each library was supposed to do in the
> FAQ.
>
> could somebody please put this in a FAQ or in a top README? or
> perhaps point me to a place where i could've found it :)
>
>
> ;-- a description of the GGI project libraries --
>
> libedemo - extension demo
> A simple example for coding extensions
>
> libgffd - no idea
General File Format Descriptions? Something like that....
> libggi - general graphics interface
> The core library, providing access to many display targets.
> Relies on libgii.
>
> libggi2d - a 2d operations library
> Dead. Use libxmi instead.
Yeah. If/when we move our CVS to SourceForge, the libggi2d
directory should be dropped. Actually, maybe we should use such a CVS
move to reorganize our whole CVS tree, which is now over three years old
and filled with cruft and deleted directories. We could split GGI/GII,
KGIcon, and each extension library off into their own separate SF
projects, to reduce the size of snapshots and such. I already did this
for LibGGI3D once upon a time....
> libggi3d - a 3d operations library
LibGGI3D is primarily intended for 3D graphics use, but it is
actually a much more general system than that. At its core, LibGGI3D
implements what is now commonly referred to as a 'rendering fabric'. It
provides a simple, lightweight component model which can be used to
implement state persistence and rendering chains on top of GGI visuals.
Think of LibGGI3D as a way to take GGI target modules and use them _above_
the function API layer, as well as below it as we do nowadays. Check out
libggi3d/doc/libggi3d.rfc for a more detailed explanation.
> libggigl
This, IIRC (Marcus?), is basically GGIMesa without "real" targets.
It is designed to wrap a pre-existing OpenGL/Mesa library implementation
in a GGI-extension layer. All the GGIGL targets would consist of
bridge/glue code, not actual pixel-drawing code. In GGIMesa we will
probably end up re-implementing the XMesa rendering code as a set of
X/Xlib/DGA targets, much as is done now in the LibXMI X-target code. But
in LibGGIGL, we would simply write an XMesa wrapper-target.
This approach ties us to the underlying implementation of the GL
libraries we encapsulate, and thus will probably be less modular and
flexible than writing a "real" GGIMesa target. However, it is also
__MUCH__ easier than writing a "real" target for an API as complex as
OpenGL. And since there already exist GL implementations for just about
every platform GGI is or will be ported to, LibGGIGL offers us a quick and
easy way to bring full OpenGL into the GGI extension framework.
I once suggested that the Berlin folks base their GL-in-GGI
framework on GGIGL instead of GGIMesa, since it will take quite some time
to implement "real" accelerated rendering for any type of complex target
in GGIMesa. They do want to run in a console in Linux, which IIRC rules
out anything but FXMesa (Glide) as a target, but it would work.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
