mesa3d-dev

Re: [Mesa3d-dev] GL extensions using

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

"I. Pokrovsky" wrote:
> 
> Hello!
> 
> When I'm using GL_EXT_shared_texture_palette OpenGL extension I'm
> getting an error: mesa got signal 11. I'm using latest MesaLib-3.4.2
> with glide.
> 
> It happends in such line:
> 
> glColorTableEXT (GL_SHARED_TEXTURE_PALETTE_EXT, GL_RGB, 256, GL_RGB, GL_UNSIGNED_BYTE, palette);
> 
> where palette - is "unsigned char palette[768]"
> 
> Such error happends with 3DFX_set_global_palette extension too.
> 
> Can anyone help me with such problem?

Haven't heard of this problem before.  I'll take a look at it, probably next week.

-Brian

[Mesa3d-dev] [ mesa3d-Bugs-437376 ] Incorrect lighting for NURBS surface

[<no...@so...>]

Bugs item #437376, was opened at 2001-06-29 07:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=437376&group_id=3

Category: GLU
Group: Rendering Error
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect lighting for NURBS surface

Initial Comment:
Mesa version: 3.5 (using SI-GLU)

Nurbs surfaces are incorrectly lighted. A few
rectangles of the mesh are wrongly shaded. The number
and position of the stains depends on the size and
orientation of the surface. This didn't happen with
Mesa 3.4.x.

[This bug is different from #212069.]

MESA_INFO gives:

X/Mesa visual = 0x8050c88
X/Mesa dithered pf = 13
X/Mesa undithered pf = 6
X/Mesa level = 0
X/Mesa depth = 16
X/Mesa bits per pixel = 16
X/Mesa visual = 0x8050c88
X/Mesa dithered pf = 13
X/Mesa undithered pf = 6
X/Mesa level = 0
X/Mesa depth = 16
X/Mesa bits per pixel = 16
Mesa GL_VERSION = 1.2 Mesa 3.5
Mesa GL_RENDERER = Mesa X11
Mesa GL_VENDOR = Brian Paul
Mesa GL_EXTENSIONS = GL_ARB_imaging GL_ARB_multitexture
GL_ARB_texture_border_clamp GL_ARB_texture_compression
GL_ARB_texture_cube_map GL_ARB_texture_env_add
GL_ARB_texture_env_combine GL_ARB_texture_env_dot3
GL_ARB_transpose_matrix GL_EXT_abgr GL_EXT_bgra
GL_EXT_blend_color GL_EXT_blend_func_separate
GL_EXT_blend_logic_op GL_EXT_blend_minmax
GL_EXT_blend_subtract GL_EXT_clip_volume_hint
GL_EXT_convolution GL_EXT_compiled_vertex_array
GL_EXT_fog_coord GL_EXT_histogram GL_EXT_packed_pixels
GL_EXT_paletted_texture GL_EXT_point_parameters
GL_EXT_polygon_offset GL_EXT_rescale_normal
GL_EXT_secondary_color GL_EXT_shared_texture_palette
GL_EXT_stencil_wrap GL_EXT_texture3D
GL_EXT_texture_env_add GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3 GL_EXT_texture_object
GL_EXT_texture_lod_bias GL_EXT_vertex_array
GL_HP_occlusion_test GL_INGR_blend_func_separate
GL_MESA_resize_buffers GL_MESA_window_pos
GL_NV_blend_square GL_NV_texgen_reflection
GL_SGI_color_matrix GL_SGI_color_table
GL_SGIS_generate_mipmap GL_SGIS_pixel_texture
GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp
GL_SGIX_depth_texture GL_SGIX_pixel_texture
GL_SGIX_shadow GL_SGIX_shadow_ambient
Mesa thread-safe: YES
Mesa x86-optimized: YES
Mesa sparc-optimized: NO

There is also some output:

arc_ccw_turn, p = 0
case b
arc_ccw_turn, p = 0
case d
arc_ccw_turn, p = 0
case a
arc_ccw_turn, p = 0
case c
[...]

Example:

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

double wx = 0; // rotation along x-axis
double wy = 0; // rotation along y-axis
double s  = 1; // scaling factor

GLUnurbsObj* nobj;

void init()
{
  GLfloat light0[4] = { 0.0, 0.0, 10.0, 1.0 };
  glLightfv (GL_LIGHT0, GL_POSITION, light0);
  glEnable (GL_LIGHT0);

  glEnable(GL_DEPTH_TEST);
  glEnable(GL_AUTO_NORMAL);
  glEnable(GL_NORMALIZE);
  glEnable(GL_LIGHTING);

  nobj = gluNewNurbsRenderer();
}

void draw()
{
  /* knot vectors */
  GLfloat U[12] = { 0, 0, 0, 0.25, 0.25, 0.5, 0.5,
0.75, 0.75, 1, 1, 1 };
  GLfloat V[8]  = { 0, 0, 0, 0.5,  0.5, 1, 1, 1 };

  /* control points */
  GLfloat a = 0.5*sqrt(2);
  GLfloat b = 0.5;
  GLfloat P[45][4] = { {1, 0, 0, 1 }, {a,  a,  0, a},
{0,  1,  0, 1}, {-a,  a,  0, a}, {-1, 0, 0, 1},
                       {a, 0, 0, a }, {b,  b,  b, b},
{0,  a,  a, a}, {-b,  b,  b, b}, {-a, 0, 0, a},
                       {1, 0, 0, 1 }, {a,  0,  a, a},
{0,  0,  1, 1}, {-a,  0,  a, a}, {-1, 0, 0, 1},
                       {a, 0, 0, a }, {b, -b,  b, b},
{0, -a,  a, a}, {-b, -b,  b, b}, {-a, 0, 0, a},
                       {1, 0, 0, 1 }, {a, -a,  0, a},
{0, -1,  0, 1}, {-a, -a,  0, a}, {-1, 0, 0, 1},
                       {a, 0, 0, a }, {b, -b, -b, b},
{0, -a, -a, a}, {-b, -b, -b, b}, {-a, 0, 0, a},
                       {1, 0, 0, 1 }, {a,  0, -a, a},
{0,  0, -1, 1}, {-a,  0, -a, a}, {-1, 0, 0, 1},
                       {a, 0, 0, a }, {b,  b, -b, b},
{0,  a, -a, a}, {-b,  b, -b, b}, {-a, 0, 0, a},
                       {1, 0, 0, 1 }, {a,  a,  0, a},
{0,  1,  0, 1}, {-a,  a,  0, a}, {-1, 0, 0, 1} };

  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

  glPushMatrix();

  glRotated(wy,0,1,0);
  glRotated(wx,1,0,0);
  glScaled(s,s,s);

  gluBeginSurface(nobj);
  gluNurbsSurface(nobj, 12, U, 8, V, 5*4, 4, &P[0][0],
3, 3, GL_MAP2_NORMAL);
  gluNurbsSurface(nobj, 12, U, 8, V, 5*4, 4, &P[0][0],
3, 3, GL_MAP2_VERTEX_4);
  gluEndSurface(nobj);

  glPopMatrix();
  glutSwapBuffers();
}

int main(int argc, char **argv)
{
  if (argc>=4)
    {
      s  = atof(argv[1]);
      wx = atof(argv[2]);
      wy = atof(argv[3]);
    }

  glutInit(&argc, argv);
  glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE |
GLUT_DEPTH);
  glutInitWindowSize(600,600);
  glutInitWindowPosition(0,0);
  glutCreateWindow(argv[0]);
  glutDisplayFunc(draw);

  init();

  glutMainLoop();
  return 0;
}




