mesa3d-dev

[Mesa3d-dev] release testing

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

I'm planning to release Mesa 3.2.1 (bug fixes since 3.2)
and Mesa 3.3 (lots of new code, extensions, etc) in the
near future, hopefully early next week.

I'd appreciate people downloading the latest sources and
testing.  Report any problems ASAP.

Thanks.

-Brian

Re: [Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

[Dave S. <shr...@sg...>]

Hi all,

   I've checked in the changes that Olivier Michel suggested for fixing
glue.c, and cleaned up the variable and function naming to reduce the
confusion (__gl -> __glu), just for cliarity's sake.  These changes have 
been checked into the CVS depot, but we haven't rolled a new tarball yet
(soon, I promise).

   I'm working to clean up the header file generation, particularly the
OpenGL 1.0 compatibility lines that appear in glu.h, and I'd like to
move the _GLfuncptr define from gl.h and into glu.h, since there's
nothing in GL proper that requires function pointers.

Thanx,
Dave

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

   Dave Shreiner                                   <shr...@sg...>
   Silicon Graphics, Inc.                            (650) 933-4899

[Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration

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

Olivier Michel wrote:
> 
> Good news: It was a bit tricky, but I successfully built 2 RPM binary
> packages (for i386)
> 
>   ogl-sample-glu-1.3.04JUL00-1.i386.rpm and
> mesa-without-glu-3.3.04JUL00-1.i386.rpm
> 
> I am not sure the names and version numbering are fine, but that's just
> a first trial.
> 
> You may use rpm -Uvh with --nodeps or --force to get them installed
> properly on differents Linux distros I could test it on Suze 6.4, Redhat
> 6.0 and Slackware 7.0 and seemed to work properly: the tesselator
> doesn't crash my app any more :)
> 
> These packages are available at ftp://ftp.cyberbotics.com (you may also
> download the other packages to test my app: webots).
> 
> I finally found the real problem with building the SGI libGLU from the
> current CVS:
> 
> In the file glue.c, the functions
> 
> static const char *__glNURBSErrorString( int errno )
> 
> and
> 
> static const char *__glTessErrorString( int errno )
> 
> should not be defined as static because they are used by error.c. This
> cause the libGLU.so doesn't work at runtime because it doesn't find
> these functions called by error.c (which are local to glue.c).
> 
> So, the fix is pretty simple: just remove the static keyword for these
> two functions in glue.c
> 
> Again, since I have no write access to the CVS, I hope someone could do
> it for me.
> 
> Moreover I had to hack the glu.h problem by hand.


Olivier,

What's the status on this project?

-Brian

Re: [Mesa3d-dev] Problems fixing Mesa 3.3 CVS for Win32

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

Alessandro Pisani wrote:
> 
> As Brian suggested, I'm adapting my fixes for Win32 for the 3.3-CVS version
> of Mesa. I moved all the pragmas to src\glheader.h but there are some
> problems with this: glheader.h is included only by files in /src.
> To avoid LOTS of errors, it must be included also by files in /src/FX,
> /src/X86, --> /src-glu and /src-glut <--, and to files in /3dfx/demos,
> /samples, /book and /demos directories.
> 
> Have we change these sources to make them include src/glheader.h ?

It's OK for any file under the src/ directory to include glheader.h.
Which files need to do this that aren't?

In src-glu/ there's the gluP.h file which I think is included by all
source files.  Put whatever pragmas are needed to cleanly compile
GLU in there.

I'm hesitant to make any new changes to the GLUT tree since I'd like
to replace it at some point with the latest "official" GLUT sources.

Are the samples/, book/, and demos/ programs generating that many
warnings?  I'd think that they'd compile fairly cleanly.


> PS: Brian, I found that the replacement for win32/rules/ files I sent on
> this list some days ago are "buggy" : should I post a fixed version of them
> for mesa 3.2.1 or directly integrate the right version of them in Mesa 3.3
> CVS ?

Both, please.  Just send me the patches.

-Brian

[Mesa3d-dev] Problems fixing Mesa 3.3 CVS for Win32

[Alessandro P. <al...@ti...>]

As Brian suggested, I'm adapting my fixes for Win32 for the 3.3-CVS version 
of Mesa. I moved all the pragmas to src\glheader.h but there are some 
problems with this: glheader.h is included only by files in /src.
To avoid LOTS of errors, it must be included also by files in /src/FX, 
/src/X86, --> /src-glu and /src-glut <--, and to files in /3dfx/demos, 
/samples, /book and /demos directories.

Have we change these sources to make them include src/glheader.h ?

TXM

PS: Brian, I found that the replacement for win32/rules/ files I sent on 
this list some days ago are "buggy" : should I post a fixed version of them 
for mesa 3.2.1 or directly integrate the right version of them in Mesa 3.3 
CVS ?
---
Alessandro Pisani aka TXM - email:al...@ti..., ICQ #2209087
INWO Project Head-programmer - http://www.inwoproject.f2s.com/
Team Isa++ software design coder ----- http://teamisa.cjb.net/

[Mesa3d-dev] Re: [Mesa3d-users] Re: Mesa 3.2 for MS-VC, all the fixes

[Alessandro P. <al...@ti...>]

At 21.22 12/07/00, you wrote:
>In Mesa 3.3 there's a new src/glheader.h file which is meant to be
>the place to put this sort of thing.  It's included by all other source
>files.  You should put your pragmas in that file.
Okay: i'll download the latest Mesa 3.3 CVS and then apply my patches 
according to the new Mesa structure ;)

