@ HellRaiZer

I took your advice (passing NULL into the glBufferDataARB() calls in CreateVertexBuffer and CreateIndexBuffer, not directly allocating any memory for mpVertexBuffer or mpIndexBuffer, and I experimented with removing the glBindBufferDataARB() calls in my unlock functions although it doesn't seem to make much difference to anything), and rewriting the DrawVertexBuffer() function) as you suggested. I'm getting a few frame's worth of garbage, followed by a crash. With regards to your question:

Quote:What's the value of 'mpVertexBuffer' when specifying glXXXPointer in DrawVertexBuffer? If it holds the last value from the Lock function, then this is wrong. If it's NULL then it should work. The point is that when using VBOs you don't specify a true pointer in memory, but an offset in the VB.

mpVertexBuffer and mpIndexBuffer both get set the first time the respective Lock functions are called, and still have the same values when DrawVertexBuffer is called, since nowhere in my code resets those pointers to NULL. Given than none of my code explicity does anything through those pointers (they're not passed into glBufferDataARB when the buffers are created, and in your version of the draw code, they're not referenced in glNormalPointer or glVertexPointer either). So, do I even need to keep those pointers around inside my rendering code?

@yosh64:

I'm not quite sure I follow you. Firstly, I assume that by unbinding, you mean calling glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0) or glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0)? Just checking...

I didn't quite follow what you said I should bind or unbind at which point, but I've added an unbind to CreateVertexBuffer, so it looks like this:


And similarly added an unbind to the end of CreateIndexBuffer. I've left the Lock and Unlock functions the same (ie Lock binds the buffer, Unlock unbinds it). And I'm also unbinding both buffers at the end of the draw function.

Still no joy :( Still getting garbage and crashes. I'll go through all of those tutorials and the white paper again with a fine tooth comb to see if there's anything I missed, I guess. It's just annoying that I can't debug any of the crashes. It seems like VBOs are pretty all-or-nothing; either they completely work, or they crash with no way of telling you why they crashed.

EDIT: although glDrawElements still crashes (as does glDrawRangedElements, which I figured out how to get compiling), using glDrawArrays actually gives something that looks a bit like what I expect. The vertices I can see all seem to be getting generated in the right place, but either the indeces are wrong or I'm missing about half of the vertex data - there are a lot of holes in my mesh, and a lot of weird triangles in places I don't expect. I can post the current version of my code, and screenshots about how the GL version and the D3D version look different if it'll help - although I suspect that it's wrong to be using glDrawArrays in this context anyway, so I might just be barking up the wrong tree.



[Edited by - ElectroDruid on July 15, 2007 3:23:54 PM]

Just to let everyone know that I sorted the problem. I am a happy bunny.

I went back to the red book (I have an old copy) to read up on glDrawElements and glDrawArrays, and remembered that glDrawArrays doesn't use index data, so if I was getting crashes, it must have been because of the index data. Turns out I was using GL_UNSIGNED_INT when the program was storing indeces as unsigned shorts. Doh! The problem is fixed now, and the program renders beautifully under both APIs.

Many thanks for your help, it was much appreciated!

ElectroDruid