----------------------------------------------------------------------

Comment By: Joachim Reichel (reichel)
Date: 2001-06-29 07:54

Message:
Logged In: YES 
user_id=28760

Oops, wasn't logged in.
Submitted by: Joachim Reichel (reichel)
Email: joa...@gm...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=437376&group_id=3

[Mesa3d-dev] [ mesa3d-Bugs-437376 ] Incorrect lighting for NURBS surface

[<no...@so...>]

Bugs item #437376, was opened at 2001-06-29 07:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=437376&group_id=3

Category: GLU
Group: Rendering Error
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect lighting for NURBS surface

Initial Comment:
Mesa version: 3.5 (using SI-GLU)

Nurbs surfaces are incorrectly lighted. A few
rectangles of the mesh are wrongly shaded. The number
and position of the stains depends on the size and
orientation of the surface. This didn't happen with
Mesa 3.4.x.

[This bug is different from #212069.]

MESA_INFO gives:

X/Mesa visual = 0x8050c88
X/Mesa dithered pf = 13
X/Mesa undithered pf = 6
X/Mesa level = 0
X/Mesa depth = 16
X/Mesa bits per pixel = 16
X/Mesa visual = 0x8050c88
X/Mesa dithered pf = 13
X/Mesa undithered pf = 6
X/Mesa level = 0
X/Mesa depth = 16
X/Mesa bits per pixel = 16
Mesa GL_VERSION = 1.2 Mesa 3.5
Mesa GL_RENDERER = Mesa X11
Mesa GL_VENDOR = Brian Paul
Mesa GL_EXTENSIONS = GL_ARB_imaging GL_ARB_multitexture
GL_ARB_texture_border_clamp GL_ARB_texture_compression
GL_ARB_texture_cube_map GL_ARB_texture_env_add
GL_ARB_texture_env_combine GL_ARB_texture_env_dot3
GL_ARB_transpose_matrix GL_EXT_abgr GL_EXT_bgra
GL_EXT_blend_color GL_EXT_blend_func_separate
GL_EXT_blend_logic_op GL_EXT_blend_minmax
GL_EXT_blend_subtract GL_EXT_clip_volume_hint
GL_EXT_convolution GL_EXT_compiled_vertex_array
GL_EXT_fog_coord GL_EXT_histogram GL_EXT_packed_pixels
GL_EXT_paletted_texture GL_EXT_point_parameters
GL_EXT_polygon_offset GL_EXT_rescale_normal
GL_EXT_secondary_color GL_EXT_shared_texture_palette
GL_EXT_stencil_wrap GL_EXT_texture3D
GL_EXT_texture_env_add GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3 GL_EXT_texture_object
GL_EXT_texture_lod_bias GL_EXT_vertex_array
GL_HP_occlusion_test GL_INGR_blend_func_separate
GL_MESA_resize_buffers GL_MESA_window_pos
GL_NV_blend_square GL_NV_texgen_reflection
GL_SGI_color_matrix GL_SGI_color_table
GL_SGIS_generate_mipmap GL_SGIS_pixel_texture
GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp
GL_SGIX_depth_texture GL_SGIX_pixel_texture
GL_SGIX_shadow GL_SGIX_shadow_ambient
Mesa thread-safe: YES
Mesa x86-optimized: YES
Mesa sparc-optimized: NO

There is also some output:

arc_ccw_turn, p = 0
case b
arc_ccw_turn, p = 0
case d
arc_ccw_turn, p = 0
case a
arc_ccw_turn, p = 0
case c
[...]

Example:

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

double wx = 0; // rotation along x-axis
double wy = 0; // rotation along y-axis
double s  = 1; // scaling factor

GLUnurbsObj* nobj;

void init()
{
  GLfloat light0[4] = { 0.0, 0.0, 10.0, 1.0 };
  glLightfv (GL_LIGHT0, GL_POSITION, light0);
  glEnable (GL_LIGHT0);

  glEnable(GL_DEPTH_TEST);
  glEnable(GL_AUTO_NORMAL);
  glEnable(GL_NORMALIZE);
  glEnable(GL_LIGHTING);

  nobj = gluNewNurbsRenderer();
}

void draw()
{
  /* knot vectors */
  GLfloat U[12] = { 0, 0, 0, 0.25, 0.25, 0.5, 0.5,
0.75, 0.75, 1, 1, 1 };
  GLfloat V[8]  = { 0, 0, 0, 0.5,  0.5, 1, 1, 1 };

  /* control points */
  GLfloat a = 0.5*sqrt(2);
  GLfloat b = 0.5;
  GLfloat P[45][4] = { {1, 0, 0, 1 }, {a,  a,  0, a},
{0,  1,  0, 1}, {-a,  a,  0, a}, {-1, 0, 0, 1},
                       {a, 0, 0, a }, {b,  b,  b, b},
{0,  a,  a, a}, {-b,  b,  b, b}, {-a, 0, 0, a},
                       {1, 0, 0, 1 }, {a,  0,  a, a},
{0,  0,  1, 1}, {-a,  0,  a, a}, {-1, 0, 0, 1},
                       {a, 0, 0, a }, {b, -b,  b, b},
{0, -a,  a, a}, {-b, -b,  b, b}, {-a, 0, 0, a},
                       {1, 0, 0, 1 }, {a, -a,  0, a},
{0, -1,  0, 1}, {-a, -a,  0, a}, {-1, 0, 0, 1},
                       {a, 0, 0, a }, {b, -b, -b, b},
{0, -a, -a, a}, {-b, -b, -b, b}, {-a, 0, 0, a},
                       {1, 0, 0, 1 }, {a,  0, -a, a},
{0,  0, -1, 1}, {-a,  0, -a, a}, {-1, 0, 0, 1},
                       {a, 0, 0, a }, {b,  b, -b, b},
{0,  a, -a, a}, {-b,  b, -b, b}, {-a, 0, 0, a},
                       {1, 0, 0, 1 }, {a,  a,  0, a},
{0,  1,  0, 1}, {-a,  a,  0, a}, {-1, 0, 0, 1} };

  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

  glPushMatrix();

  glRotated(wy,0,1,0);
  glRotated(wx,1,0,0);
  glScaled(s,s,s);

  gluBeginSurface(nobj);
  gluNurbsSurface(nobj, 12, U, 8, V, 5*4, 4, &P[0][0],
3, 3, GL_MAP2_NORMAL);
  gluNurbsSurface(nobj, 12, U, 8, V, 5*4, 4, &P[0][0],
3, 3, GL_MAP2_VERTEX_4);
  gluEndSurface(nobj);

  glPopMatrix();
  glutSwapBuffers();
}

int main(int argc, char **argv)
{
  if (argc>=4)
    {
      s  = atof(argv[1]);
      wx = atof(argv[2]);
      wy = atof(argv[3]);
    }

  glutInit(&argc, argv);
  glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE |
GLUT_DEPTH);
  glutInitWindowSize(600,600);
  glutInitWindowPosition(0,0);
  glutCreateWindow(argv[0]);
  glutDisplayFunc(draw);

  init();

  glutMainLoop();
  return 0;
}




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=437376&group_id=3