>I'm really happy you're doing this work.  I just want to be sure it's
>done cleanly.
And i'm happy to do something useful for Mesa :)

TXM

Re: [Mesa3d-users] Re: [Mesa3d-dev] Re: Mesa 3.2 for MS-VC, all the fixes

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

Alessandro Pisani wrote:
> 
> At 19.30 12/07/00, you wrote:
> >Certainly the gl.h header has no business turning off warnings in application
> >programs!  Yikes!
> >
> >This needs to be included into a private Mesa header file.
> Please take a look to the resulting gl.h and the actual gl.h : the actual
> one does YET contains warning turns-off. Moreover, the resulting gl.h does
> not contains these turn-off AT ALL: I moved them in another file.
> So: look-BEFORE-say "Yikes!", please.
> 
> --- cut from GL.H of Mesa 3.2 OFFICIAL (not patched by me) ---
> #if !defined(OPENSTEP) && (defined(__WIN32__) || defined(__CYGWIN32__))
> #  pragma warning( disable : 4068 ) /* unknown pragma */
> #  pragma warning( disable : 4710 ) /* function 'foo' not inlined */
> #  pragma warning( disable : 4711 ) /* function 'foo' selected for
> automatic inline expansion */
> #  pragma warning( disable : 4127 ) /* conditional expression is constant */
> #       if defined(MESA_MINWARN)
> #         pragma warning( disable : 4244 ) /* '=' : conversion from 'const
> double ' to 'float ', possible loss of data */
> #         pragma warning( disable : 4018 ) /* '<' : signed/unsigned mismatch */
> #         pragma warning( disable : 4305 ) /* '=' : truncation from 'const
> double ' to 'float ' */
> #         pragma warning( disable : 4550 ) /* 'function' undefined;
> assuming extern returning int */
> #         pragma warning( disable : 4761 ) /* integral size mismatch in
> argument; conversion supplied */
> #  endif
> #       if defined(_MSC_VER) && defined(BUILD_GL32) /* tag specify we're
> building mesa as a DLL */
> #               define GLAPI __declspec(dllexport)
> #     define WGLAPI __declspec(dllexport)
> --- end cut ---


In 3.2, gl.h was issuing pragmas.  In 3.3 I moved them into the internal
glheader.h file.

-Brian

Re: [Mesa3d-dev] Re: Mesa 3.2 for MS-VC, all the fixes

