mesa3d-dev

Re: [ogl-sample] Re: [Mesa3d-dev] GLU rpm available from SGI sample implementation

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

Olivier Michel wrote:
> 
> Brian Paul wrote:
> 
> > Olivier Michel wrote:
> > >
> > > Good news!
> > >
> > > The SGI sample implementation CVS was updated this week-end with many
> > > minor bug fixes that make it now possible to build a GLU rpm directly
> > > from the SGI CVS tree that works fine with Mesa.
> > >
> > > I built it yesterday night for ppc and i386. The name of the files
> > > I created are:
> > >
> > > oss-opengl-glu.spec (1.6 KB) -> my RPM spec file
> > > ogl-sample.20000925.tgz (1.7 MB) -> the source from the CVS tree
> > > oss-opengl-glu-20000925-1.i386.rpm (212 KB) -> binary package for i386
> > > oss-opengl-glu-20000925-1.ppc.rpm (242 KB) -> binary package for ppc
> >
> > Is the /usr/include/GL/glu.h header included in the binary RPM?
> 
> Yes. By the way I put it in /usr/include/GL but I discovered that some recent
> Mesa-devel packages put the include files in /usr/X11R6/include/GL and the
> libraries in /usr/X11R6/lib/. My package defaults to /usr/include/GL for the
> includes and /usr/lib for the lib. However, it is relocatable that is users
> can install it in /usr/X11R6 by typing rpm -Uvh --prefix=/usr/X11R6
> package.rpm. But the question is: What is the standard localtion for Mesa
> include and libraries, /usr or /usr/X11R6 ?

The OpenGL/Linux ABI spec calls for using /usr/include/GL and /usr/lib.
See http://oss.sgi.com/projects/ogl-sample/ABI/

XFree86 4.0.1 and later build and install the headers and libs under
/usr/X11R6 but also make symlinks from /usr/include and /usr/lib to
satisfy the ABI spec.


> > Is there also a gluext.h file?
> 
> No. Nothing looking like this is produced by SGI sample OpenGL...

OK.


> > > the process for building the rpm is very easy:
> > >
> > > 1) copy the oss-opengl-glu.spec in the rpm SPECS directory
> > > 2) copy the ogl-sample.20000925.tgz in the rpm SOURCES directory
> > > 3) cd to the SPECS directory and type rpm -bb oss-opengl-glu.spec (bb
> > > stands for build binary)
> > > 4) you get the binary package in the rpm RPMS/i386 or RPMS/ppc directory
> > >
> > > Unfortunatelly, I have no room to host these files online, but I would
> > > be a pleasure for me to upload them anywhere, so that they are available
> > > to anyone.
> >
> > I could put them on the Mesa site.  Ideally, they should also be on
> > SGI's site.
> 
> Ok, thanks. How to we proceed ? Shall I upload it somewhere or send it to you
> as an e-mail attachment ?

Send them by email and I'll put them on the Mesa site.


> > > By the way, my spec file could be included into the CVS tree of the
> > > ogl-sample ?
> > >
> > > I also have the same set of files to build a Mesa rpm package without
> > > Mesa GLU (to use the GLU from the above package).
> > >
> > > Let me know if anyone can host my files.
> > > Thanks!
> >
> > -Brian
> 
> -Olivier

-Brian

Re: [ogl-sample] Re: [Mesa3d-dev] GLU rpm available from SGI sample implementation

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

On Wed, Sep 27, 2000 at 10:38:17AM +0200, Olivier Michel wrote:
> Brian Paul wrote:
> > Is the /usr/include/GL/glu.h header included in the binary RPM?
> 
> Yes. By the way I put it in /usr/include/GL but I discovered that some recent
> Mesa-devel packages put the include files in /usr/X11R6/include/GL and the
> libraries in /usr/X11R6/lib/. My package defaults to /usr/include/GL for the
> includes and /usr/lib for the lib. However, it is relocatable that is users
> can install it in /usr/X11R6 by typing rpm -Uvh --prefix=/usr/X11R6
> package.rpm. But the question is: What is the standard localtion for Mesa
> include and libraries, /usr or /usr/X11R6 ?
> 
IMO, the mesa libs should use /usr/include and /usr/lib. My reasoning
is that /usr/X11R6 is for X only programs and mesa can be used to
render directly to a file.

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

Re: [ogl-sample] Re: [Mesa3d-dev] GLU rpm available from SGI sample implementation

