mesa3d-dev

[Mesa3d-dev] New Mesa 3.2 Bugs - One serious (I think)

[Linux D. A. <li...@iv...>]

   While I have been working with OpenGL since its inception I am
relatively new to Mesa and the Source Forge development system here
so bear with me.

   An initial question: If I find what I think is bug do I directly
try to add in the source forge bug tracker or do we discuss it first here
to make sure a bug has really been found?

   I recently compiled a fairly large visualization system under Linux-i386 and
Mesa OpenGL. Overall I am very impressed - kudos to the developers. However I
did discover several bugs, one which I think is quite serious. These tests
were done with a dataset of approx. 50 million polygons. Here are the
problems that I found

----

#1 Incorrect Rendering of Subpixel quadstrips - Serious problem ?

Polygons less than one pixel in size don't display at all. Take a very complex
polygonal surface then slowly pull back. Given the huge number of
polygons eventually the size of a polygon will be mathematically smaller
than one pixel. It appears at this stage that no on screen pixel
representation is drawn. Thus as you pull back the suface discenigrates
and vanishes even though the overall surface might cover thousands of
pixels.

Note this problem does not happen on SGI, Sun, or windows OpenGL 
implementations so I guess there is some aspect of the OpenGL standard
that Mesa does not correctly implement. In this implementation the surface
is a digital terrain model rendered as a series a quad strips.

----

#2 Front & Back buffer drawing+blending = crash 

With a double buffered visual if I draw polygons (quad strips in this
case) normally or use glDrawBuffer( GL_FRONT ) and draw the polygons no problem.
However, if I use glDrawBuffer(GL_FRONT_AND_BACK) the application crashes.
Here's some output from gdb.

Reading symbols from /lib/ld-linux.so.2...done.
#0  0x400552ac in blend_transparency (ctx=Cannot access memory at address 0x3d
) at blend.c:286
286	blend.c: No such file or directory.
(gdb) where
#0  0x400552ac in blend_transparency (ctx=Cannot access memory at address 0x3d
) at blend.c:286
#1  0x842ed10 in ?? ()
Cannot access memory at address 0x1


Note that the quad strips are drawn with GL_BLEND enabled although I am 
not sure if that has anything to do with the problem.

----

#3 Rendering Performance Issue - Not a bug but an observation.

Again using a double buffered (+Zbuffer) - If I draw the same quad strip
scene described in bug #1 normaly in the background and swap it to the
foregroup this the usual SwapBuffer command I get excellent performance.
However if I set glDrawBuffer(GL_FRONT) and render the same scene you get
absolutely horrible performance in comparison. I would say 10-12 times
slower. I would expect the two situations to have similar performance with only 
glDrawBuffer(GL_FONT_AND_BACK) to suffering a performance penalty. Anyone
with more Mesa knowledge care to comment - Is this a problem or just a
optimization waiting for an implementor?

----

This testing was done with a C++ application using Mesa 3.2, Redhat 6.2
with the stock kernel, XFree86 3.3.6, Metrolink Motif, and the SGI Motif
OpenGL drawing widget from Mesa (GLwMDrawingA.h).

I plan to look into #2 myself as a first experiment working with the Mesa
code but for #1 and #3 it would be nice to see some dicussion from the
more experienced Mesa developers. Sould I add these bugs to source forge?

Talk to you later,
  Mark

-------------------------------------
Mark Paton
Interactive Visualization Systems Inc. 
http://www.ivs.unb.ca

Re: [Mesa3d-dev] -pedantic

[Brian P. <br...@pr...>]