[Mesa3d-dev] [Fwd: Link problem for Mesa 3.5 - patch included]

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

Sven, can you look at this?

-Brian


Lans Carstensen wrote:
> 
> Greetings!
> 
> There is a problem with the libMesaOS.la during builds, such that
> src/.libs/libGL.so.* get moved aside and not relinked on a "make
> install".  Instead of pointing at the .libs directory for linking, the
> build is pointing to /usr/lib when relinking with -lMesaOS.
> 
> Basically, a clean build on a clean machine won't work because of this.
> The patch below fixes this.  Looks like it was a typo.  I was able to
> rebuild Mesa 3.5 RPMs for RedHat 7.1 for some of our internal work with
> this patch.  If you'd like me to submit my Mesa 3.5 source RPM, I'd be
> happy to - just let me know where to FTP it.
> 
> *** src/OSmesa/Makefile.am.orig Wed Jun 27 16:02:16 2001
> --- src/OSmesa/Makefile.am      Wed Jun 27 16:02:30 2001
> ***************
> *** 5,11 ****
>   INCLUDES = -I$(top_srcdir)/include -I$(top_srcdir)/src
> 
>   if HAVE_OSMESA
> ! lib_LTLIBRARIES = libMesaOS.la
>   endif
> 
>   libMesaOS_la_SOURCES = osmesa.c
> --- 5,11 ----
>   INCLUDES = -I$(top_srcdir)/include -I$(top_srcdir)/src
> 
>   if HAVE_OSMESA
> ! noinst_LTLIBRARIES = libMesaOS.la
>   endif
> 
>   libMesaOS_la_SOURCES = osmesa.c
> 
> --
> Lans Carstensen - la...@an...
> Dreamworks Feature Animation Technology network guy