[Olivier M. <Oli...@cy...>]

Brian Paul wrote:

> Olivier Michel wrote:
> >
> > Good news!
> >
> > The SGI sample implementation CVS was updated this week-end with many
> > minor bug fixes that make it now possible to build a GLU rpm directly
> > from the SGI CVS tree that works fine with Mesa.
> >
> > I built it yesterday night for ppc and i386. The name of the files
> > I created are:
> >
> > oss-opengl-glu.spec (1.6 KB) -> my RPM spec file
> > ogl-sample.20000925.tgz (1.7 MB) -> the source from the CVS tree
> > oss-opengl-glu-20000925-1.i386.rpm (212 KB) -> binary package for i386
> > oss-opengl-glu-20000925-1.ppc.rpm (242 KB) -> binary package for ppc
>
> Is the /usr/include/GL/glu.h header included in the binary RPM?

Yes. By the way I put it in /usr/include/GL but I discovered that some recent
Mesa-devel packages put the include files in /usr/X11R6/include/GL and the
libraries in /usr/X11R6/lib/. My package defaults to /usr/include/GL for the
includes and /usr/lib for the lib. However, it is relocatable that is users
can install it in /usr/X11R6 by typing rpm -Uvh --prefix=/usr/X11R6
package.rpm. But the question is: What is the standard localtion for Mesa
include and libraries, /usr or /usr/X11R6 ?

> Is there also a gluext.h file?

No. Nothing looking like this is produced by SGI sample OpenGL...

> > the process for building the rpm is very easy:
> >
> > 1) copy the oss-opengl-glu.spec in the rpm SPECS directory
> > 2) copy the ogl-sample.20000925.tgz in the rpm SOURCES directory
> > 3) cd to the SPECS directory and type rpm -bb oss-opengl-glu.spec (bb
> > stands for build binary)
> > 4) you get the binary package in the rpm RPMS/i386 or RPMS/ppc directory
> >
> > Unfortunatelly, I have no room to host these files online, but I would
> > be a pleasure for me to upload them anywhere, so that they are available
> > to anyone.
>
> I could put them on the Mesa site.  Ideally, they should also be on
> SGI's site.

Ok, thanks. How to we proceed ? Shall I upload it somewhere or send it to you
as an e-mail attachment ?

> > By the way, my spec file could be included into the CVS tree of the
> > ogl-sample ?
> >
> > I also have the same set of files to build a Mesa rpm package without
> > Mesa GLU (to use the GLU from the above package).
> >
> > Let me know if anyone can host my files.
> > Thanks!
>
> -Brian

-Olivier

Re: [Mesa3d-dev] GLU rpm available from SGI sample implementation

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

Olivier Michel wrote:
> 
> Good news!
> 
> The SGI sample implementation CVS was updated this week-end with many
> minor bug fixes that make it now possible to build a GLU rpm directly
> from the SGI CVS tree that works fine with Mesa.
> 
> I built it yesterday night for ppc and i386. The name of the files
> I created are:
> 
> oss-opengl-glu.spec (1.6 KB) -> my RPM spec file
> ogl-sample.20000925.tgz (1.7 MB) -> the source from the CVS tree
> oss-opengl-glu-20000925-1.i386.rpm (212 KB) -> binary package for i386
> oss-opengl-glu-20000925-1.ppc.rpm (242 KB) -> binary package for ppc

Is the /usr/include/GL/glu.h header included in the binary RPM?
Is there also a gluext.h file?


> the process for building the rpm is very easy:
> 
> 1) copy the oss-opengl-glu.spec in the rpm SPECS directory
> 2) copy the ogl-sample.20000925.tgz in the rpm SOURCES directory
> 3) cd to the SPECS directory and type rpm -bb oss-opengl-glu.spec (bb
> stands for build binary)
> 4) you get the binary package in the rpm RPMS/i386 or RPMS/ppc directory
> 
> Unfortunatelly, I have no room to host these files online, but I would
> be a pleasure for me to upload them anywhere, so that they are available
> to anyone.

I could put them on the Mesa site.  Ideally, they should also be on
SGI's site.


> By the way, my spec file could be included into the CVS tree of the
> ogl-sample ?
> 
> I also have the same set of files to build a Mesa rpm package without
> Mesa GLU (to use the GLU from the above package).
> 
> Let me know if anyone can host my files.
> Thanks!


-Brian