[Alessandro P. <al...@ti...>]

At 19.30 12/07/00, you wrote:
>Certainly the gl.h header has no business turning off warnings in application
>programs!  Yikes!
>
>This needs to be included into a private Mesa header file.
Please take a look to the resulting gl.h and the actual gl.h : the actual 
one does YET contains warning turns-off. Moreover, the resulting gl.h does 
not contains these turn-off AT ALL: I moved them in another file.
So: look-BEFORE-say "Yikes!", please.

--- cut from GL.H of Mesa 3.2 OFFICIAL (not patched by me) ---
#if !defined(OPENSTEP) && (defined(__WIN32__) || defined(__CYGWIN32__))
#  pragma warning( disable : 4068 ) /* unknown pragma */
#  pragma warning( disable : 4710 ) /* function 'foo' not inlined */
#  pragma warning( disable : 4711 ) /* function 'foo' selected for 
automatic inline expansion */
#  pragma warning( disable : 4127 ) /* conditional expression is constant */
#       if defined(MESA_MINWARN)
#         pragma warning( disable : 4244 ) /* '=' : conversion from 'const 
double ' to 'float ', possible loss of data */
#         pragma warning( disable : 4018 ) /* '<' : signed/unsigned mismatch */
#         pragma warning( disable : 4305 ) /* '=' : truncation from 'const 
double ' to 'float ' */
#         pragma warning( disable : 4550 ) /* 'function' undefined; 
assuming extern returning int */
#         pragma warning( disable : 4761 ) /* integral size mismatch in 
argument; conversion supplied */
#  endif
#       if defined(_MSC_VER) && defined(BUILD_GL32) /* tag specify we're 
building mesa as a DLL */
#               define GLAPI __declspec(dllexport)
#     define WGLAPI __declspec(dllexport)
--- end cut ---

TXM

[Mesa3d-dev] Re: [Mesa3d-users] Re: Mesa 3.2 for MS-VC, all the fixes

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

Alessandro Pisani wrote:
> 
> At 15.42 12/07/00, Brian Paul wrote:
> >I have a few problems with this.
> >
> >1. You introduce a new include/GL/mesawin32.h header.  The headers in
> >    include/GL are meant to be public interfaces.  Your header just has
> >    a bunch of MSVC pragmas for compiling Mesa.  This should probably be
> >    moved to the src/ directory.
> >2. When I tried to apply your patch, many of the patches failed since the
> >latest 3.2 CVS files are different from the released 3.2 distro.
> >Can you download the latest files from CVS and try again?
> >3. It would be best if you used the CVS sources since you could then
> >    test/update Mesa 3.3 which will be released soon.
> 
> Mhh...okay: I'll apply them on the latest Mesa 3.3-CVS... but before this
> we've to find a hack for the problem #1... i think moving mesawin32.h into
> /src is complicated : you also have to put something like:
> 
> #ifdef __WIN32__
>   #include "mesawin32.h"
> #endif
> 
> (note that __WIN32__ is defined in gl.h so this code-fragment must be put
> after include <GL/gl.h> )
> 
> in EACH source-file of these dir: /src, /src/FX, /src/FX/X86, /src/X86,
> /demos, /3dfx/demos, /book  etc, etc...
> Please also note that you have to add the code-fragment above in every new
> file you create in Mesa (this is for future), so I think this is not an
> efficient method... is it?

In Mesa 3.3 there's a new src/glheader.h file which is meant to be
the place to put this sort of thing.  It's included by all other source
files.  You should put your pragmas in that file.


> I don't know enough about the Mesa internal structure to find a better
> solution, but if you find a better method (and I'm sure there's one), I'll
> be happy to test it with MS-VC 6.0 ;)

I'm really happy you're doing this work.  I just want to be sure it's
done cleanly.

-Brian

[Mesa3d-dev] Re: [Mesa3d-users] Re: Mesa 3.2 for MS-VC, all the fixes

[Alessandro P. <al...@ti...>]

