On Wed, Jan 08, 2003 at 10:36:10AM +0000, Keith Whitwell wrote:
>
> >
> > Then there's a problem with glArrayElement() in the R200 driver while
> > recording a displaylist.
> >
> > The specific piece of code that it's running is this (while a displaylist
> > is being recorded in GL_COMPILE_AND_EXECUTE mode):
> >
> > glEnableClientState(GL_VERTEX_ARRAY);
> > glVertexPointer(3, GL_FLOAT, stride, &((*mesh)[0]->pos.x));
> > glEnableClientState(GL_NORMAL_ARRAY);
> > glNormalPointer(GL_FLOAT, stride,
> > &((*mesh)[0]->nrm.x));
> > int p = 0;
> > for (int i = 0; i < h - 1; i++)
> > {
> > glBegin(GL_TRIANGLE_STRIP);
> > for (int j = 0; j < w; j++)
> > {
> > glArrayElement(p);
> > glArrayElement(p + w);
> > p++;
> > }
> > glEnd();
> > }
> >
> > (w and h are set previously, and the nasty pointer math on 'mesh' just
> > gives pointers to the appropriate w*h arrays of vertex data.)
> >
>
>
> The isosurf demo lets you do something like this, but doesn't use
> COMPILE_AND_EXECUTE as it stands.
>
> As it stands, it works fine. If I change it to build the list with
> COMPILE_AND_EXECUTE, the first time (ie when it is being built) it works fine,
> but on subsequent calllists, nothing is rendered.
>
> Does this match what you are seeing?
If it causes a GL_INVALID_ENUM error, then yes, that matches what I see
with both my Radeon 7000 and the binary nVidia drivers (except that the
first few primitives in the displaylist do render). What other people seem
to be experiencing on the r200 driver is that it visits the vertices either
out-of-order or with huge gaps or other weird issues (like, getting offset
by sizeof(float) or whatever).
--
http://trikuare.cx
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