[Mesa3d-dev] GLU rpm available from SGI sample implementation

[Olivier M. <Oli...@cy...>]

Good news!

The SGI sample implementation CVS was updated this week-end with many
minor bug fixes that make it now possible to build a GLU rpm directly
from the SGI CVS tree that works fine with Mesa.

I built it yesterday night for ppc and i386. The name of the files
I created are:

oss-opengl-glu.spec (1.6 KB) -> my RPM spec file
ogl-sample.20000925.tgz (1.7 MB) -> the source from the CVS tree
oss-opengl-glu-20000925-1.i386.rpm (212 KB) -> binary package for i386
oss-opengl-glu-20000925-1.ppc.rpm (242 KB) -> binary package for ppc

the process for building the rpm is very easy:

1) copy the oss-opengl-glu.spec in the rpm SPECS directory
2) copy the ogl-sample.20000925.tgz in the rpm SOURCES directory
3) cd to the SPECS directory and type rpm -bb oss-opengl-glu.spec (bb
stands for build binary)
4) you get the binary package in the rpm RPMS/i386 or RPMS/ppc directory

Unfortunatelly, I have no room to host these files online, but I would
be a pleasure for me to upload them anywhere, so that they are available
to anyone.

By the way, my spec file could be included into the CVS tree of the
ogl-sample ?

I also have the same set of files to build a Mesa rpm package without
Mesa GLU (to use the GLU from the above package).

Let me know if anyone can host my files.
Thanks!

-Olivier

Re: [Mesa3d-dev] Re: [Dri-devel] Who is working on Texture Compression (other than me?)

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

Ian D Romanick wrote:
> 
> > Who is working on texture compression in Mesa?  I have an implementation
> > of the ARB extension (mostly done by Brian Paul) and an implementation of
> > the GL_3DFX_texture_compression_FXT1 extension.  These are in the
> > tdfx-2-1-branch branch of the DRI tree.
> 
> Is this extension going to only be supported on 3dfx hardware or will there
> be a software fallback?  It sure would be nice to make sure that one's code
> works right with the FXT1 textures without having to go out and buy a Voodoo
> 4/5/6.  The same could also be done with S3TC format textures, I suppose.
> 
> If this is not work that is currently planned, could someone perhaps provide
> some guidance for others that might want to try and tackle this?

We're not doing a software implementation of texture compression.  It would
be impractical.

-Brian

Re: [Mesa3d-dev] Re: [Dri-devel] Who is working on Texture Compression (other than me?)

[Bill W. <bil...@gr...>]

I don't think it is possible or sensible to create a SW fallback,
especially for testing porpoises.  Unless you test with the real
HW, you won't know if it will work on the real HW.  Only 3Dfx
implements FXT1 as far as I know.

Certainly I don't plan to do anything with it unless I can think
of how it might be useful.

[Mesa3d-dev] Re: [Dri-devel] Who is working on Texture Compression (other than me?)

[Ian D R. <id...@cs...>]

> > Is this extension going to only be supported on 3dfx hardware or will there
> > be a software fallback?  It sure would be nice to make sure that one's code
> > works right with the FXT1 textures without having to go out and buy a Voodoo
> > 4/5/6.  The same could also be done with S3TC format textures, I suppose.
> 
> I don't think there are plans for software fallbacks, but in reality you
> are much better off using non-compressed textures than using software
> fallbacks. What really happens is that other drivers that don't
> implement the feature don't advertise and it and the application doesn't
> use it. 

Well, it could be useful so that a person could write and test code that
uses that extension without having to have hardware the explicitly supports
it.  I for one don't have the extra $$$ just sitting around to go out and
buy a Voodoo5, but I'd really like for my code to correctly support its
texture compression extensions.

> I am not a lawyer, but from what I understand FXT1 can be implemented in
> software, because 3dfx made it open source and even provided code to do
> so. S3TC is very heavily protected and I wouldn't want to go near it for
> a software implementation for fear of legal issues.

You are probably right there.  It could possibly go either way, but I'd
rather not press my luck. :)

-- 
"The [300MHz P-II computer] is clearly not optimized for word processing.
 But when we pushed it to produce high-end 3D graphics, it truly shined."
                            -- Byte, Sept 97, pp. 33
What the hell does it take to do word processing?  http://www.cs.pdx.edu/~idr/

[Mesa3d-dev] Re: [Dri-devel] Who is working on Texture Compression (other than me?)