At 15.42 12/07/00, Brian Paul wrote:
>I have a few problems with this.
>
>1. You introduce a new include/GL/mesawin32.h header.  The headers in
>    include/GL are meant to be public interfaces.  Your header just has
>    a bunch of MSVC pragmas for compiling Mesa.  This should probably be
>    moved to the src/ directory.
>2. When I tried to apply your patch, many of the patches failed since the 
>latest 3.2 CVS files are different from the released 3.2 distro.
>Can you download the latest files from CVS and try again?
>3. It would be best if you used the CVS sources since you could then
>    test/update Mesa 3.3 which will be released soon.
Mhh...okay: I'll apply them on the latest Mesa 3.3-CVS... but before this 
we've to find a hack for the problem #1... i think moving mesawin32.h into 
/src is complicated : you also have to put something like:

#ifdef __WIN32__
  #include "mesawin32.h"
#endif

(note that __WIN32__ is defined in gl.h so this code-fragment must be put 
after include <GL/gl.h> )

in EACH source-file of these dir: /src, /src/FX, /src/FX/X86, /src/X86, 
/demos, /3dfx/demos, /book  etc, etc...
Please also note that you have to add the code-fragment above in every new 
file you create in Mesa (this is for future), so I think this is not an 
efficient method... is it?

I don't know enough about the Mesa internal structure to find a better 
solution, but if you find a better method (and I'm sure there's one), I'll 
be happy to test it with MS-VC 6.0 ;)

TXM

Re: [Mesa3d-dev] Re: Mesa 3.2 for MS-VC, all the fixes

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

On Wed, 12 Jul 2000, Brian Paul wrote:

> I have a few problems with this.
> 
> 1. You introduce a new include/GL/mesawin32.h header.  The headers in
>    include/GL are meant to be public interfaces.  Your header just has
>    a bunch of MSVC pragmas for compiling Mesa.  This should probably be
>    moved to the src/ directory.
 
Certainly the gl.h header has no business turning off warnings in application
programs!  Yikes!

This needs to be included into a private Mesa header file.

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

[Mesa3d-dev] Re: Mesa 3.2 for MS-VC, all the fixes

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

Alessandro Pisani wrote:
> 
> Okay, i've put togheter all the fixes needed to make Mesa 3.2 work fine
> with MS VC 6.0 . These fixes have 3 (main) goals:
> 1) Avoid lots of compile warnings/errors (about 1.1MB of stdout ... ;)
> 2) Remove a link error during OPENGL32.DLL creation of the 3dfx/Mesa
> 3) Make 3DNOW, MMX, X86 (but also KATMAI for Mesa 3.3) optimizations work
> fine for both the normal and the 3dfx versions of Mesa 3.2
> 
> I've fixed makefiles, rules files and some includes and sources. I've
> slightly modified gl/gl.h : now this includes a new mesawin32.h include
> file if __WIN32__ is detected. mesawin32.h contains the complete list
> (about 25~30 pragmas) of all warning you have to disable in MSVC if you
> don't want to become insane during compiling.
> (Please note that the disabled-warnings have been tested only on MS-VC 6...
> I tried to make the list backward compatible, but I do not know if i
> succeeded : i only have the 6.0 version)
> 
> I've prepared a diff file produced with DIFF 2.7.2 (for DOS) (command line
> used if  diff -uNr dir2/Mesa-3.2 dir1/Mesa-3.2 -- dir2 contained the
> ORIGINAL Mesa 3.2 AND Mesa Demos 3.2, dir1 contained my patched version of
> both Mesa 3.2 and MesaDemos 3.2).
> 
> I applied the patch with PATCH 2.5.4 (for DOS) with the commandline: patch
> -p1 -f < mesa32.diff  to a clean-original Mesa3.2 + MesaDemos3.2,  then
> recompiled all the stuff (static libs, DLLs, Demos, 3dfx demos,
> book-samples, ...) via mesaw32.bat and all works fine for me.
> 
> Note for Brian and Mesa 3.2.1: Brian, I'm sorry for breking you work but
> please apply this patch insted of files I posted some days ago: i made
> other changes on them.


