Initializing and transferring the buffer all read back and verified to be correct.
glVertexPointer(2, GL_FLOAT, 0, 0/XXX/);
glDrawArrays(GL_LINE_STRIP, 0, 2); // Access violation reading 0x00000000 /or any other value at XXX/
Which clearly indicates the glBindBuffer call had no effect, which it should since the buffer has been verified to contain the exact data by mapping and reading it back after filling it with glBufferData(…, GL_STATIC_DRAW).
I’m baffled and very much welcoming any helpful information.
How about enabling the gl_vertex_array before specifying glvertexpointer ?
No, tried that and all else i can think of, and tried it again just now.
Try putting the glGetError and/or querying the id of the bound buffer after the first command. Somehow I get a feeling that your buffer didn’t bind correctly.
I have experienced this before, however the situation was a bit obscure: ATI drivers would ignore the VBO if used while compiling a display list. So, it would behave as if no VBO was bound, and since the offset was usually 0, it would AV trying to read from 0x00000000 (as it would in the case of a regular VA).
Indeed, i just re-read the spec. I did not expect such non-uniform behaviour. It was being compiled into a displaylist.
My bad, thanks.
Well the way I read the specs, there shouldn’t be any issue with using a VBO to compile a display list. Specifically
Which commands are compiled into display lists?
RESOLVED: None of the commands in this extension are compiled into display lists. The reasoning is that the server may not have up-to-date buffer bindings, since BindBuffer is a client command.
Just as without this extension, vertex data is dereferenced when ArrayElement, etc. are compiled into a display list.
Which was what I wanted in my case, but oh well