[Mesa3d-dev] GL extensions using

[I. P. <igo...@ma...>]

Hello!

When I'm using GL_EXT_shared_texture_palette OpenGL extension I'm
getting an error: mesa got signal 11. I'm using latest MesaLib-3.4.2
with glide.

It happends in such line:

glColorTableEXT (GL_SHARED_TEXTURE_PALETTE_EXT, GL_RGB, 256, GL_RGB, GL_UNSIGNED_BYTE, palette);

where palette - is "unsigned char palette[768]"

Such error happends with 3DFX_set_global_palette extension too.

Can anyone help me with such problem?

===============================================================

 Thursday, June 28, 2001, 8:24:05 AM           I.Pokrovsky

Re: [Mesa3d-dev] src-glut missing from .tar.gz?

[Sven M. H. <pe...@gm...>]

On Mon, Jun 25, 2001 at 11:17:44PM +0200, Marcelo E. Magallon wrote:
>  configure.in wants to have the glut sources (why?) but there's no
>  src-glut in the tarball.

Thanks for this pointer, too! :) That constraint came from autoconf 2.13. I
just shuffled some stuff around in configure.in so the build system should now
deal correctly with non-present GLUT and demo directories.

Right now I'm still testing things out, but everything appears to work fine
and the CVS commit should not be far.

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

[Mesa3d-dev] src-glut missing from .tar.gz?

[Marcelo E. M. <mar...@bi...>]

Hi,

 configure.in wants to have the glut sources (why?) but there's no
 src-glut in the tarball.

-- 
Marcelo

Re: [Mesa3d-dev] libtool problem

[Marcelo E. M. <mar...@bi...>]

>> "Sven M. Hallberg" <pe...@gm...> writes:

 > Actually, I'm pretty sure that an explicit libtoolize is not needed,
 >         automake -a -c
 > does it itself (I think it says so in the docs, too).

 Oh, cool.

 > Oh, thanks for pointing this out, I've just fixed it. I had missed a
 > minor point of the automake doc, which says that generated source
 > files must be mentioned in a BUILT_SOURCES variable. It's in there
 > now, and matypes.h is _really_ generated automagically whenever
 > needed now.

 Oh, even cooler!

 Perhaps you know how to fix this one...  m4/assembler.m4 reads:

AC_DEFUN(MESA_SYS_AS_FEATURE, [
  AC_CACHE_CHECK(whether the assembler supports $1,
                 mesa_cv_sys_as_$1,
                 MESA_TRY_ASSEMBLE([#include "src/X86/assyntax.h"], $2,
                                   mesa_cv_sys_as_$1=3Dyes,
                                   mesa_cv_sys_as_$1=3Dno))
])

 I need to get -I$(srcdir) on the command line because I use VPATH to
 compile mesa (cd buld/software && ../../configure).  MESA_TRY_ASSEMBLE
 looks like this:

AC_DEFUN(MESA_TRY_ASSEMBLE, [
  cat > conftest.S <<EOF
$1

$2
EOF
  save_ac_ext=3D"$ac_ext"
  ac_ext=3DS
  if AC_TRY_EVAL(ac_compile); then
    $3;
  else
    $4;
  fi=B7=B7=B7=B7
  ac_ext=3D"$save_ac_ext"
  rm -f conftest.S
])

 doesn't ac_compile already include all the necessary -I's?  I thought so=
 but
 on the config.log I have:

configure:7290: gcc -c -g -O2 -Wall -fomit-frame-pointer -ffast-math -fex=
pensive
-optimizations -fstrict-aliasing -malign-loops=3D2 -malign-jumps=3D2 -mal=
ign-functio
ns=3D2 -D_REENTRANT -DPTHREADS  -I../../src/X86 conftest.S >&5
conftest.S:1: src/X86/assyntax.h: No such file or directory

 I can fix this on the command line, but I'm wondering what's the nice
 autoconf way of doing this...

 Cheers,

--=20
Marcelo

[Mesa3d-dev] docs/COPYRIGHT actualization

[Marcelo E. M. <mar...@bi...>]

Hi,

 Attached is a patch for 3.5's docs/COPYRIGHT.  I called si-glu "SI GLU
 library" and glext.h, glxext.h "Extension registry".

-- 
Marcelo

Re: [Mesa3d-dev] libtool problem

[Sven M. H. <pe...@gm...>]

On Tue, Jun 19, 2001 at 09:22:16PM +0200, Marcelo E. Magallon wrote:
>  Nope, libtoolize is missing on the bootstrap script.  Something like
>  this:
> 
>  run_cmd cat m4/*.m4 > acinclude.m4
>  run_cmd libtoolize --automake --copy --force
>  run_cmd aclocal

Actually, I'm pretty sure that an explicit libtoolize is not needed,
        automake -a -c
does it itself (I think it says so in the docs, too).


>  The other problem is that matypes.h is not being generated.

Oh, thanks for pointing this out, I've just fixed it. I had missed a minor
point of the automake doc, which says that generated source files must be
mentioned in a BUILT_SOURCES variable. It's in there now, and matypes.h is
_really_ generated automagically whenever needed now.


-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

[Mesa3d-dev] [ mesa3d-Bugs-436064 ] solaris 2.6/Mesa-3.5 - libnurbs compile problem

[<no...@so...>]

Bugs item #436064, was opened at 2001-06-25 03:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=436064&group_id=3

Category: GLU
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Ross Campbell (ross)
Assigned to: Nobody/Anonymous (nobody)
>Summary: solaris 2.6/Mesa-3.5 - libnurbs compile problem

Initial Comment:
System is sparc solaris 2.6 with all GNU utils. gcc is
2.95.3. Compile fails as follows

gmake[4]: Entering directory
`/tmp/Mesa-3.5/si-glu/libnurbs/internals'
/bin/sh ../../../libtool --mode=compile g++
-DHAVE_CONFIG_H -I. -I. -I../../.. -I../../include
-I../nurbtess  -I./src/X86  -DLIBRARYBUILD -c
mapdesc.cc
g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../include
-I../nurbtess -I./src/X86 -DLIBRARYBUILD
-Wp,-MD,.deps/mapdesc.pp -c mapdesc.cc  -fPIC -DPIC -o
mapdesc.omapdesc.cc: In method `int
Mapdesc::bboxTooBig(REAL *, int, int, int, int, float
(*)[5])':
mapdesc.cc:689: implicit declaration of function `int
ceilf(...)'
mapdesc.cc:689: implicit declaration of function `int
floorf(...)'
gmake[4]: *** [mapdesc.lo] Error 1
gmake[4]: Leaving directory
`/tmp/Mesa-3.5/si-glu/libnurbs/internals'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/tmp/Mesa-3.5/si-glu/libnurbs'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/tmp/Mesa-3.5/si-glu'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/tmp/Mesa-3.5'
gmake: *** [all-recursive-am] Error 2


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=436064&group_id=3

[Mesa3d-dev] [ mesa3d-Bugs-436064 ] solaris 2.6 - libnurbs compile problem

[<no...@so...>]

Bugs item #436064, was opened at 2001-06-25 03:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=436064&group_id=3

Category: GLU
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Ross Campbell (ross)
Assigned to: Nobody/Anonymous (nobody)
Summary: solaris 2.6 - libnurbs compile problem

Initial Comment:
System is sparc solaris 2.6 with all GNU utils. gcc is
2.95.3. Compile fails as follows

gmake[4]: Entering directory
`/tmp/Mesa-3.5/si-glu/libnurbs/internals'
/bin/sh ../../../libtool --mode=compile g++
-DHAVE_CONFIG_H -I. -I. -I../../.. -I../../include
-I../nurbtess  -I./src/X86  -DLIBRARYBUILD -c
mapdesc.cc
g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../include
-I../nurbtess -I./src/X86 -DLIBRARYBUILD
-Wp,-MD,.deps/mapdesc.pp -c mapdesc.cc  -fPIC -DPIC -o
mapdesc.omapdesc.cc: In method `int
Mapdesc::bboxTooBig(REAL *, int, int, int, int, float
(*)[5])':
mapdesc.cc:689: implicit declaration of function `int
ceilf(...)'
mapdesc.cc:689: implicit declaration of function `int
floorf(...)'
gmake[4]: *** [mapdesc.lo] Error 1
gmake[4]: Leaving directory
`/tmp/Mesa-3.5/si-glu/libnurbs/internals'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/tmp/Mesa-3.5/si-glu/libnurbs'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/tmp/Mesa-3.5/si-glu'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/tmp/Mesa-3.5'
gmake: *** [all-recursive-am] Error 2


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=436064&group_id=3

[Mesa3d-dev] Bug in affine triangles?

[Klaus N. <kl...@ma...>]

Hi,

I modified the 'fire'-demo, because I wanted to see how it worked with the
affine_triangle function, basically I used 'GL_NEAREST' for Min and Max
and I set GL_PERSPECTIVE_CORRECTION_HINT to GL_FASTEST and the results I
get are pretty strange. I know that texturing can look wrong, but here
half of the trees at the border of the screen are just missing and the
ground at the bottom seems to be foggy, though I switch fog off (yes, if I
switch fog off, the fog disappears, but only for the polygons that are not
close to the border of the screen).

This problem is related to 'GL_MODULATE', because if I switch to
'GL_REPLACE' everything looks o.k.

I was using the CVS-version of the week before last week for my tests and
software-rendering.

Bye

	Klaus

[Mesa3d-dev] [ mesa3d-Support Requests-435921 ] Voodoo 5 with Mesa

[<no...@so...>]

Support Requests item #435921, was opened at 2001-06-24 14:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=200003&aid=435921&group_id=3

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Voodoo 5 with Mesa

Initial Comment:
How do I get Mesa to use the tdfx driver and run the
applications in fullscreen mode?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=200003&aid=435921&group_id=3

[Mesa3d-dev] [ mesa3d-Bugs-435682 ] Can't compile Mesa 3.5 with VC++ 6.0

[<no...@so...>]

Bugs item #435682, was opened at 2001-06-23 07:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=435682&group_id=3

Category: None
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't compile Mesa 3.5 with VC++ 6.0

Initial Comment:

When trying to compile Mesa 3D version 3.5 with:
nmake /f Makefile.win
I get following error messages:
tnl\t_imm_dlist.c(502) : error C2152: '=' : pointers 
to functions with different attributes
tnl\t_imm_dlist.c(504) : error C2152: '=' : pointers 
to functions with different attributes
tnl\t_imm_dlist.c(510) : warning C4018: '==' : 
signed/unsigned mismatch
tnl\t_imm_dlist.c(511) : error C2152: '=' : pointers 
to functions with different attributes
tnl\t_imm_dlist.c(513) : error C2152: '=' : pointers 
to functions with different attributes
tnl\t_imm_dlist.c(515) : error C2152: '=' : pointers 
to functions with different attributes

My compiler (VC++ 6.0) should be correctly installed 
so that isn't the problem, I think.

Is there some compiler option that should be enabled?
If not, what is the problem?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100003&aid=435682&group_id=3

Re: [Mesa3d-dev] Bitmap and Pixmap Positioning

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

Allen Barnett wrote:
> 
> Brian Paul wrote:
> >
> > Allen Barnett wrote:
> > > Maybe Mesa
> > > could be configured w/o Glide by default now that DRI is the way to go?
> >
> > Try ./configure --without-glide
> 
> (OK. I just meant to make --without-glide the default.)

That'll probably be the default in the future.  I don't know if many
people are still using the Glide driver.


> Also, about raster images: I see that you added a glWindowPosMESA
> extension which doesn't suffer from the viewport clipping effect of
> glRasterPos. However, the units of glWindowPos are the direct window
> coordinates. I think I need something somewhere in between, i.e., to
> draw an image at coordinates which are transformed by the
> projection/modelview matrices but whose origin may be outside the
> viewport. I know about the glBitmap(0,0,0,0,xmove,ymove,NULL) trick, but
> the xmove/ymove coordinates are in pixels, not model units. The
> following seems to work OK:
> 
> glGet viewing matrices
> gluProject( mx, my, mz, viewing matrices, &wx, &wy, &wz);
> glWindowPosMESA( wx, wy );
> glDrawPixels(...);
> 
> but this seems inefficient (as well as requiring a MESA extension). Is
> there some better trick I'm missing?

Take a look at this:
http://oss.sgi.com/projects/ogl-sample/registry/IBM/rasterpos_clip.txt

I could pretty easily implement this extension if you want it.

-Brian

Re: [Mesa3d-dev] Bitmap and Pixmap Positioning

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

Brian Paul wrote:
> 
> Allen Barnett wrote:
> >
> > Hi,
> >
> > In the routine _mesa_DrawPixels in the file src/drawpix.c, the current
> > raster position is converted to integer coordinates through the IROUND
> > function (round to nearest, I think?). However, in the routine
> > _mesa_Bitmap, the raster position is just cast to a GLint. At least on
> > my system (RedHat 7.1/i386, gcc 2.96), these occasionally give different
> > values, which I can see as inconsistencies in the positioning of bitmaps
> > and pixmaps. I was wondering what the reason was for treating these
> > conversions differently? (_mesa_CopyPixels gets the IROUND, too.)
> 
> Sounds like a bug.  glBitmap should use rounding as well.

Hmmm, I'm not so sure now.  If I change glBitmap to round off the
coordinates then the conformance test fails.  Similarly, if I change
glDraw/CopyPixels to truncate the coordinates then conformance fails
too.

When I have more time I'll look closer at this.  I'll leave things
as-are for now (conformant).

-Brian

Re: [Mesa3d-dev] Bitmap and Pixmap Positioning

[Allen B. <ba...@lo...>]

Brian Paul wrote:
> 
> Allen Barnett wrote:
> > Maybe Mesa
> > could be configured w/o Glide by default now that DRI is the way to go?
> 
> Try ./configure --without-glide

(OK. I just meant to make --without-glide the default.)

Also, about raster images: I see that you added a glWindowPosMESA
extension which doesn't suffer from the viewport clipping effect of
glRasterPos. However, the units of glWindowPos are the direct window
coordinates. I think I need something somewhere in between, i.e., to
draw an image at coordinates which are transformed by the
projection/modelview matrices but whose origin may be outside the
viewport. I know about the glBitmap(0,0,0,0,xmove,ymove,NULL) trick, but
the xmove/ymove coordinates are in pixels, not model units. The
following seems to work OK:

glGet viewing matrices
gluProject( mx, my, mz, viewing matrices, &wx, &wy, &wz);
glWindowPosMESA( wx, wy );
glDrawPixels(...);

but this seems inefficient (as well as requiring a MESA extension). Is
there some better trick I'm missing?

Thanks,
Allen

Re: [Mesa3d-dev] Bitmap and Pixmap Positioning

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

Allen Barnett wrote:
> 
> Hi,
> 
> In the routine _mesa_DrawPixels in the file src/drawpix.c, the current
> raster position is converted to integer coordinates through the IROUND
> function (round to nearest, I think?). However, in the routine
> _mesa_Bitmap, the raster position is just cast to a GLint. At least on
> my system (RedHat 7.1/i386, gcc 2.96), these occasionally give different
> values, which I can see as inconsistencies in the positioning of bitmaps
> and pixmaps. I was wondering what the reason was for treating these
> conversions differently? (_mesa_CopyPixels gets the IROUND, too.)

Sounds like a bug.  glBitmap should use rounding as well.



> Also, I downloaded the tar file of MesaLib-3.5 from SourceForge and
> tried to build it from scratch, but it would not complete its
> ./configure run unless src-glut/ was installed from MesaDemos, too.
> Perhaps this is worth a note in the documentation? The other minor
> glitch I noticed was that RH 7.1 installs the Glide libraries by
> default, which causes ./configure to pick up them up and compile the
> Glide driver. This treats you to the message: WARNING: This Mesa Library
> includes the Glide driver... when you first run a program. Maybe Mesa
> could be configured w/o Glide by default now that DRI is the way to go?

Try ./configure --without-glide

-Brian

[Mesa3d-dev] Bitmap and Pixmap Positioning

[Allen B. <ba...@lo...>]

Hi,

In the routine _mesa_DrawPixels in the file src/drawpix.c, the current
raster position is converted to integer coordinates through the IROUND
function (round to nearest, I think?). However, in the routine
_mesa_Bitmap, the raster position is just cast to a GLint. At least on
my system (RedHat 7.1/i386, gcc 2.96), these occasionally give different
values, which I can see as inconsistencies in the positioning of bitmaps
and pixmaps. I was wondering what the reason was for treating these
conversions differently? (_mesa_CopyPixels gets the IROUND, too.)

Also, I downloaded the tar file of MesaLib-3.5 from SourceForge and
tried to build it from scratch, but it would not complete its
./configure run unless src-glut/ was installed from MesaDemos, too.
Perhaps this is worth a note in the documentation? The other minor
glitch I noticed was that RH 7.1 installs the Glide libraries by
default, which causes ./configure to pick up them up and compile the
Glide driver. This treats you to the message: WARNING: This Mesa Library
includes the Glide driver... when you first run a program. Maybe Mesa
could be configured w/o Glide by default now that DRI is the way to go?

Thanks,
Allen

Re: [Mesa3d-dev] Mesa-3.5: unresolved symbols in libGLU after latest CVS update

[Dieter <Die...@ha...>]

Am Mittwoch, 20. Juni 2001 16:52 schrieb Marcelo E. Magallon:
> >> Dieter Nützel <Die...@ha...> writes:
> >>
>  > gcc -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
>  > -fschedule-insns2 -fexpensive-optimizations -I../include -I../util -Wall
>  > -ansi -pedantic -fPIC
>  > -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE
>  > -DUSE_XSHM -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
>  > -DPTHREADS -I/usr/X11R6/include anisotropic.c -L../lib -lglut -lGLU -lGL
>  > -lm -o anisotropic
>
>  does the error go away if you link with g++ instead of gcc?

No, but I solved it, now.

I've installed gcc-3.0 (final, yah) in /usr/local for testing and after that 
some C++ apps would be linked against libstdc++.so.3 without my request???

Thanks for your response and sorry for the alarm.

-Dieter

BTW Mesa-3.5 (final) is running fine, too :-)

[Mesa3d-dev] Mesa 3.5 released

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

Mesa 3.5 is now available for download at
http://sourceforge.net/project/showfiles.php?group_id=3

This is a development release (vs. a stable release) as indicated by the 
odd minor version number.  This basically means that Mesa 3.5 has a lot
of new features and changes and possibly a few new bugs.  Though, 3.5
testing has been very positive so far.

Mesa 3.5 has undergone a major source code reorganization.  It's now
more modularized and has a much cleaner interface for hardware
acceleration (for the DRI 3D drivers).  Keith Whitwell can be credited
with that.

Mesa 3.5 also has a lot of new extensions:

	- GL_EXT_convolution
	- GL_ARB_imaging
	- GL_ARB_texture_env_add
	- GL_EXT_fog_coord
	- GL_EXT_secondary_color
	- GL_ARB_texture_env_add
	- GL_ARB_texture_env_combine
	- GL_ARB_texture_env_dot3
	- GL_ARB_texture_border_clamp (aka GL_SGIS_texture_border_clamp)
	- GL_SGIX_depth_texture
	- GL_SGIX_shadow and GL_SGIX_shadow_ambient
	- GL_SGIS_generate_mipmap

Other features include:

	- support for eight texture units
	- SGI's GLU 1.3 library
	- new, conformant AA line algorithm
	- SPARC assembly language optimization, by David Miller
	- assorted performance improvements
	- 16-bit/channel (64-bit pixels) rendering option in OSMesa
	- assorted bug fixes
	- new demo programs

One problem with Mesa 3.5 is the fact that a number of the device drivers
haven't been updated.  This includes the DOS and Windows drivers.  We're
hoping someone will volunteer to do that work.

See the docs/RELNOTES-3.5 and docs/VERSIONS files for more details.

Please report any problem you find to the Mesa bug database.

-Brian

Re: [Mesa3d-dev] Mesa-3.5: unresolved symbols in libGLU after latest CVS update

[Marcelo E. M. <mar...@bi...>]

>> Dieter Nützel <Die...@ha...> writes:

 > gcc -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4 
 > -fschedule-insns2 -fexpensive-optimizations -I../include -I../util -Wall 
 > -ansi -pedantic -fPIC
 > -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE 
 > -DUSE_XSHM -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM 
 > -DPTHREADS -I/usr/X11R6/include anisotropic.c -L../lib -lglut -lGLU -lGL -lm 
 > -o anisotropic

 does the error go away if you link with g++ instead of gcc?

-- 
Marcelo

[Mesa3d-dev] Mesa-3.5: unresolved symbols in libGLU after latest CVS update

[Dieter <Die...@ha...>]

gcc -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4 
-fschedule-insns2 -fexpensive-optimizations -I../include -I../util -Wall 
-ansi -pedantic -fPIC
-D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE 
-DUSE_XSHM -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM 
-DPTHREADS -I/usr/X11R6/include anisotropic.c -L../lib -lglut -lGLU -lGL -lm 
-o anisotropic
../lib/libGLU.so: undefined reference to `operator new[](unsigned)'
../lib/libGLU.so: undefined reference to `vtable for 
__cxxabiv1::__si_class_type_info'
../lib/libGLU.so: undefined reference to `operator delete(void*)'
../lib/libGLU.so: undefined reference to `__gxx_personality_v0'
../lib/libGLU.so: undefined reference to `__cxa_pure_virtual'
../lib/libGLU.so: undefined reference to `vtable for 
__cxxabiv1::__class_type_info'
../lib/libGLU.so: undefined reference to `operator delete[](void*)'
../lib/libGLU.so: undefined reference to `vtable for 
__cxxabiv1::__vmi_class_type_info'
../lib/libGLU.so: undefined reference to `operator new(unsigned)'
collect2: ld returned 1 exit status
make[2]: *** [anisotropic] Error 1
make[2]: Leaving directory `/opt/Mesa/demos'
make[1]: *** [linux-x86] Error 2
make[1]: Leaving directory `/opt/Mesa/demos'
make: *** [linux-x86] Error 2

Thanks,
	Dieter

Re: [Mesa3d-dev] Unaligned traps in __indirect_glFrustum

[Mike A. H. <mh...@re...>]

On Mon, 18 Jun 2001, Brian Paul wrote:

>The preprocessor token __GLX_ALIGN64 should fix that.  The
>__GLX_PUT_DOUBLE() macro is defined as follows:
>
>#ifdef __GLX_ALIGN64
>/*
>** This can certainly be done better for a particular machine
>** architecture!
>*/
>#define __GLX_PUT_DOUBLE(offset,a) \
>    __GLX_MEM_COPY(pc + offset, &a, 8)
>#else
>#define __GLX_PUT_DOUBLE(offset,a) \
>    *((FLOAT64 *) (pc + offset)) = a
>#endif
>
>
>The following patch should fix this:
>
>Index: Imakefile
>===================================================================
>RCS file: /cvsroot/dri/xc/xc/lib/GL/glx/Imakefile,v
>retrieving revision 1.10
>diff -r1.10 Imakefile
>89a90,92
>> #if defined(AlphaArchitecture)
>>      GLX_DEFS = GlxDefines -D__GLX_ALIGN64
>> #else
>90a94,95
>> #endif
>>

Thanks Brian, I'll apply it to my next build.
TTYL


----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc.                    Ontario, Canada, P6C 5B3
http://www.redhat.com           Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS:      ftp://people.redhat.com/mharris/testing