I have a few problems with this.

1. You introduce a new include/GL/mesawin32.h header.  The headers in
   include/GL are meant to be public interfaces.  Your header just has
   a bunch of MSVC pragmas for compiling Mesa.  This should probably be
   moved to the src/ directory.

2. When I tried to apply your patch, many of the patches failed since the
   latest 3.2 CVS files are different from the released 3.2 distro.
   Can you download the latest files from CVS and try again?

3. It would be best if you used the CVS sources since you could then
   test/update Mesa 3.3 which will be released soon.

-Brian

[Mesa3d-dev] Mesa 3.2 for MS-VC, all the fixes

[Alessandro P. <al...@ti...>]

Okay, i've put togheter all the fixes needed to make Mesa 3.2 work fine 
with MS VC 6.0 . These fixes have 3 (main) goals:
1) Avoid lots of compile warnings/errors (about 1.1MB of stdout ... ;)
2) Remove a link error during OPENGL32.DLL creation of the 3dfx/Mesa
3) Make 3DNOW, MMX, X86 (but also KATMAI for Mesa 3.3) optimizations work 
fine for both the normal and the 3dfx versions of Mesa 3.2

I've fixed makefiles, rules files and some includes and sources. I've 
slightly modified gl/gl.h : now this includes a new mesawin32.h include 
file if __WIN32__ is detected. mesawin32.h contains the complete list 
(about 25~30 pragmas) of all warning you have to disable in MSVC if you 
don't want to become insane during compiling.
(Please note that the disabled-warnings have been tested only on MS-VC 6... 
I tried to make the list backward compatible, but I do not know if i 
succeeded : i only have the 6.0 version)

I've prepared a diff file produced with DIFF 2.7.2 (for DOS) (command line 
used if  diff -uNr dir2/Mesa-3.2 dir1/Mesa-3.2 -- dir2 contained the 
ORIGINAL Mesa 3.2 AND Mesa Demos 3.2, dir1 contained my patched version of 
both Mesa 3.2 and MesaDemos 3.2).

I applied the patch with PATCH 2.5.4 (for DOS) with the commandline: patch 
-p1 -f < mesa32.diff  to a clean-original Mesa3.2 + MesaDemos3.2,  then 
recompiled all the stuff (static libs, DLLs, Demos, 3dfx demos, 
book-samples, ...) via mesaw32.bat and all works fine for me.

Note for Brian and Mesa 3.2.1: Brian, I'm sorry for breking you work but 
please apply this patch insted of files I posted some days ago: i made 
other changes on them.

Okay...that's all... and Hope That Helps ;)
Bye,
TXM 

Re: [Mesa3d-dev] setting location of conf files for ggi [patch included]

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

"James A. Treacy" wrote:
> 
> On Mon, Jul 10, 2000 at 04:53:00PM -0600, Brian Paul wrote:
> >
> > Are you sure you made your patch against the latest sources?
> >
> > I had numerous failures when I tried to apply it.
> >
> Sorry, I should have specified that it was against 3.2.
> Hopefully, I made the diff correctly.

I tried applying it to 3.2 but it didn't work.

Perhaps you can verify that it applies on your end.  And if it
does work, send me the patch command.  Maybe I'm missing a flag.

-Brian

Re: [Mesa3d-dev] setting location of conf files for ggi [patch included]

[James A. T. <tr...@de...>]

On Mon, Jul 10, 2000 at 04:53:00PM -0600, Brian Paul wrote:
> 
> Are you sure you made your patch against the latest sources?
> 
> I had numerous failures when I tried to apply it.
> 
Sorry, I should have specified that it was against 3.2.
Hopefully, I made the diff correctly.

-- 
James (Jay) Treacy
tr...@de...

Re: [Mesa3d-dev] setting location of conf files for ggi [patch included]

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

