On Fri, 3 Sep 1999 [EMAIL PROTECTED] wrote:
> | ...It's not
> | guaranteed to be true (Think multitexture for example - all N
> | textures have to be resident at the same time - but the proxy
> | command didn't know that the other 4 textures you ar
Wolfram Gloger wrote:
>
> Hi,
>
> I'm strongly suspecting a bug in Mesa-3.1beta2 where either the
> modelview matrix or compiled display list information becomes corrupt
> when multiple GLX contexts are switched between (I'm using the
> standard X11 driver). Both Mesa-3.0 and GLX from Irix6.2 d
> Have you tried using the latest CVS sources? I recall fixing a bug
> related to multiple contexts since the beta 2 release.
I'm about to. CVS access and ftp access to mesa3d.org and its only
mirror was _very_ slow for me over here, which is the reason I haven't
tried it immediately. Also, `m
> Have you tried using the latest CVS sources? I recall fixing a bug
> related to multiple contexts since the beta 2 release.
I'm pleased to report that the problem indeed seems to be completely
fixed in MesaCVS-1999-09-05, both in my modified isosurf sample and in
my large application.
I compi
A Mesa user reported a problem with glClientActiveTexture and
multiple texture coord arrays.
There was still a remnant of the old GL_SGIS_multitexture code
which was fouling things up. Basically, I removed TexCoordUnit
from the GLcontext struct. All occurances were replaced by
ctx->Array.Active
Wolfram Gloger wrote:
>
> > Have you tried using the latest CVS sources? I recall fixing a bug
> > related to multiple contexts since the beta 2 release.
>
> I'm pleased to report that the problem indeed seems to be completely
> fixed in MesaCVS-1999-09-05, both in my modified isosurf sample an
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.
Fellow developers, any concerns?
O
My program is failing in glDrawElements,
I have found out that:
It appears that clipTEX0_RGBA0 is called with
VB->TexCoordPtr[0]->data pointing to the
texture coordinate data I originally gave
as a parameter to glTexCoordPointer.
This means bad things because the clippings
certainly don't fit in
Test to see if I am back on. Please ignore!
+---+
| SciTech Software - Building Truly Plug'n'Play Software! |
+---+
| Kendall Bennett | Email: [EMAIL PROTECTED]
> (=bad stride + not writeable, which are both true...)
>
> Of course the problem does not show up at the first
> call to draw elements, and the program where it happens
> has > 6 lines of code...
Silly bug - I've committed a fix, thanks for the report.
Keith
___
Is there still meant to be one? The Win32 makefiles seem to live here, but
as this directory isn't in CVS anymore it seems kinda hard to build Mesa for
Win32. Or am I just missing something? :-)
This would greatly assist in me getting the new tessellation code in - I no
longer have a home machi
"Hughes, Gareth" wrote:
>
> Win32 support is moving away from the IDE and to the command line, so win32/
> looks more like the right one (according to the README.WIN32). However, we
> need NMAKE.MAK and NMAKE.MIF to build Mesa...
>
> Ted, any help here? I've taken my 3.0 Win32/ dir and hacke
I am attaching to this mail the patch between the current
CVS version of src/Makefile.fx and my current version.
Changes:
changed the FX_V2 to NOT be defined by default,
also made it separately commented option
added vertices.obj
Brian, could you apply this to the CVS
"Hughes, Gareth" wrote:
>
> Is there still meant to be one? The Win32 makefiles seem to live here, but
> as this directory isn't in CVS anymore it seems kinda hard to build Mesa
> for
> Win32. Or am I just missing something? :-)
>
> This would greatly assist in me getting the new tessellation
On 07-Sep-99 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.310
>
> Mesa 3.0 had both Win32/ and win32/ directories:
>
> % ls Win32
> 3dfx/ MesaDemos-samples.dsw MesaGLUT32.dsp demos/
> GLUT-SGIGL.dsp MesaDemos-samples.opt MesaLib.dsw
> fxMesaGL32.dsp
> MesaDemos-3dfx.dsw MesaGL.dsp MesaLib.ncb res/
> Mesa
> 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.
>
> Fellow developers, an
17 matches
Mail list logo
