2009/8/18 Alex Holkner <[email protected]>:
> I too have heard that maintaining vertex ordering is not a requirement
> of OpenGL, but I haven't seen the relevant part of the specification
> to be sure, nor have I seen it happen in practice. Incrementing Z for
> each primitive in your draw order should be sufficient to maintain
> that ordering though, even if the driver does like to reorder things
> at the same Z depth.
Page 28 of the OpenGL 2.0 spec (the version I happen to have to hand,
I'm sure it's the same in other versions, albeit on a different page)
claims:
The effect of
DrawArrays (mode, first, count);
is the same as the effect of the command sequence
if (mode or count is invalid )
generate appropriate error
else
{
int i;
Begin(mode);
for (i=0; i < count; i++)
ArrayElement(first + i);
End();
}
with one exception: the current edge flag, texture coordinates, color,
color index, and normal coordinates are each indeterminate after the
execution of DrawArrays, if the corresponding array is enabled.
There are similar passages for MultiDrawArrays and DrawElements.
Unfortunately, I can't seem to find anywhere that explicitly states
that primitives within a Begin()/End() block can't be reordered, but
nor can I find anywhere that states that they can. The general feel I
get from the text is that the authors didn't expect this to happen,
but they didn't specify explicitly, as far as I can see.
Of course, just because the spec says so is no guarantee that any
given implementation will play nicely, but it's nice to have the
standard on your side.
Martin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
