[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: READ THIS; Debian XFree86 4.0.1 mini-FAQ



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
joshagam@cs.nmsu.edu           \ / No HTML/RTF in email
www.cs.nmsu.edu/~joshagam       X  No Word docs in email
                               / \ Respect for open standards



Reply to: