There should probably be a set of standard functions that synthesize lines
and points with quads, similar to the automatic quad-to-two-triangles
routines.
The matrox glx driver currently handles colored, depth buffered, and
blended lines, but can't handle wide lines or textured lines directly.
On 07-Sep-99 Brian Paul wrote:
> I propose this lib name for the 3.1 release: libGL.so.1.2.310
> The 1.2 designates an implementation of the 1.2 API specification.
> The 310 designates the Mesa version number (3.1.0). The main idea
> is to allow Linux OpenGL apps to relink with other OpenGL
> i
Here is a small patch for the "isosurf" demo.
If your renderer doesn't support CVA compactified arrays were
not generated but they are used also in the simple gl_vertex(GL_TRIANGLE)
case!
Andree
--- /usr/src/mesa-glx/demos/isosurf.c Sat Sep 4 23:27:47 1999
+++ ./isosurf.c Wed Sep 8 14:17:3
On Tue, 7 Sep 1999, Brian Paul wrote:
> Here's another issue. There's an effort underway to standardize
> the OpenGL environment on Linux. One aspect of that is version
> numbering for the libGL.so file (used to be libMesaGL.so).
>
> I propose this lib name for the 3.1 release: libGL.so.1.2.3
On Tue, 7 Sep 1999, Brian Paul wrote:
> I'd like to make a 3.1 beta 3 release by the end of next week.
> Fellow developers, any concerns?
Is anyone going to put in the glGetFuncAddressEXT stuff before
then so we are essentially compliant with the new Linux OpenGL
Base spec?
Steve Baker
On Wed, 8 Sep 1999, Joe Waters wrote:
> On the other hand, I think nvidia's reference implementation for linux *did*
> include its own glu library -- are these the same? Should people continue to
> look to Mesa for the de facto standard glu implementation?
GLU is supposed to be a pure layer on
Stephen J Baker wrote:
>
> On Tue, 7 Sep 1999, Brian Paul wrote:
>
> > I'd like to make a 3.1 beta 3 release by the end of next week.
>
> > Fellow developers, any concerns?
>
> Is anyone going to put in the glGetFuncAddressEXT stuff before
> then so we are essentially compliant with the new Li
There shouldn't be "two" win32 directories - remember that Windblows doesn't
differentiate files/dirs base case of lettering, so all of the fines in both
"Win32/" and "win32/" should be in one hierarchy. The creation of these two
separate directories was probably a typing mistake (likely on my pa
Joe Waters wrote:
|
| 2) What's the best way to handle multiple drivers for different chipsets? It
| almost seems like it would make sense to have each of the Mesa versions be
| named something to do with it's chipset -- ie libGx00GL.so.1.0,
| libVoodooGL.so.1.0, libRivaGL.so.1.0, etc, and then
Brian Paul wrote:
>
> I'd like to make a 3.1 beta 3 release by the end of next week.
> There have been quite a few bug fixes since beta 2 but I'm not
> quite confident enough that a final release is appropriate yet.
> I'd like to do more conformance testing and get more end user
> feedback.
> 2) What's the best way to handle multiple drivers for different chipsets?
Well, the best way that I have found to handle it is to use GGIMesa,
which lets you keep the exact same libGL.so core and dynamically load
driver modules on a per-hardware or per-rendering-system basis.
Jon
_
On Wed, 8 Sep 1999, Jon Taylor wrote:
> > Here's another issue. There's an effort underway to standardize
> > the OpenGL environment on Linux.
>
> ...Which explicitly states that this "standardization effort" is
> predicated on the existence and use of X/GLX, and hence is not relevant
>
Stephen J Baker wrote:
>
> On Wed, 8 Sep 1999, Jon Taylor wrote:
>
> > > Here's another issue. There's an effort underway to standardize
> > > the OpenGL environment on Linux.
> >
> > ...Which explicitly states that this "standardization effort" is
> > predicated on the existence and use
John Carmack wrote:
>
> There should probably be a set of standard functions that synthesize lines
> and points with quads, similar to the automatic quad-to-two-triangles
> routines.
>
> The matrox glx driver currently handles colored, depth buffered, and
> blended lines, but can't handle wide l
>This is done inside glide, mesa doesn't see it. I was wondering about
this for
>the mga driver - do you have the magic incantations to build the displaced
>vertices for the two triangles? I don't see any way to avoid taking
1/sqrt(area)
>to get the increments. It's the square root I'd like to
> I can update the DSP files, but that would move them over to
> DevStudio 6 as I no longer have DevStudio 5, and I don't know
> how that would affect the user base at all (they DSP/DSW files
> are NOT compatible across versions, although 6 will load -and
> convert- 5's). Opinions?
I'm using 6
Test to see if I am back on. Please ignore...
+---+
| SciTech Software - Building Truly Plug'n'Play Software! |
+---+
| Kendall Bennett | Email: [EMAIL PROTECTED]
17 matches
Mail list logo
