according to the spec
glAttribPointerARB should be part of a display list, however I just tried this and it doesnt work
when I abuse some classic pointer like texcoord, the arb_vertex_program will work.
but not when using attrib pointers.
my fix now is using secondary color, however I wonder if that works well in the .w value the handness is stored -1/1 will secondary color normalize the color vector ? or will I get the same values I point to from within the vertex program ?
has anyone else had this problem ? though probably noone uses display lists anymore
stranded on laptop here so cant test if its just a driver bug, running 9600moblity atm
You do know that the attribute data gets de-referenced at display list compile time, don’t you? That means that even though glAttribPointer is valid in a display list, the data is ripped from the array pointed to at DL compile time, and the pointer itself is forgotten about.
I hope you knew that.
If you did, and I’ve gotten hold of the wrong end of your stick, post your display list compilation code, and clearly state what behaviour you’re expecting, and what behaviour you’re actually getting.
BTW, display lists are widely supported…they give the same performance as static VBO’s in my experience (well, you have to compile them in immediate mode on quadros, but that’s just an nvidia bug). Lots of professional software (things like autocad, 3dsmax etc.) use display lists extensively, so the drivers are seriously optimised for 'em.
yes I am aware of the data being ripped
the problem is that the data is not being ripped when I use AttribPointer, but it works when I use any other “old” pointer, like secondarycolor, normal, pos, texcoord
so lets say I store the tangents in a texcoord array, it will work fine when I render the display list
but not when I use say attrib
what I expect is that glVertexAttribPointerARB works just like glTexCoordPointer when used within a display list compile
at the moment it doesnt
and I make sure the attrib channel doesnt collide with other classic pointers
yes, as said its the same setup like for the other pointers, and when I use one of them it will work just fine.
Sounds like a driver bug. Do you have a sample app?
here is a current testbuild:
the ev2bump. batch files have the sample inside with displaylist or vertex array
thx to Humus, the situation is clear now and likely a bug thats going to be fixed