[Daryll S. <da...@va...>]

On Fri, Sep 22, 2000 at 09:10:24AM -0700, Ian D Romanick wrote:
> Is this extension going to only be supported on 3dfx hardware or will there
> be a software fallback?  It sure would be nice to make sure that one's code
> works right with the FXT1 textures without having to go out and buy a Voodoo
> 4/5/6.  The same could also be done with S3TC format textures, I suppose.

I don't think there are plans for software fallbacks, but in reality you
are much better off using non-compressed textures than using software
fallbacks. What really happens is that other drivers that don't
implement the feature don't advertise and it and the application doesn't
use it. 

I am not a lawyer, but from what I understand FXT1 can be implemented in
software, because 3dfx made it open source and even provided code to do
so. S3TC is very heavily protected and I wouldn't want to go near it for
a software implementation for fear of legal issues.

> If this is not work that is currently planned, could someone perhaps provide
> some guidance for others that might want to try and tackle this?

Guidance: FXT1 should be portable, but isn't useful unless the hardware
you're using supports FXT1. S3TC is supported on lots of hardware, but
due to legal restraints I wouldn't go near it.

						- |Daryll

[Mesa3d-dev] Re: [Dri-devel] Who is working on Texture Compression (other than me?)

[Ian D R. <id...@cs...>]

> Who is working on texture compression in Mesa?  I have an implementation
> of the ARB extension (mostly done by Brian Paul) and an implementation of
> the GL_3DFX_texture_compression_FXT1 extension.  These are in the 
> tdfx-2-1-branch branch of the DRI tree.

Is this extension going to only be supported on 3dfx hardware or will there
be a software fallback?  It sure would be nice to make sure that one's code
works right with the FXT1 textures without having to go out and buy a Voodoo
4/5/6.  The same could also be done with S3TC format textures, I suppose.

If this is not work that is currently planned, could someone perhaps provide
some guidance for others that might want to try and tackle this?

-- 
"You must understand...that there are two ways of fighting: by
 law or by force.  The first way is natural to man, and the 
 second to beasts.  But as the first way often proves inadequate
 one must have recourse in the second."  -- Machiavelli, The Prince

Re: [Mesa3d-dev] Who is working on Texture Compression (other than me?)

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

Bill White wrote:
> 
> Who is working on texture compression in Mesa?  I have an implementation
> of the ARB extension (mostly done by Brian Paul) and an implementation of
> the GL_3DFX_texture_compression_FXT1 extension.  These are in the
> tdfx-2-1-branch
> branch of the DRI tree.
> 
> If someone else is working on this, and depends on the implementation, please
> let me know.  For something I am working on, the driver interface needs to
> change.  In particular, there is a routine which calculates the specific
> texture compression format given a generic one.  For example, given
> GL_COMPRESSED_RGB_ARB, the routine might return GL_COMPRESSED_RGB_FXT1_3DFX.
> This routine needs to have more parameters to support some more compressed
> texture formats.
> 
> Please let me know if you are working in this area, and I can give you
> more details.  They are generally pretty harmless, and I think they are
> backward compatible, though I have not tested for this.

You and I are the only ones who've touched that code.  Go ahead and make
your changes.

-Brian

[Mesa3d-dev] Who is working on Texture Compression (other than me?)

[Bill W. <bil...@gr...>]

Who is working on texture compression in Mesa?  I have an implementation
of the ARB extension (mostly done by Brian Paul) and an implementation of
the GL_3DFX_texture_compression_FXT1 extension.  These are in the 
tdfx-2-1-branch
branch of the DRI tree.

If someone else is working on this, and depends on the implementation, please
let me know.  For something I am working on, the driver interface needs to
change.  In particular, there is a routine which calculates the specific
texture compression format given a generic one.  For example, given
GL_COMPRESSED_RGB_ARB, the routine might return GL_COMPRESSED_RGB_FXT1_3DFX.
This routine needs to have more parameters to support some more compressed
texture formats.

Please let me know if you are working in this area, and I can give you
more details.  They are generally pretty harmless, and I think they are
backward compatible, though I have not tested for this.

Re: [Mesa3d-dev] CVS problem

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

Hi All,

I just got a mail from sourceforge telling me the problem (described below)
was fixed.

               Jouk
