"Jacob (=Jouk) Jansen" wrote:
>
> Hi all,
>
> I did not get any answers to my last posts over the last weeks concerning
> an initialization problem on VMS systems and my proposed solution. (the trafic
> on Mesa3d-dev is very low last weeks anyway). So
> -Is nobody (except me) getting my mails
Just a reminder, I'll soon be shutting down the Mesa lists hosted
at mesa3d.org. The new lists are hosted on sourceforge.net
I see that a lot of people on this list haven't yet subscribed to
the new developers list on SourceForge. To subscribe to it, visit
http://sourceforge.net/mail/?group_id
physic wrote:
>
> Hey Brian, I just wanted to point out that you should probably rerun
> the sgi opengl conformance suite before you release 3.2.
Yup. I already did over the weekend. Same results as for 3.1.
-Brian
___
Mesa-dev maillist - [EMAIL
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> I was wondering if anybody is experiencing an 'illegal instruction' error when using
>gluBuild2DMipmap() functions with Mesa 3.1/3.2 on Linux?
>
> I've double checked the code and it looks fine. It also works on other
>implementations of OpenGL (Sun, and M
Kendall Bennett wrote:
>
> Brian Paul <[EMAIL PROTECTED]> wrote:
>
> > 3.2 will be wrapped up and released as soon as I find and fix a few
> > more specific bugs. Hopefully within a week.
>
> Great! We will concentrate on using the 3.2 sources for our releas
Kendall Bennett wrote:
>
> Hi Guys,
>
> I am trying to determine the latest status of the Mesa 3D project,
> since we are trying to wrap up some of our Mesa projects for release.
> Hence I am thinking that we should be sticking to the Mesa 3.2
> sources instead of the Mesa 3.1 (or is it now Mesa
Those of you who want CVS write access must first get an account
on sourceforge. Then send me a note, with your login ID, so I
can add you as a project developer and enable CVS writes for you.
Note that you'll need ssh (Secure Shell) on your system for CVS
write authentication.
-Brian
__
One of the Mesa CVS host's disks went haywire and so VA moved the
Mesa CVS tree to SourceForge.net. Everything appears to be intact.
(sigh of relief!)
So, everyone will have to check out a new CVS tree from SourceForge
following the instructions at http://sourceforge.net/cvs/?group_id=3
I'd al
"Jacob (=Jouk) Jansen" wrote:
>
> Hi
>
> Is something wrong with the CVS machine. I only get:
>
> sm43-jj) alias cvsmesa
> cvs -d:pserver:[EMAIL PROTECTED]:/cvs/mesa3d
> sm43-jj) cvsmesa checkout .
> cvs [checkout aborted]: unrecognized auth response from cvs.mesa3d.org: cvs pser
> Jouk
"Jacob (=Jouk) Jansen" wrote:
>
> Hi
>
> Is something wrong with the CVS machine. I only get:
>
> sm43-jj) alias cvsmesa
> cvs -d:pserver:[EMAIL PROTECTED]:/cvs/mesa3d
> sm43-jj) cvsmesa checkout .
> cvs [checkout aborted]: unrecognized auth response from cvs.mesa3d.org: cvs pser
> Jouk
> Gerry Cook wrote:
>
> Brian,
>
> I have problems with widgets-sgi. I tried contacting suggested support at
> [EMAIL PROTECTED] and
> crunch.ikp.physik.th-darmstadt.de (unknown ISP) as documented in Mandrake
> Linux 3.1. Do you keep contacts updated and how do I contact Thorsten Ohl or
> Jeroen
If anyone has seen clipping problems in Mesa 3.1 or later on X86 systems
you might be interested in this.
I found that gl_x86_cliptest_points4() is raising an FP overflow
exception in some programs. Disabling that function, by commenting
out the assignment near line 114 of Mesa/src/X86/x86.c:
I'm glad that people are reporting bugs in the Mesa bug database
on SourceForge. However, I'd like it if people would submit their
bugs as a real user, not anonymously. If you submit bugs anonymously
you won't get email when the report is modified. People usually don't
submit enough informatio
"Jacob (=Jouk) Jansen" wrote:
>
> Hi All,
>
> Someone switched the GLX_EXT_visual_rating macro on in glx.h. This gives
> problems in src-glut/glut_distr.c since GLX_SLOW_VISUAL_EXT is not defined.
>
> Why was glx.h changed?
> What should be the definition of GLX_SLOW_VISUAL_EXT?
As I wrote b
I've just upload the Mesa 3.2 beta 1 files to SourceForge at
https://sourceforge.net/project/filelist.php?group_id=3
3.2 (note even number) is a stabilization release of Mesa 3.1
meaning it's mainly just bug fixes.
Here's what's changed:
Bug fixes:
- mixed drawing of lines and bitm
Keith Whitwell wrote:
>
> Marco Tessore wrote:
> >
> > My system (Slackware 7.0) doesn't compile macros written on multiple
> > lines.
> > I must compat like the file in attachment.
> > Sorry for my English and thank you for Mesa
> >
> > Marco Tessore <[EMAIL PROTECTED]>
> >
> > ---
Last night I finished my antialiased triangle code for Mesa 3.3.
It seems to work pretty well. It could stand some performance
tuning but it'll always be considerably slower than non-
antialiased triangles.
I believe this was the last bit of OpenGL functionality which was
missing in Mesa.
-Bri
As I've said before, I'm going to be moving the Mesa project to
SourceForge.net in the near future.
Those of you on the Mesa developer's list should visit
www.sourceforge.net, register yourselves as users and join the
[EMAIL PROTECTED] mailing list. I will not be automatically
moving the member
emanuel stiebler wrote:
>
> Hi,
>
> Is it true, that the size of GLcontext is about 75 KByte ?
sizeof(GLcontext) ~= 72KB in Mesa 3.3. With all the other structs
and arrays that it points to it's probably several times that size.
> Is there any chance to get it smaller ?
Not much smaller.
W
Eero Pajarre wrote:
>
> While searching for a bug (which was elsewhere),
> I noticed that glPopAttrib doesn't seem to
> call the necessary driver functions for
> restoring the current "clear color"
>
> And there might be similar problems with the
> write masks...
>
> And I guess this is a typo:
emanuel stiebler wrote:
>
> Hi all,
>
> In osmesa, i can allocate my own framebuffer, which resides on my pci-card.
> But, what is the suggested/clean way to do the same with the depth-buffer ?
>
> Because I'm writing a driver for a card which has a rendering processor, it
> would be "nice" if
I've checked in some changes for Mesa 3.3 so that it can support
different sizes of depth buffers at runtime. Previously you had
to recompile for 16 or 32bpp depth values. That was bad for the
new hardware device drivers.
Now you can choose any depth from 0 to 32 bits. For software
rendering,
relnev wrote:
>
> Patch for colortab.c. _mesa_GetColorTableParameteriv didn't support
> the PROXY_TEXTURE formats..
Thanks. I've applied the patch to Mesa 3.3 (and back-ported it to 3.2).
-Brian
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://li
relnev wrote:
>
> A two line patch against src-glu/mipmap.c for gluScaleImage to allow
> GL_BGR and GL_BGRA formats
Thanks. I've applied the patch.
-Brian
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
"Jacob (=Jouk) Jansen" wrote:
>
> Hi all
>
> I got the following compilation informational warnings for the latest Mesa3.3
> At the moment I have no time to look into it. Maybe they are harmless.
>
>Jouk
>
> cc /include=([-.include],[])/define=(FBIND=1) MATRIX.C
>
>if (mask ==
"Jacob (=Jouk) Jansen" wrote:
>
> [EMAIL PROTECTED] wrote on 23-FEB-2000 16:40:03.97
>
> >"Jacob (=Jouk) Jansen" wrote:
> > I may have located the problem in xmesa2.c:
> >
> > if (xmesa->xm_buffer->buffer != XIMAGE) {
> ^^
> backpix
"Jacob (=Jouk) Jansen" wrote:
>
> Hi
>
> Brian wrote:
> >Yesterday I checked in a few changes to xmesaP.h, xmesa1.c and xmesa2.c
> >which fixed some problems with 24bpp rendering and buffer clearing.
> >
> >Can you get a more detailed stack trace? Setting the MESA_XSYNC env var
> >first will fo
"Jacob (=Jouk) Jansen" wrote:
>
> Hi all,
>
> When running xlockmore with Mesa3.3 this morning (MET) I get in some of the
> demos this runtime error
> polka-jj) xlock -nice 0 -modelist allgl -inwindow
> X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
> Major opcode
I've checked in a few new files which implement antialiased triangles.
The code isn't finished yet- this is just a checkpoint. I need to fix
a bug involving edges with very small slopes and the mipmap lod
computation hasn't been implemented yet. Finally, it will need some
optimization.
The cod
Eero Pajarre wrote:
>
> I just tried to run my program, which I have developed with
> Win32+Mesa+3dfx, with Win32+Nvidia Open GL+Geforce.
>
> It did not work ;-(
>
> I tracked down the reason: I was pushing two times a matrix into
> the projection stack. Geforce driver apparently only
> impleme
relnev wrote:
>
> This small patch fixes a problem when using a shared palette with
> textures (EXT_shared_texture_palette) for mesa32 (even if
> SHARED_TEXTURE_PALETTE_EXT was enabled, texObj was used to check for the
> current palette format).
Thanks. I've committed the fix to the 3.2 and 3.3
Thomas Tanner wrote:
>
> On 16-Feb-2000 Brian Paul wrote:
> > Thanks. I'd like to elaborate on this. The Linux/OpenGL standard
> > calls for libGL.so to be built with implicit links to all other
> > libraries which it depends on. I've been working on fixing t
Michael Vance wrote:
>
> On Wed, Feb 16, 2000 at 01:54:51PM -0700, Brian Paul wrote:
>
> > > Where can I find information about the values in ctx->ProjectionMatrix?
> >
> > Not sure I understand your question.
>
> Where are the values for ctx->Proj
Michael Vance wrote:
>
> This is all with respect to software Mesa:
>
> Where can I find information about the values in ctx->ProjectionMatrix?
Not sure I understand your question.
> I'm tracing through the glFog code, and for the
> code I'm testing the value of eyez is always zero, so for EX
As I wrote earlier, I changed the old-style Makefile so that the
libGL, libGLU, and libglut libraries are implicitly linked with
the libraries that each is dependent on.
This is done with the GL_LIB_DEPS, GLU_LIB_DEPS, GLUT_LIB_DEPS and
APP_LIB_DEPS vars in the Make-config file. These are used
Thomas Tanner wrote:
>
> On 13-Feb-00 Brian Paul wrote:
> >> Is there any reason Mesa 3.3 is building without link information
> >> in the library? Those of us who dlopen() the library get a dl_error
> >> because we can't anticipate the need of, say, G
Neal Tringham wrote:
>
> (I actually posted this message a week or so ago, but I haven't seen a
> reply and I've noticed that the header was malformed for some reason -
> it both sent and copied the message to Mesa-Dev. So I'm resending it in
> case it didn't actually get sent out by the list.
Michael Vance wrote:
>
> Is there any reason Mesa 3.3 is building without link information
> in the library? Those of us who dlopen() the library get a dl_error
> because we can't anticipate the need of, say, Glide.
I guess you're using the GNU configure scripts, right?
Using the old-style Make
Eero Pajarre wrote:
>
> In my application I noticed than when I
> repeat a mixture of glGenTextures and then
> glDeleteTextures, my texture id numbers from
> glGenTextures seem to go up all the time.
> (I had specific conditions, like I hardly ever
> had the texture to be deleted as the current
>
emanuel stiebler wrote:
>
> Hi,
>
> why is glinfo reporting a version 3.1, and not 3_2_dev ?
Because I hadn't updated it yet. I just fixed it.
There are several other places where version strings
have to be checked/updated. I'll try to do that soon.
-Brian
_
emanuel stiebler wrote:
>
> Hi,
>
> tried:
>
> nmake /f nmake.mak alldynamic (with the CVS of todays morning) i get:
>
>Creating library .\Release\glu32\GLU32.lib and object
> .\Release\glu32\GLU32.exp
> tess_fist.obj : error LNK2001: unresolved external symbol
> _tess_clip_polygons
> .\Re
Daryll Strauss wrote:
>
> On Fri, Feb 04, 2000 at 03:47:05PM +, Neal Tringham wrote:
> > FX_grTexCombine_NoLock(GR_TMU1, GR_COMBINE_FUNCTION_ZERO,
> > GR_COMBINE_FACTOR_NONE, GR_COMBINE_FUNCTION_ZERO,
> > GR_COMBINE_FACTOR_NONE, FXFALSE,FXFALSE);
> >
> > call for the (LODBlend
Brian Paul wrote:
>
> I've reorganized the contexts of some of the 3.3 source files.
contents
-Brian
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
I've reorganized the contexts of some of the 3.3 source files.
Removed:
glmisc.c
glmisc.h
New:
buffers.c - glRead/DrawBuffers, glClear, etc
buffers.h
hint.c - glHint and related funcs
hint.h
state.c - state management, used to b
wmilas wrote:
> > fresh checkout, ./bootstrap, ./configure, make
> >
> > After doing the above, it looks like none of the SVGA directory is being
> > compiled. ie, no .o files.
> > ./config does spit out:
> > checking for vga.h... yes
> > checking for main in -lvga... yes
> > and later on:
> > cr
Wayde Milas wrote:
>
> Compiling cvs 3.2_dev as of today yields wierd lib errors when running a
> OGL app. Im getting:
> sh: error in loading shared libraries: /usr/local/lib/libGL.so:
> undefined symbol: __clear_color16
>
> This seems to have cropped up in the last coupla weeks. Any ideas?
Loo
As I mentioned last month, I intend to move the Mesa project onto
SourceForge.net at http://mesa3d.sourceforge.net/
CJ Beyer and I have now moved the web pages and ftp content to
sourceforge. The www.mesa3d.org IP number will get reassigned
to the new server in the near future.
Also, the bug d
Lately I've been curious about the performance of glTexImage2D under
various conditions so last night I whipped up a new test program.
I've check it in demos/texdown.c
You can use the keyboard to change texture size, format, datatype,
toggle scaling/biasing, glTexSubImage loading, etc. and see t
Michael Vance wrote:
>
> On Thu, Jan 27, 2000 at 12:19:48PM -0700, Brian Paul wrote:
>
> > So, you're all set now?
>
> Yep. Offhand, do you know if similar problems exist with other glX
> implementations?
A real implementation of GLX shouldn'
Michael Vance wrote:
>
> On Thu, Jan 27, 2000 at 11:49:45AM -0700, Brian Paul wrote:
> > Have you looked at glXReleaseBuffersMESA(Display, GLXDrawable)?
> > If you call this function after destroying your window, Mesa
> > will free the internal XMesaBuffer associated wi
there.
> On Thu, Jan 27, 2000 at 11:17:47AM -0700, Brian Paul wrote:
>
> > Yes, XMesaBufferList should be set to NULL when the last XMesaBuffer
> > is removed from the list.
>
> Hm, free_xmesa_buffer() is never called after the
> glXDestroyContext(). It seems that
Michael Vance wrote:
>
> Does the XMesaBufferList ever get reset to NULL when the last context
> is destroyed?
>
> I'm seeing lockups in XSync() inside of XMesaGarbageCollect() after
> creating, then destroying, then trying to create again... the first
> time through, XMesaBufferList is NULL, I
Stephen J Baker wrote:
> On Thu, 27 Jan 2000, Jacob (=Jouk) Jansen wrote:
>
> > Agreed. I think it would be best to include both (or pointers only) in the
> > Mesa-distribution so that application builders can choose. Remember that
> > (free)glut is only a tool-kit to make programming with OpenGL
Stephen J Baker wrote:
>
> On Wed, 26 Jan 2000, Adam D. Moss wrote:
>
> > Stephen J Baker wrote:
> > > I was wondering about whether we should consider
> > > dropping GLUT from the next major Mesa distribution
> > > (3.4 I guess) and replacing it with 'freeglut'
> >
> > FWIW I think that this is
Dieter Nützel wrote:
>
> What's the problem here?
>
> rm -fr .libs/libGL.la .libs/libGL.* .libs/libGL.*
> gcc -shared accum.lo alpha.lo alphabuf.lo attrib.lo bbox.lo bitmap.lo
> blend.lo clip.lo colortab.lo config.lo context.lo copypix.lo cva.lo
> debug_xform.lo depth.lo dispatch.lo dlist.lo dr
Richard Guenther wrote:
>
> Hi!
>
> I get SIGSEGVs in feedback.c:gl_do_feedback_vertex()
> at the line
>
>gl_feedback_vertex( ctx, win, color, VB->IndexPtr->data[v], tc );
>
> VB->IndexPtr is NULL.
>
> The fault is on my side, though as I rendered geometry without
> Normals in twoside-lig
ralf willenbacher wrote:
>
> mitch wrote:
> >
> > If I compile SSE support into mesa, can it access the registers without
> > patching the kernel?
>
> no.. it would produce illegal instructions
>
> > Does the kernel patch just allow multiple uses or
> > how does that work and what do I need to
mitch wrote:
>
> to add to this, I went back to my mesa 3.2 cvs from two weeks ago and now
> everything works just fine. Is the current 3.2 broke or did I miss some
> new update or compile method?
It should work. You'll have to provide more details in order to get
help.
-Brian
__
mitch wrote:
>
> Mesa 3.2 compiles just fine but when I tried to build the current 3.3
> cvs with SSE support, I got the following error
>
> svgamesa.c:246: structure has no member named `SetBuffer'
> svgamesa.c: In function `SVGAMesaCreateContext':
> svgamesa.c:388: too few arguments to functio
Gareth Hughes wrote:
>
> Okay, I'll target the work for 3.5 then. I've reread the specs
> (including the patent issue stuff) - are we even allowed to do this?
> Can we get permission from SGI to implement both extensions?
I don't know. Someone will have to ask SGI. I'm too busy.
-Brian
___
Eero Pajarre wrote:
>
> I have a patch which adds support for RGB5_A1 internal
> texture format for mesa/3dfx driver.
>
> (Now it is an appropriate time to inform me that the 3dfx does
> not really support this internal format, and I have imagined
> that the color quality improved when compared
"Hughes, Gareth" wrote:
>
> Any news/updates on the Mesa implementations of these specs? I was under
> the impression someone was implementing EXT_fragment_lighting, but haven't
> really heard or seen anything about this lately.
I don't think anyone is working on it. All I saw was talk, no cod
"Jacob (=Jouk) Jansen" wrote:
>
> Hi,
>
> The VMS compile support is up to date. So no objections to create a distribution
> from my side.
Thanks, Jouk!
-Brian
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mes
Holger Waechtler wrote:
>
> Hi Brian, hi everybody else,
>
> Mesa reports wrong depth values in picking mode. Try the pickdepth demo
> from the Red Book examples to see.
>
> The problem is in feedback.c (gl_select_triangle, gl_select_line and
> gl_select_points):
>
> gl_update_hitflag( c
Status report on Mesa 3.2 / 3.3:
It looks like we'll need Mesa 3.3 for the XFree86 4.0 release
since the new dispatch mechanism is needed for the new libGL.so
design. The timetable is a bit aggressive so here's the plan.
First, Mesa 3.2 (the stabilization of 3.1) is just about ready.
The only
Mesa 3.3 features a new API dispatch system. In order make it as
efficient as possible it should be implemented with assembly
language. I'm looking for a volunteer to help with this.
Basically, all of the GL entrypoints/functions need to be implemented
with a tiny assembly language routine whi
Bernd Kreimeier wrote:
>
> Jim Kutter writes:
> > i.e. 512x384 just displays in part of the screen, or worse yet, it falls
> > back to mesa software.
>
> On a related note, is there any way to prevent the fallback
> to software, and have glXCreateContext fail instead?
No.
> The automatic fa
Jon Taylor wrote:
>
> Can someone fix this? I can't commit
Done.
-Brian
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
mitch wrote:
>
> sorry, one more question. I don't see the sse option in the readme or
> install. How do I configure Mesa with SSE support? Thanks.
SSE/Katmai optimizations are only in Mesa 3.3 now.
You can use the old style makefile targets linux-katmai or
linux-katmai-glide to build. Or, usin
Michael Vance wrote:
>
> On Tue, Jan 04, 2000 at 04:12:22PM -0700, Brian Paul wrote:
>
> > catching signals and registering atexit() handlers. However, they're
> > there to solve other problems.
>
> Right.
>
> > I'm not sure that testing glbTotN
Michael Vance wrote:
>
> If you happen to register an atexit() handler in your code that calls
> glXDestroyContext(), and then you create a context, FX-Mesa will then
> register an atexit() handler itself. When your program exits, the
> FX-Mesa handler is called first, it brute force deletes the
PimpSmurf wrote:
>
> make linux-3dnow-glide fails in current 3.1 version also.
> I reported the cvs as doing this, not knowing that it current version
> did also.
> here is the screen dump.
>
> make[2]: Entering directory `/usr/src/Mesa-3.1/src'
> make[2]: *** No rule to make target `FX/X86/fx_g
Someone reported a compiler flag problem using the GNU configure
build method.
The flag -ieee_with_no_inexact must be used when compiling
for the Alpha processor using the DEC compiler. Otherwise
there's a problem with FP exceptions.
The old-style Mesa makefiles did this but I'm not sure how t
Eero Pajarre wrote:
>
> Ok this seems to work:
> (Neal, could you please test this with your VC version?
> and propably it would be best that some Linux/Gcc users
> would try this now as well)
>
> 1) add FX\X86\fx_3dnow_fastpath.obj to the end of
> X86OBJS variable at makefile.fx.
Done in 3.2 an
I discovered there's a dead CVS lock half-way through tagging
the sources (mesa_3_1 tag). I have to wait for VA Linux to
remove it. Please don't check anything in until this is resolved.
I'll post when it's done.
-Brian
___
Mesa-dev maillis
I'm happy to announce that Mesa 3.1 is now available!
It's available for download from the Mesa web site at www.mesa3d.org
There's a lot of new things in Mesa 3.1. Please see the
included docs/VERSIONS and docs/RELNOTES files for details.
I'd like to thank a few people who have made very sign
I'm planning on making the final 3.1 release really soon now,
maybe today.
Keith and I fixed a few of the recently reported bugs over
the weekend. I encourage people to update from CVS and test
their apps. Report problems ASAP. However, it'll take a
pretty serious bug to stop the release. I
John Carmack wrote:
>
> Since new driver interfaces have been brought up, here are some thoughts
> about improving texturing:
>
> With the current architecture, it isn't possible to accelerate
> glCopyTexSubimage, even though most non-voodoo hardware is capable of doing
> it completely asynhrono
Randall Frank wrote:
>
> Hello,
> I ran into a snag today, it appears that the glx routines
> are not thread aware? In my example, I am rendering to multiple
> gl contexts simultaneously using pthreads under Linux/Irix. Mesa
> with thread support enabled seems to work ok, but I had the
I've check in a bunch of new stuff into the main / 3.3 branch:
1. Device driver support for hardware stencil buffers.
Four new functions were needed to access the stencil values when
falling onto a software path:
WriteStencilSpan
ReadStencilSpan
WriteStencilPixels
Ralph Giles wrote:
>
> Hi everyone,
>
> Here's a patch against the mesa_3_2_dev branch that updates the .cvsignore
> files to ignore the generated files. It also adds some new ones. I got
> tired of seeing all those '?' lines when I did an update. ;)
>
> One caveat: One of the more common thing
Doh! The subject should have been GLX_ARB_get_proc_address (note
the X).
The extension adds glXGetProcAddressARB() to GLX, not the core GL.
-Brian
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
This extension was approved at this week's OpenGL ARB meeting.
It will operate context independently, for those of you wondering.
I've checked in my changes to support it in Mesa 3.1/3.2.
Implementing it in Mesa 3.3 will take a bit longer.
The latest version of the spec for this extension is at
"Hughes, Gareth" wrote:
>
> I've just added the ability to do boundary-only tessellation, ie. just
> output the final contours as line loops. What are the chances of running
> the new tessellation code through the OpenGL conformance tests? Can we
> still do that?
I've had the 1.0 conformance t
Eero Pajarre wrote:
>
> Andre Werthmann wrote:
> >
> > I have committed the remaining transform-functions written in SSE-assembly.
> > That means now all the transform_points* functions are done in SSE-assembly :)
> >
> > These functions are faster than the fpu-ones, but to get the most speed ou
For those of you who haven't heard of it yet, SourceForge is
VA Linux System's new site for hosting of open-source development
projects. Check it out at www.sourceforge.net It looks really
promising and is already hosting many projects. Precision Insight
will be storing its DRI-related work th
Eero Pajarre wrote:
>
> (I think I have mentioned this sometimes before)
>
> For some unknown reason I cannot get the hot key for
> toggling the in-window rendering for FxMesa to work
> on my Win95 machine.
>
> (I guess it must work for other people)
>
> The attached patch fixes this on my co
JONATHAN DINERSTEIN wrote:
>
> As an example of the kind of rendering errors I want to get rid of,
> check out:
> http://www.npl.com/~jon/
>
> It is a jpeg so some amount of loss has happened, but you can still easily see
> the problem. All I did was have GLUT draw a sphere of a
Bernd Kreimeier wrote:
>
> Brian Paul wrote:
> > I recently rewrote the fxDDReadRGBASpan() and fxDDReadRGBAPixels()
> > functions. Before, these functions were returning bad (imprecise)
> > values. Instead of doing bit masking and shifts a lookup table is
> > now
"Hughes, Gareth" wrote:
>
> > Hi All,
> >
> > I just checked the performance of the new GLU with the text3d demo in
> > xlockmore. (why is the new version only in the 3.2 branch and not in
> > the 3.3?) A lot of letters in the demo are not correctly processed
> > (=look awfull!!!)
>
> Okay, I'll
Brad Grantham wrote:
>
> > From [EMAIL PROTECTED] Mon Nov 29 21:56:58 1999
> > Hi everybody,
> >
> > I've been needing to produce non-realtime high quality output from
> > OpenGL programs I've already written. As a result, I'm adding Phong shading to
> > Mesa. I'd like to do this r
Michael Vance wrote:
>
> On Fri, Nov 26, 1999 at 12:48:47PM -0700, Brian Paul wrote:
>
> > Furthermore, glCopyPixels needed the same fix.
>
> As an addendum, is there a color swap bug in the 3Dfx glReadPixels
> implementation? I was going to have a hack at fixing i
"Hughes, Gareth" wrote:
>
> I'm committing an update to the Win32 makefiles so they build GLU correctly
> with the changes I've done lately. There seems to be a lock hanging around
> on Win32/Rules...
I don't have permission to remove the lock file. I've send a
message to the admins ([EMAIL PR
Gareth Hughes wrote:
>
> Okay, I've added some code that gobbles up zero-area ears as the are
> created. This fixes the last of the problems with the Red Book demos.
>
> I'm committing those changes now. So, the clipping/winding rule
> operations are done, and the tessellation itself is done.
Brian Paul wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > Hi,
> >
> > here is a bugfix for DrawPixel:
> >
> > When depth test is disabled but fog enabled, the z-span for "gl_fog_rgba_span"
> > is uninitialized.
> >
> > [B
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> here is a bugfix for DrawPixel:
>
> When depth test is disabled but fog enabled, the z-span for "gl_fog_rgba_span"
> is uninitialized.
>
> [Bug found with Flightgears panel & GLX-MGA - I don't know if FlightGear
> really wants a fogged panel but that's the
Ralph Giles wrote:
>
> On Wed, 24 Nov 1999, Brian Paul wrote:
>
> > > The mesa_3_2_dev branch still thinks it's 3.1, and our configure script
> > > reports it as such.
> >
> > It's correct as-is. The mesa_3_2_dev branch will end with the release
Ralph Giles wrote:
>
> Hello all,
>
> Over on the glx list, we've been seeing reports from users confused about
> mesa versions. We're currently tracking 3.2 cvs, and no doubt all this
> will go away when 3.2 is actually released. However, aside from those who
> don't read our documentation, tw
Heriberto Delgado wrote:
>
> I have a question about color index management. In all the books I've read about
> GL, there is NO definition of how RGB colors must be distributed across color
>indexes;
> apparently, it's implementation-dependent. However, if we look at the Palm, we'll
>see it
>
Eero Pajarre wrote:
>
> The latest glu.h update causes some problems for VC++ 5.0.
>
> The compiler gets upset because of the prototype parameter
> names "near" and "far". Apparently it has somekind of deja-vu
> experience because of Microsoft C history.
>
> So I hope the parameter names can be
1 - 100 of 333 matches
Mail list logo