"James A. Treacy" wrote:
> 
> Below is a patch so that the location of the ggi conf files are set from
> autoconf. It only affects the .c files. There are still 3 conf files
> that have hard coded paths in them. Any recommendations on how these
> should be set?

Are you sure you made your patch against the latest sources?

I had numerous failures when I tried to apply it.

Jon Taylor will have to answer the questions about GGI stuff.

-Brian

[Mesa3d-dev] setting location of conf files for ggi [patch included]

[James A. T. <tr...@de...>]

Below is a patch so that the location of the ggi conf files are set from
autoconf. It only affects the .c files. There are still 3 conf files
that have hard coded paths in them. Any recommendations on how these
should be set?

diff -u -r src/GGI.orig/Makefile.am src/GGI/Makefile.am
--- src/GGI.orig/Makefile.am	Sun Jul  9 23:09:41 2000
+++ src/GGI/Makefile.am	Mon Jul 10 16:26:30 2000
@@ -8,6 +8,8 @@
 # Build a libtool convenience library.
 noinst_LTLIBRARIES = libMesaGGI.la
 
+CFLAGS = -DGGIMESACONFFILE=\"/etc/ggi/ggimesa.conf\" @CFLAGS@
+
 libMesaGGI_la_SOURCES = ggimesa.c
 libMesaGGI_la_LIBADD = $(GGI_LIBS)
 
diff -u -r src/GGI.orig/default/Makefile.am src/GGI/default/Makefile.am
--- src/GGI.orig/default/Makefile.am	Mon Jul 10 16:33:58 2000
+++ src/GGI/default/Makefile.am	Mon Jul 10 16:34:29 2000
@@ -13,7 +13,7 @@
 sublib_LTLIBRARIES = stubs.la linear_8.la linear_15.la \
 	linear_16.la linear_24.la linear_32.la $(KGILIB)
 
-
+CFLAGS = -DGGIMESACONFFILE=\"/etc/ggi/ggimesa.conf\" @CFLAGS@
 
 genkgi_la_SOURCES = genkgi_visual.c genkgi_mode.c
 genkgi_la_LDFLAGS = -module -no-undefined -avoid-verison \
diff -u -r src/GGI.orig/default/genkgi_visual.c src/GGI/default/genkgi_visual.c
--- src/GGI.orig/default/genkgi_visual.c	Mon Jul 10 16:27:17 2000
+++ src/GGI/default/genkgi_visual.c	Mon Jul 10 14:19:16 2000
@@ -67,7 +67,9 @@
 #define NUM_ACCELS	(sizeof(accel_strings)/sizeof(accel_info))
 
 /* FIXME: These should be defined in the makefile system */
+#ifndef CONF_FILE
 #define CONF_FILE "/usr/local/etc/ggi/mesa/targets/genkgi.conf"
+#endif
 void *_configHandle;
 char confstub[512] = CONF_FILE;
 char *conffile = confstub;
diff -u -r src/GGI.orig/display/Makefile.am src/GGI/display/Makefile.am
--- src/GGI.orig/display/Makefile.am	Mon Jul 10 16:34:09 2000
+++ src/GGI/display/Makefile.am	Mon Jul 10 16:34:39 2000
@@ -10,6 +10,8 @@
 fbdev_la_LDFLAGS = -module -no-undefined -avoid-verison \
 	-export-symbols-regex "GGIdl.*"
 
+CFLAGS = -DGGIMESACONFFILE=\"/etc/ggi/ggimesa.conf\" @CFLAGS@
+	
 fbdevconfdir = $(sysconfdir)/ggi/mesa/targets
 fbdevconf_DATA = fbdev.conf
 	
diff -u -r src/GGI.orig/display/fbdev_visual.c src/GGI/display/fbdev_visual.c
--- src/GGI.orig/display/fbdev_visual.c	Mon Jul 10 16:28:22 2000
+++ src/GGI/display/fbdev_visual.c	Mon Jul 10 14:20:04 2000
@@ -67,7 +67,9 @@
 #define NUM_ACCELS	(sizeof(accel_strings)/sizeof(accel_info))
 
 /* FIXME: These should really be defined in the make system */