"Sebastián González M." wrote:
> 
> Hi there!
> Please consider this 7-line program, 'test.cpp':
> 
> #include <cstdlib>
> #include <GL/glut.h>
> 
> int main(void)
> {
>     return 0;
> }
> 
> I'm working with Mesa on Linux, when compiling test.cpp with -ansi -pedantic
> i get:
> 
> In file included from test.cpp:2:
> /usr/include/GL/glut.h:202: warning: declaration of `exit(int)' throws
> different exceptions
> /usr/include/stdlib.h:520: warning: previous declaration here
> 
> glut.h declares exit(), why?
> I think that exit() dcl isn't needed to GLUT end-users; can you remove it on
> next release?

I've removed it.  It's another side effect of Windows-specific nonsense.

-Brian

[Mesa3d-dev] minor updates to asm code

[Brian P. <br...@pr...>]

I've moved the definition of the LLBL macro into assyntax.h and
removed it from all .S files.  It also now uses the CONCAT macro.
Then I removed all spaces from all invocations of that macro.
I.e. LLBL( foo ) becomes LLBL(foo).

I did this to fix problem encountered when building on FreeBSD 3.4
inside the XFree86 X tree.

There shouldn't be any side effects to these changes but I'd
appreciate people updating their sources and testing the changes.

-Brian

Re: [Mesa3d-dev] Re: [RFC] bump extension proposal..

[Holger W. <hwa...@ya...>]

Hi,

on

http://www.nvidia.com/Marketing/Developer/DevRel.nsf/TechnicalDemosFrame?OpenPage

you find various demos and algorithms for different approaches to bump
mapping without the need of a special extension. However, non of them does
a real per pixel lighting or is able to change light parameters over a
triangle.

- Holger

Re: [Mesa3d-dev] Re: [RFC] bump extension proposal..

[Scott M. <mcm...@ca...>]

I don't know if this is coincidence or not, but Slashdot posted
a pointer to an article at tweak3d.net about the various kinds of
bump mapping.  At one point the article mentions that the G400 can
do Environment Mapped Bump Mapping:

"This feature was first introduced in Matrox's G400 graphic card
 series and the upcoming RadeOn GPU from ATI is expected to
 implement EMBM as well."

Check out: http://www.tweak3d.net/articles/bumpmapping/

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

Re: [Mesa3d-dev] Re: [RFC] bump extension proposal..

[Holger W. <hwa...@ya...>]

On Tue, 13 Jun 2000, Stephen J Baker wrote:

> Whatever you implement needs to be something that at least *some* hardware
> can support - which means that we should be using some of the existing
> extensions rather than inventing new ones.

Does any current card supports a 'real' per pixel lighting ?
I believed phong shading is usually implemented by multitexturing using
the modulating texture as exponential lookup table.


> Also, if you stick with existing extensions, there is a better chance
> that programs not specifically written for Mesa will take advantage
> of this new code.  Note that Mesa is no longer the only game in town
> for Linux users - the nVidia driver already has bump-map extensions - and
> I fully intend my programs to make use of them.

Simple bumpmapping can be implemented on usual consumer cards using
multitexturing without any additional extension. On nVidia's website was a
'GLBump' demo a while ago (don't know, if it's still there ...), which
shows a simple and straightforward implementation of this.

Does anybody knows where to get the spec to nVidias bumpmapping 
extension ? I never heard about it until now.

- Holger

Re: [Mesa3d-dev] Re: [RFC] bump extension proposal..

[Holger W. <hwa...@ya...>]

On Tue, 13 Jun 2000, Brian Paul wrote:

> Holger Waechtler wrote:
> 
> I have some concerns about implementing these extensions:
>   1. Will any of these extensions map onto current hardware?  None that I
>      know of.

Shure, but if next generation cards may be designed for this. Do you know
a graphics chip designer we might ask ?


>   2. There are patent issues associated with them.

Who is owning the patents ?


>   3. They're somewhat complicated and I worry about implementation problems.

Yes, but the design is clean and we have the spec now. As far I have seen,
a new triangle rasterizer would have to be implemented, which interpolates 
normals and light texture parameters.


> I'd like to see an extension spec for NVIDIA's new per-pixel lighting feature.
> That might be more interesting/useful.

That's the other way. Who knows, where to get this ?

- Holger

Re: [Mesa3d-dev] Re: [RFC] bump extension proposal..

[ralf w. <b_...@gm...>]

Stephen J Baker wrote:

> You should be able to find out all about the nVidia extensions (for example)
> at the www.opengl.org site.
> 

nvidia writes extensions specific to their hardware.. so does sgi.
i wanted something simple.
-- 
ralf willenbacher (bj...@oc...)

Re: [Mesa3d-dev] Re: [RFC] bump extension proposal..

[Stephen J B. <sj...@li...>]

On Tue, 13 Jun 2000, Holger Waechtler wrote:

> 
> ralf willenbacher wrote:
> > 
> > attached are my thoughts on a bumpmapping extension for mesa.
> > i would like to hear some opinions :>
> 
> What do you think about implementing GL_EXT_texture_perturb_normal ??
> 
> GL_EXT_light_texture, GL_EXT_coordinate_space and GL_EXT_fragment_lighting
> would have to be written first, but it's the better solution in my mind.
> If you go this way, I would be glad if I could help implementing one or
> two of those extensions.
 
Whatever you implement needs to be something that at least *some* hardware
can support - which means that we should be using some of the existing
extensions rather than inventing new ones.

Also, if you stick with existing extensions, there is a better chance
that programs not specifically written for Mesa will take advantage
of this new code.  Note that Mesa is no longer the only game in town
for Linux users - the nVidia driver already has bump-map extensions - and
I fully intend my programs to make use of them.

You should be able to find out all about the nVidia extensions (for example)
at the www.opengl.org site.

                            --ooOOoo--

Please note the change in my email address (was hti.com - now link.com)

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-dev] Re: [RFC] bump extension proposal..

[Brian P. <br...@pr...>]

Holger Waechtler wrote:
> 
> ralf willenbacher wrote:
> >
> > attached are my thoughts on a bumpmapping extension for mesa.
> > i would like to hear some opinions :>
> 
> What do you think about implementing GL_EXT_texture_perturb_normal ??
> 
> GL_EXT_light_texture, GL_EXT_coordinate_space and GL_EXT_fragment_lighting
> would have to be written first, but it's the better solution in my mind.
> If you go this way, I would be glad if I could help implementing one or
> two of those extensions.

I have some concerns about implementing these extensions:
  1. Will any of these extensions map onto current hardware?  None that I
     know of.
  2. There are patent issues associated with them.
  3. They're somewhat complicated and I worry about implementation problems.
  4. I don't know of any other GL that implements these extensions.

I'd like to see an extension spec for NVIDIA's new per-pixel lighting feature.
That might be more interesting/useful.

-Brian

Re: [Mesa3d-dev] Re: [RFC] bump extension proposal..

[Gareth H. <ga...@pr...>]

Holger Waechtler wrote:
> 
> ralf willenbacher wrote:
> >
> > attached are my thoughts on a bumpmapping extension for mesa.
> > i would like to hear some opinions :>
> 
> What do you think about implementing GL_EXT_texture_perturb_normal ??
> 
> GL_EXT_light_texture, GL_EXT_coordinate_space and GL_EXT_fragment_lighting
> would have to be written first, but it's the better solution in my mind.
> If you go this way, I would be glad if I could help implementing one or
> two of those extensions.

I still haven't heard back from SGI regarding permission to implement
EXT_light_texture or EXT_fragment_lighting, but I haven't chased it up
in a while...

-- Gareth

Re: [Mesa3d-dev] Re: [RFC] bump extension proposal..

[Holger W. <hwa...@ya...>]

ralf willenbacher wrote:
> 
> attached are my thoughts on a bumpmapping extension for mesa.
> i would like to hear some opinions :>

What do you think about implementing GL_EXT_texture_perturb_normal ??

GL_EXT_light_texture, GL_EXT_coordinate_space and GL_EXT_fragment_lighting
would have to be written first, but it's the better solution in my mind.
If you go this way, I would be glad if I could help implementing one or
two of those extensions.

- Holger

Re: [Mesa3d-dev] Compiling Mesa with VectorC

[Eero P. <epa...@ko...>]

Andrew Richards wrote:
> 
> I am the head programmer at CodePlay Limited, a company that is
> developing a C compiler for PCs that is able to  vectorize standard C
> code to take advantage of MMX, 3DNow! and Streaming SIMD Extensions. I
> would like to  update Mesa to help VectorC take full advantage of these
> processor features. This requires adding a few "hints"  and "restrict"s
> in the source code. These can be done with #defines so as not to affect
> other compilers.
> 
> I would like some advice - which parts of Mesa would benefit from MMX,
> 3DNow! and SSE? I have  tried running VTune on Mesa and failed to get it
> to work. How do other Windows developers profile Mesa?
> 

I have used VTune (3.0 if that matters) with my application, which
used Mesa (Glide version). I was able to see the performance 
hotspots in Mesa. The Makefile.fx (int Mesa/src) contains
those options which I needed in order to compile the dll (and the
.pdb and .map) files which were suitable for this use.


Using the 3dfx Voodoo2 the critical components of mesa were
the transformation routines (Which are already available as
X86 assembly), some of the FX setup routines. (I did not use
the "fastpath" because I used fog(?)). In some cases the
texture conversion/downloading might have some performance efects.


		Eero

[Mesa3d-dev] Compiling Mesa with VectorC

[Andrew R. <a.r...@co...>]

I am the head programmer at CodePlay Limited, a company that is
developing a C compiler for PCs that is able to  vectorize standard C
code to take advantage of MMX, 3DNow! and Streaming SIMD Extensions. I
would like to  update Mesa to help VectorC take full advantage of these
processor features. This requires adding a few "hints"  and "restrict"s
in the source code. These can be done with #defines so as not to affect
other compilers.

I would like some advice - which parts of Mesa would benefit from MMX,
3DNow! and SSE? I have  tried running VTune on Mesa and failed to get it
to work. How do other Windows developers profile Mesa?

Andrew Richards
CodePlay Limited - http://www.codeplay.com

[Mesa3d-dev] -pedantic

[<se-...@un...>]

Hi there!
Please consider this 7-line program, 'test.cpp':

#include <cstdlib>
#include <GL/glut.h>

int main(void)
{
    return 0;
}

I'm working with Mesa on Linux, when compiling test.cpp with -ansi -pedantic
i get:

In file included from test.cpp:2:
/usr/include/GL/glut.h:202: warning: declaration of `exit(int)' throws
different exceptions
/usr/include/stdlib.h:520: warning: previous declaration here

