Initializing and transferring the buffer all read back and verified to be correct.
Then:
glBindBuffer(GL_ARRAY_BUFFER, buf);
glVertexPointer(2, GL_FLOAT, 0, 0/XXX/);
glEnableClientState(GL_VERTEX_ARRAY);
glDrawArrays(GL_LINE_STRIP, 0, 2); // Access violation reading 0x00000000 /or any other value at XXX/
glDisableClientState(GL_VERTEX_ARRAY);
glBindBuffer(GL_ARRAY_BUFFER, 0);
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.
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).
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.