+#ifndef CONF_FILE
 #define CONF_FILE "/usr/local/etc/ggi/mesa/targets/fbdev.conf"
+#endif
 void *_configHandle;
 char confstub[512] = CONF_FILE;
 char *conffile = confstub;
diff -u -r src/GGI.orig/ggimesa.c src/GGI/ggimesa.c
--- src/GGI.orig/ggimesa.c	Fri Jul  7 16:35:37 2000
+++ src/GGI/ggimesa.c	Sun Jul  9 23:35:38 2000
@@ -42,7 +42,9 @@
 static void *_ggimesaConfigHandle;
 
 /* FIXME: These should really be defined in the make system using -Dxxx */
+#ifndef GGIMESACONFFILE
 #define GGIMESACONFFILE "/usr/local/etc/ggi/ggimesa.conf"
+#endif
 #define GGIMESATAGLEN 0
 static char ggimesaconfstub[512] = GGIMESACONFFILE;
 static char *ggimesaconffile = ggimesaconfstub + GGIMESATAGLEN;

-- 
James (Jay) Treacy
tr...@de...

[Mesa3d-dev] Re: [Mesa3d-users] Mesa3.2/Win32-3dfx issue --FIXED--

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

Alessandro Pisani wrote:
> 
> Preliminar note: this patch is against Mesa 3.2-final
> Okay, i've fixed the bi**h : now it works fine ;)
> Thanks to Eero Pajarre for helping me understand what was wrong :)
> 
> The attached file will replace these files:
> win32\nmake.mak
> win32\nmake.mif
> win32\rules\lib.fxmesa
> win32\rulelib.fxmesa32
> 
> With these changes you will be able to recompile Mesa+3dfx from mesae32.bat
> or nmake /f win32\nmake.mak without receiving "unresolved external" errors.
> 
> I tested the new files with my MS-VC 6.0, enabling ALL optimizations (asm
> x86, mmx, 3dnow) and all of them now work ;)
> Note: for some strange reason i can't understand, NASM 0.98 does not want a
> NASM variabile is set in the environment WHEN called from win32/nmake.mak
> (that's strange 'cos the same thing doesn't happen with makefile.fx), so i
> changed the NASM variable in all the files above to USENASM.
> 
> (if you try to compile mesa+3dfx from win32/nmake.mak with NASM=whatever,
> you will receive an error like "more than one input file specified"... it
> seems like NASM read the env-variable NASM and uses "whatever" as first
> input-file value.... ?!?)
> 
> More patches for MSVC6 are under testing ... ;)
> Hope that helps,
> TXM
> 
> PS: the file attached is intended to be unzipped in the mesa root dir.

Done. I've checked in the new changes to the Mesa 3.2 branch.  They'll
be in the 3.2.1 release which I hope to finish this week.

-Brian

[Mesa3d-dev] CVS logging should be working

[Keith W. <ke...@va...>]

Please subscribe to mesa3d-cvs to receive timely notifications of commits by
the developers.

Let me know if you have any problems...

Keith

[Mesa3d-dev] Mesa3.2/Win32-3dfx issue --FIXED--

[Alessandro P. <al...@ti...>]

Preliminar note: this patch is against Mesa 3.2-final
Okay, i've fixed the bi**h : now it works fine ;)
Thanks to Eero Pajarre for helping me understand what was wrong :)

The attached file will replace these files:
win32\nmake.mak
win32\nmake.mif
win32\rules\lib.fxmesa
win32\rulelib.fxmesa32

With these changes you will be able to recompile Mesa+3dfx from mesae32.bat 
or nmake /f win32\nmake.mak without receiving "unresolved external" errors.

I tested the new files with my MS-VC 6.0, enabling ALL optimizations (asm 
x86, mmx, 3dnow) and all of them now work ;)
Note: for some strange reason i can't understand, NASM 0.98 does not want a 
NASM variabile is set in the environment WHEN called from win32/nmake.mak 
(that's strange 'cos the same thing doesn't happen with makefile.fx), so i 
changed the NASM variable in all the files above to USENASM.

(if you try to compile mesa+3dfx from win32/nmake.mak with NASM=whatever, 
you will receive an error like "more than one input file specified"... it 
seems like NASM read the env-variable NASM and uses "whatever" as first 
input-file value.... ?!?)

More patches for MSVC6 are under testing ... ;)
Hope that helps,
TXM

PS: the file attached is intended to be unzipped in the mesa root dir.

Re: [Mesa3d-dev] on highly dynamic textures (ie: movies and similar)

[Allen A. <ak...@po...>]

On Thu, Jul 06, 2000 at 07:03:54PM -0400, winterlion wrote:
| Is there a method for either making small updates to an OpenGL texture...

Will glTexSubImage2D() do what you want?

Allen

[Mesa3d-dev] on highly dynamic textures (ie: movies and similar)

[winterlion <win...@fs...>]

Is there a method for either making small updates to an OpenGL texture or
making a block of videomemory writable by a program?

on small updates to a texture:
actually AFAIK this is possible - but all tests I've done so far
failed..  mind you I couldn't find documentation so...

Primary uses:
	Movies on a texture
	Applications on an X-emu on a texture

Now this might be a nonissue (ie: like I said I have a lack of
documentation :) or something not applicable to the developer side...  but
while applications on a texture can be relatively efficient, playing a
movie when every frame has to be uploaded is a little costly.
(okay, with a 3D accel such as the 3dfx/banshee I have it still happens)

Thanks in advance for any ideas :)
(and please tell me if I'm out to lunch - or if even anyone's getting any
of my message..  My last one on 3dfx-accel using mesa on glide2x without X 
didn't get an answer....)

G'day, eh? :)
	- Teunis

PS: one would think there exists a formal extension to describe such a
circumstance :)

-- 
Trying to bring truth from beauty is Winterlion.
find at this <a href="http://www.geocities.com/winterlion">winterlions' page</a>

Re: [Mesa3d-dev] Proxy texture problems in 3.3?

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

That solved the problem.

Brian Paul wrote:
> 
> Scott McMillan wrote:
> >
> > Has anyone else noticed problems with proxy texture tests failing
> > in recent versions of 3.3?  I have them failing on relatively small
> > (64x64) ones whereas in 3.2 the test passed (or at least seemed to).
> > I will try and come up with a small test case, but it may take me
> > a while.
> 
> I fixed a bug in this just last week.  The proxy texture test was
> always updating the 1D texture instead of the appropriate 1D, 2D or
> 3D texture.
> 
> Try the latest CVS sources.

-- 
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] Proxy texture problems in 3.3?

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

Scott McMillan wrote:
> 
> Has anyone else noticed problems with proxy texture tests failing
> in recent versions of 3.3?  I have them failing on relatively small
> (64x64) ones whereas in 3.2 the test passed (or at least seemed to).
> I will try and come up with a small test case, but it may take me
> a while.

I fixed a bug in this just last week.  The proxy texture test was
always updating the 1D texture instead of the appropriate 1D, 2D or
3D texture.

Try the latest CVS sources.

-Brian

Re: [Mesa3d-dev] glReadPixels

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

Steve Baker wrote:
> 
> On Mon, 3 Jul 2000, Michael Vance wrote:
> 
> > Yep, it's in the blue book. Create texture of width and height with
> > unspecified contents. Mesa sticks a big old piece of 'MESA' text in it
> > :)
> 
> Boring!  It should have been Brian Paul's cat/dog/kid!
> 
>    :-)

That was my modest attempt at putting an "Easter Egg" in Mesa.
I've told a few people about it over the years but no one else
has ever said "Hey, I found this!".

-Brian


PS: I don't have a cat, dog or kid.