glut.h declares exit(), why?
I think that exit() dcl isn't needed to GLUT end-users; can you remove it on
next release?
If it is needed, glut.h should include stdlib.h...

Thanks a lot. Mesa rocks.

Re: [Mesa3d-dev] Re: [RFC] bump extension proposal..

[Brian P. <br...@pr...>]

ralf willenbacher wrote:
> 
> 
> attached are my thoughts on a bumpmapping extension for mesa.
> i would like to hear some opinions :>
> i am thinking about poor loki entertainment when they
> have to port a game that uses the directX bumpmapping function.

I'm not familiar with DirectX's bumpmapping.  Is your extension
a copy of it?

My comments follow.



> i ripped this style from texgen_emboss from nvidia
> 
> Name
>    MESA_perpixel_lighting (or MESA_anisotropic_blending)
> 
> Extension String
>    GL_MESA_perpixel_lighting (or GL_MESA_anisotropic_blending)
> 
> Dependencies
> ARB_multitexture.
> 
> Overview
>     The extension allows lumination per pixel of textures depending on 4 direction vectors.
>     Its done with a texture containing height differences of X and Y (U/V) in texture space.
>     The texture may contain a third component that specifies the reflection of the surface material.
> 
> 
> Issues
> 
>     why depending on arb_multitexture ?
>     most hardware implements anisotropic lighting in the second texture stage and outputs
>     the luminance to the first.

