On Sun, Sep 24, 2000 at 03:40:03AM -0500, Branden Robinson wrote:
> * The Mesa problem (specifically, the lack of libGLU.so) really has to be
IMNSHOIANALIIRC, every implementation of libGLU I've ever seen has just
been a simple, software-only, non-hardware-pipelinable algorithmic wrapper
around OpenGL calls. I see no reason that libGLU *as it stands now* needs
to be bundled with any specific OpenGL implementation or driver. Although
SGI says otherwise, libGLU really is just a separate thingy which a lot of
OpenGL applications happen to use. (Myself, I only use one libGLU call in
my entire 3D engine, and even that could be easily replaced with a raw
OpenGL call if I weren't so lazy.) Of course, some people use the
tesselator and the like, but those still aren't really reliant on any
specific impementation of libGL, they just require that there be a libGL to
link against.
Basically, I think there should just be one libGLU which is packaged on its
own (for now), and any program which uses GLU should just have it as a
requirement. If it ever changes and some video card implements part of GLU
in hardware (which is incredibly unlikely), then it could be sorted out
later. As it stands, though, I don't think that GLU even cares about the
current OpenGL context, since it just makes raw OpenGL calls anyway.
Of course, it could be that I'm totally off-base, and the only functions
I've been looking at in the GLU source happen to not need low-level OpenGL
access. However, some parts of GLU (such as the tesselator) don't even
seem to rely on OpenGL at all...
--
Joshua Shagam /"\ ASCII Ribbon Campaign
[EMAIL PROTECTED] \ / No HTML/RTF in email
www.cs.nmsu.edu/~joshagam X No Word docs in email
/ \ Respect for open standards
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]