>br...@va... wrote on  18-SEP-2000 21:47:19.96
>>"Jacob (=Jouk) Jansen" wrote:
>>> 
>>> Hi
>>> 
>>> Something seems to be wrong with the CVS.
>>> This morning I got:
>>> 
>>> sm43-jj) cvsmesa checkout Mesa
>>> jo...@cv...'s password:
>>> cvs server: Updating Mesa
>>> U Mesa/.cvsignore
>>> cvs [checkout aborted]: writing Mesa/Make-config: No such file or directory
>>> sm43-jj) Write failed flushing stdout buffer.
>>> write stdout: Broken pipe
>>> 
>>> What is wrong?
>>
>>Try again later.  If the problem persists, file a problem report on
>>SourceForge.
>
>The problem persists and has to do with the acual file Make-config. If I start
>in a fresh directory with a "new" checkout. All files before this one are OK
>but it fails with Make-config. I will report the problem to sourceforge
>tomorrow, since presently I'm at home with limited resources.
>
>               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

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

Re: [Mesa3d-dev] GL_EXT_vertex_weighting

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

Li Ming wrote:
> 
> Hi,
> 
> But maybe the Vertex Program(also called Vertex shader) is a more
> general and uniform way to do such things. It even can do much more
> than the vertex weighting.
> 
> However, it seems that to implement the vertex program extension is a
> hard work because it modifies the traditional pipelines and involves
> transformation, lighting, fog, clipping etc.
> 
> By the way, the specification has been already released by Nvidia on
> their web page.

Read the "IP Status" section.  I don't think anyone outside of
NVIDIA can implement the extension without their permission.

-Brian

Re: [Mesa3d-dev] GL_EXT_vertex_weighting

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

Li Ming wrote:
> 
> But maybe the Vertex Program(also called Vertex shader) is a more
> general and uniform way to do such things. It even can do much more
> than the vertex weighting.
> 
> However, it seems that to implement the vertex program extension is a
> hard work because it modifies the traditional pipelines and involves
> transformation, lighting, fog, clipping etc.
> 
> By the way, the specification has been already released by Nvidia on
> their web page.

Yes, and it's NVIDIA proprietary, which means you can't implement it. 
And, the spec is ~75 pages long.  Perhaps a little ambitious for a
school project...

-- Gareth

Re: [Mesa3d-dev] GL_EXT_vertex_weighting

[Li M. <mi...@mp...>]

Hi,

But maybe the Vertex Program(also called Vertex shader) is a more
general and uniform way to do such things. It even can do much more
than the vertex weighting.

However, it seems that to implement the vertex program extension is a
hard work because it modifies the traditional pipelines and involves
transformation, lighting, fog, clipping etc.

By the way, the specification has been already released by Nvidia on
their web page.

Li Ming.


Karsten Weiss wrote:

> Hi!
>
> Is anybody working on a GL_EXT_vertex_weighting implementation
> for Mesa? Last time I checked this extension was still
> unsupported.
>
> I'm currently looking for an interesting university project and
> would like to do something useful and was considering doing
> this implementation (together with a little demo).
>
> Any comments?
>
> bye,
>   Karsten
>
> --
> Karsten Weiss   | kn...@gm... (private) or
> ASK FOR PGP KEY | kn...@ru... (university)
>
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> http://lists.sourceforge.net/mailman/listinfo/mesa3d-dev

Re: [Mesa3d-dev] CVS problem

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

br...@va... wrote on  18-SEP-2000 21:47:19.96
>"Jacob (=Jouk) Jansen" wrote:
>> 
>> Hi
>> 
>> Something seems to be wrong with the CVS.
>> This morning I got:
>> 
>> sm43-jj) cvsmesa checkout Mesa
>> jo...@cv...'s password:
>> cvs server: Updating Mesa
>> U Mesa/.cvsignore
>> cvs [checkout aborted]: writing Mesa/Make-config: No such file or directory
>> sm43-jj) Write failed flushing stdout buffer.
>> write stdout: Broken pipe
>> 
>> What is wrong?
>
>Try again later.  If the problem persists, file a problem report on
>SourceForge.

The problem persists and has to do with the acual file Make-config. If I start
in a fresh directory with a "new" checkout. All files before this one are OK
but it fails with Make-config. I will report the problem to sourceforge
tomorrow, since presently I'm at home with limited resources.

               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

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

Re: [Mesa3d-dev] CVS problem

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

On Mon, 18 Sep 2000, Brian Paul wrote:

> > Something seems to be wrong with the CVS.
> > This morning I got:
> > 
> > sm43-jj) cvsmesa checkout Mesa
> > jo...@cv...'s password:
> > cvs server: Updating Mesa
> > U Mesa/.cvsignore
> > cvs [checkout aborted]: writing Mesa/Make-config: No such file or directory
> > sm43-jj) Write failed flushing stdout buffer.
> > write stdout: Broken pipe
> > 
> > What is wrong?
> 
> Try again later.  If the problem persists, file a problem report on
> SourceForge.
 
Sourceforge did some major reorganization over the weekend - and the
service was actually unavailable 10pm Saturday night through to
8am Sunday Morning (US Pacific time) - perhaps that had something
to do with it.

----
Science being insufficient - neither ancient protein species deficient.

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] CVS problem

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

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi
> 
> Something seems to be wrong with the CVS.
> This morning I got:
> 
> sm43-jj) cvsmesa checkout Mesa
> jo...@cv...'s password:
> cvs server: Updating Mesa
> U Mesa/.cvsignore
> cvs [checkout aborted]: writing Mesa/Make-config: No such file or directory
> sm43-jj) Write failed flushing stdout buffer.
> write stdout: Broken pipe
> 
> What is wrong?

Try again later.  If the problem persists, file a problem report on
SourceForge.

-Brian

[Mesa3d-dev] CVS problem

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

Hi 

Something seems to be wrong with the CVS.
This morning I got:

sm43-jj) cvsmesa checkout Mesa
jo...@cv...'s password:
cvs server: Updating Mesa
U Mesa/.cvsignore
cvs [checkout aborted]: writing Mesa/Make-config: No such file or directory
sm43-jj) Write failed flushing stdout buffer.
write stdout: Broken pipe


What is wrong?

      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

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

Re: [Mesa3d-dev] GL_EXT_vertex_weighting

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

Karsten Weiss wrote:
> 
> Hi!
> 
> Is anybody working on a GL_EXT_vertex_weighting implementation
> for Mesa? Last time I checked this extension was still
> unsupported.

No one is implementing it in Mesa.


> I'm currently looking for an interesting university project and
> would like to do something useful and was considering doing
> this implementation (together with a little demo).
> 
> Any comments?

This could be a very compilicated extension to implement.
I'd try to find something easier to do for a school project.

BTW, there may be an official ARB version of this extension in
the near future.

-Brian

[Mesa3d-dev] GL_EXT_vertex_weighting

[Karsten W. <kn...@gm...>]

Hi!

Is anybody working on a GL_EXT_vertex_weighting implementation
for Mesa? Last time I checked this extension was still
unsupported.

I'm currently looking for an interesting university project and
would like to do something useful and was considering doing
this implementation (together with a little demo).

Any comments?

bye,
  Karsten

-- 
Karsten Weiss   | kn...@gm... (private) or
ASK FOR PGP KEY | kn...@ru... (university)

Re: [Mesa3d-dev] ARB_texture_compression

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

Michael Vance wrote:
> 
> Brian,
> 
> As a heads up, the official ARB_texture_compression standard
> (http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt)
> defines the internalFormat parameter of CompressedTexImage* to be
> 'int' and not 'enum'. I would think 'enum' is more appropriate, but
> there it is all the same. A good C++ compiler will complain about
> this.

Hmmm, the spec says internalFormat should be a GLint but SGI's
glext.h file has GLenum.  Also, the gl.spec file (which is used
to generate glext.h and other files) uses the PixelInternalFormat
type which in all other functions maps to GLenum.

Looks like an inconsistency in the gl.spec file.  I'll contact SGI.

-Brian

[Mesa3d-dev] ARB_texture_compression

[Michael V. <bri...@lo...>]

Brian,

As a heads up, the official ARB_texture_compression standard
(http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt)
defines the internalFormat parameter of CompressedTexImage* to be
'int' and not 'enum'. I would think 'enum' is more appropriate, but
there it is all the same. A good C++ compiler will complain about
this.

m.

-- 
Programmer             "Ha ha." "Ha ha." "What are you laughing at?"
Loki Software                      "Just the horror of being alive."
http://lokigames.com/~briareos/                   - Tony Millionaire

[Mesa3d-dev] Mesa3D port to Windows CE

[ron s. <ro...@mi...>]

I am exploring the possibilities of porting Mesa3D to Windows CE. Does
anyone know if there has been a port already or some of the issues involved?


Thanks,

-Ron