Wined3d/OpenGL question

Jason Green jave27 at
Tue Apr 4 20:44:27 CDT 2006

On 4/4/06, H. Verbeet <hverbeet at> wrote:
> I think the first thing you should do, is to verify that it's the call
> to glDrawElements() that's generating the errors. glGetError just
> check if an error flag is set, but if an error flag is set it doesn't
> neccesarily mean the call right before glGetError generated that
> error. The easiest way to do this would probably be to call glGetError
> *before* the call to glDrawElements and verify that it return 0 /

Well, added that call just before the glDrawElements() call, and it
returns "call ok".  So, I tried Jame's suggestion that it was stuck
inside of a glBegin()/glEnd() call...  It didn't look like it in the
source, but to be sure, I put an extra glEnd() in the code under
certain circumstances [cleaned up and stripped of #ifdefs]:

    checkGLcall("before glDrawElements");
    /* This particular # of vertices w/ GL_TRIANGLES is on that is 
failing, so check for it */
    if (glPrimitiveType == 4 && numberOfVertices == 6144)
    if (idxData != NULL /* This crashes sometimes!*/) {
        TRACE("(%p) : glElements(%x, %d, %ld, ...)\n", This,
glPrimitiveType, numberOfVertices, minIndex);
        idxData = idxData == (void *)-1 ? NULL : idxData;
        glDrawElements(glPrimitiveType, numberOfVertices, idxSize == 2
                     (const char *)idxData+(idxSize * startIdx));
Here's the output:

trace:d3d_draw:drawStridedFast before glDrawElements call ok drawprim.c / 1226
fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> 502 from glEnd() @
drawprim.c / 1230
trace:d3d_draw:drawStridedFast (0x7fd8d1e8) : glElements(4, 6144, 0, ...)
fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> 502 from
glDrawRangeElements @ drawprim.c / 1248

I also did another check later to verify that idxData != NULL.  All I
can figure is that the data in idxData is somehow not matching up with
the data that OpenGL is looking for...  or the calculated # of
vertices or indices is somehow wrong?  I really don't know past this
point, but am willing to keep plugging away.  Any further ideas are


More information about the wine-devel mailing list