Huh?


>     it cannot be used as the first texture stage because
>     then someone might want to use the second texture stage for something else which would require
>     another pass in the driver (is this really that bad ?). could be used in single texture mode too
>     for flat triangles with carvings on it.

I don't see any dependency on multitexture for this extension.


>     perpixel or anisotropic ?
>     dunno.. anisotropic will make some people to run for dictionaries.

I'm not sure either name is really accurate.


> New Procedures and Functions
> 
>     glLightDirectionMESA(GLfloat left, GLfloat right, GLfloat bottom, GLfloat top)
>     sets the direction the light is shining on the surface.
>     is clamped to -1.0/1.0
>     negative numbers mean darken, positive brighten.
>     defaults to 0.0, 0.0, 0.0, 0.0

You aren't defining a light direction so much as four blending weights.
Perhaps  glBlendWeightsMESA(GLfloat left, GLfloat right, GLfloat bottom, GLfloat top)


> New Tokens
> 
>     GL_DXDYDL (or DUDVL ?)
>     defines a texture format to load an image containing delta X(U), delta Y(V) and
>     material luminance (L).
>     to be used in glTexImage2D
>     DX and DY are signed, L is unsigned.
> 
>     GL_DXDY (or DUDV)
>     the same without luminance.
>     
>     GL_FUNC_PERPIXEL_LIGHTING (or _ANISOTROPIC)
>     to be used in glBlendEquation. could be a problem bacause it clashes with glBlendFunc...

I would think that this feature would be implemented in the texture environment,
not in the fragment blending stage.  I.e. GL_FUNC_PERPIXEL_LIGHTING would really
be a glTexEnv mode.


>     for hardware that does not have native bumpmapping (oops.. um.. perpixel..
>     anisotropic.. emboss.. nvidia magic) support an internal texture format might be
>     specified that contain 4 seperate luminance maps to be applied seperate to the
>     framebuffer/ first stage texture. could be left to the drivers though..
> 
>     the following additions to the opengl specification could be wrong
>     because the 1.2 .pdf looks funny in xpdf. i will stick to name in braces
> 
> Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation)
> 
>     when glTexImage2D is called with either GL_DXDYL or GL_DXDY the incoming pixels will
>     be converted to byte size. when luminance is not given (GL_DXDY) a luminance of
>     255 (full luminance) will be assumed. DX and DY will be clamped to -127/127
>     when a border is given the bordercolor will be taken as DX,DY,L. alpha will be ignored.

It's against the grain of OpenGL to specify the internal storage format for
something like this.  I'd just say that the image is stored internally with
values in [-1, 1] and indeterminate precision.
    
    
> Additions to Chapter 3 of the 1.2 Specification (Rasterization)
> 
>     in single texture mode where the blendequation is GL_FUNC_PERPIXEL the lumination
>     will be applied to
>     the frame buffer like a  GL_LUMINANCE texture.
> 
>     the luminance from the GL_FUNC_PERPIXEL blending equation is calculated like this:
>     incoming texture is of type GL_DXDYL, left, right, top, bottom is set by glLightDirectionMESA
> 
>     for every pixel
> 
>     dX = DX / 127.0
>     dY = DY / 127.0
>     l = L / 255.0
>     
>     luminance = 1.0         ; start with no luminance
>     
>     if(dX >= 0.0) luminance += left*dX
>     else luminance += right*(-dX)
>     if(dy >= 0.0) luminance += top*dY
>     else luminance += bottom*(-dY)
> 
>     luminance *= l;
> 
>     the destination pixel RGBA
>     R*l, G*l, B*l, Alpha is unchanged.
> 
>     in the multitexture case the destination will be the first texture stage.. 

Here's how I would phrase it:

      let dx, dy = the sampled texture value

      luminance = 1.0

      if(dX >= 0.0) luminance += left*dX
      else luminance += right*(-dX)
      if(dy >= 0.0) luminance += top*dY
      else luminance += bottom*(-dY)
  
      luminance *= l;

      let (R, G, B, A) be the texture unit's incoming fragment color.

      The outgoing fragment color (R', G', B', A') is then:

      R' = R * l
      G' = G * l
      B' = B * l
      A' = A


That said, however, I don't see how this extension is really going to work.
I think I can see this working on a planer polygon, with the four blend
weights getting recalculated depending on the surface orientation.  But how
is it supposed to work for a non-planar surface?  The luminance calculation
has to be dependent on the polygon's orientation with respect to the light
position.  Either the DXDV data or the blend weights would have to be modified
per polygon.  Or maybe determine which parts of the texture get mapped to which
triangles and modify the DX DY values accordingly (sounds hard).

Finally, is it your expectation that this feature can be implemented in terms
of current hardware?  Or, is it supposed to be a software solution.  I don't
think either is practical.

-Brian

Re: [Mesa3d-dev] VMS freeware CD

[Brian P. <br...@pr...>]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> I just found this in the VMS newsgroup
> 
>   I am also now soliciting updates and new submissions for the OpenVMS
>   Freeware V5 release.  Submissions for the Freeware can be sent to
>   ope...@co... -- please note this email address is for
>   submissions only and cannot accept requests for the field test kits.
> 
>  --------------------------- pure personal opinion ---------------------------
>    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com
> 
> 
> Shall I point them to the latest release of Mesa to include that on this
> freeware CD which will be distributed for free with VMS7.3 (if it comes out)
> and will be placed on the web. It surebale will make it easier for VMS users
> to get Mesa on their systems.

Fine with me.

-Brian

[Mesa3d-dev] VMS freeware CD

[<jo...@hr...>]

Hi all,

I just found this in the VMS newsgroup

  I am also now soliciting updates and new submissions for the OpenVMS 
  Freeware V5 release.  Submissions for the Freeware can be sent to
  ope...@co... -- please note this email address is for
  submissions only and cannot accept requests for the field test kits.

 --------------------------- pure personal opinion ---------------------------
   Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com
   

Shall I point them to the latest release of Mesa to include that on this
freeware CD which will be distributed for free with VMS7.3 (if it comes out)
and will be placed on the web. It surebale will make it easier for VMS users
to get Mesa on their systems.

               Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

[Mesa3d-dev] Re: [RFC] bump extension proposal..

[ralf w. <b_...@gm...>]

 
attached are my thoughts on a bumpmapping extension for mesa.
i would like to hear some opinions :>
i am thinking about poor loki entertainment when they
have to port a game that uses the directX bumpmapping function.

-- 
ralf willenbacher (bj...@oc...)
oops.. mesa3d is now at sourceforge..

Re: [Mesa3d-dev] glFog

[Brian P. <br...@pr...>]

Andreas Ehliar wrote:
> 
> On Mon, Jun 05, 2000 at 07:32:04AM -0600, Brian Paul wrote:
> >
> > ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH() would be the correct macro.
> > I'm patching the 3.2 and 3.3 trees.
> 
> What is the difference between ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH
> and ASSERT_OUTSIDE_BEGIN_END ?

ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH checks if there's any data in
the vertex buffer.  If there is, we first flush (render) the
vertex data before proceeding.

-Brian

Re: [Mesa3d-dev] glFog

[Andreas E. <eh...@ly...>]

On Mon, Jun 05, 2000 at 07:32:04AM -0600, Brian Paul wrote:
> 
> ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH() would be the correct macro.
> I'm patching the 3.2 and 3.3 trees.

What is the difference between ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH
and ASSERT_OUTSIDE_BEGIN_END ?

regards
Andreas Ehliar

Re: [Mesa3d-dev] vms directory missing in MesaLib-3.2.tar.gz

[Brian P. <br...@pr...>]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi,
> 
> I just got a notice that the directory
>    vms
> is missing in the 3.2 distribution. Probably this directory was not included
> when making the distribution from the CVS. The directory is however
> essential when compiling Mesa on a VMS-system.

I've now fixed the Makefiles which build the tar files.

Thanks.

-Brian

Re: [Mesa3d-dev] glFog

[Brian P. <br...@pr...>]

Daniel Vogel wrote:
> 
> hi`
> 
> according to the specs (OpenGL 1.2.1 specs, page 19) calling glFog
> between glBegin/End should generate an INVALID_OPERATION error. Or at
> least this is how I read the specs ;-) I attached a small patch to Mesa
> CVS that does the check but am not sure whether I call the right macro
> there.

ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH() would be the correct macro.
I'm patching the 3.2 and 3.3 trees.

Thanks!

-Brian

[Mesa3d-dev] vms directory missing in MesaLib-3.2.tar.gz

[<jo...@du...>]

Hi,

I just got a notice that the directory
   vms
is missing in the 3.2 distribution. Probably this directory was not included
when making the distribution from the CVS. The directory is however
essential when compiling Mesa on a VMS-system.

           Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

[Mesa3d-dev] glFog

[Daniel V. <vo...@lo...>]

hi`

according to the specs (OpenGL 1.2.1 specs, page 19) calling glFog
between glBegin/End should generate an INVALID_OPERATION error. Or at
least this is how I read the specs ;-) I attached a small patch to Mesa
CVS that does the check but am not sure whether I call the right macro
there.

-- 
Daniel Vogel
Programmer
Loki Entertainment Software