Brian Paul wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > On 18-Nov-99 [EMAIL PROTECTED] wrote:
> > >
> > > However, "DrawArrays" is broken anyway. It doesn't use the Z-values
> > > from the vertex array on startup. When you switch to eg. DrawElements
> > > and then back to DrawArrays it's ok, but j
[EMAIL PROTECTED] wrote:
>
> On 18-Nov-99 [EMAIL PROTECTED] wrote:
> >
> > However, "DrawArrays" is broken anyway. It doesn't use the Z-values
> > from the vertex array on startup. When you switch to eg. DrawElements
> > and then back to DrawArrays it's ok, but just start my testprogram
> > (prev
Hello again everyone!
For all of you who have a Palm, I'm sending with this message a .ZIP containing two
PRCs
with my attempt to make an GL-alike library for the Palm. A copy of the complete
Codewarrior
project is included, too. One of them uses the floating-point library included with
Cod
Somehow "ctx->Driver.GetBufferSize" get called before it is set up
when I run "glxinfo" with the MGA-GLX driver... I don't know if
this should considered a bug in the MGA-GLX driver or in Mesa.
Nevertheless here is a fix for it:
Index: context.c
=
Wolfram Gloger wrote:
>
> Hi,
>
> I sent the following patch two months ago, and just discovered it
> hasn't been applied yet to current CVS sources. If you think it is
> wrong, please tell me why. It plugs a memory leak for me and in fact
> worse: if comparePointers is false, then `vishandle'
Brian Paul <[EMAIL PROTECTED]> wrote:
> > The first problems I saw where with glut.h
> > These are with _WIN32
> >
> > 1) (warning)
> > glut.h defines CALLBACK, but it seems to be also
> > defined by gl.h, so there is a "already defined"
> > warning.
>
> Perhaps Ted or Kendall can check on this
Hi,
I sent the following patch two months ago, and just discovered it
hasn't been applied yet to current CVS sources. If you think it is
wrong, please tell me why. It plugs a memory leak for me and in fact
worse: if comparePointers is false, then `vishandle' points nowhere
definite, so crashes
On 18-Nov-99 [EMAIL PROTECTED] wrote:
>
> However, "DrawArrays" is broken anyway. It doesn't use the Z-values
> from the vertex array on startup. When you switch to eg. DrawElements
> and then back to DrawArrays it's ok, but just start my testprogram
> (previous mail), and the plane is centered
On 18-Nov-99 [EMAIL PROTECTED] wrote:
> There is a bug with "DrawArrays":
>
> When an application first uses DrawArrays and then switch to DrawElements
> or Begin/ArrayElement/End nothing is drawn for some frames - may be until
> the VB overflows...?
>
> I have attached a small test program:
>
I have checked in the first 40% of the PIII-optimized vertex-transformation code.
It can be optimized more (using prefetch-instructions to prevent cache-misses)...
I have modified the configure.in file and the file src/X86/Makefile.am to enable the
use of the new PIII-assembly
in autoconf/autom
There is a bug with "DrawArrays":
When an application first uses DrawArrays and then switch to DrawElements
or Begin/ArrayElement/End nothing is drawn for some frames - may be until
the VB overflows...?
I have attached a small test program:
It starts with "DrawArrays". Hit ´1´ to switch to Draw
11 matches
Mail list logo
