7

Does the latter deprecate the former?

I'm writing code which I would like to work on shader 2.0 hardware, but I want to use the more recent programming conventions such as VAO's.

So I have been using the glVertexAttribPointer functions instead of glVertexPointer, glNormalPointer, glColorPointer and so on.

It seems as though we have come to a point where the server-client concept isn't... particularly relevant (edit: I meant as it applies to switching state for these buffer pointers). But I'd like to know just what the old En/DisableClientState actually does and how it relates to what glEnableVertexAttribArray actually does.

And I also don't have any graphics hardware from 5 generations ago, but surely some user of my software might. How might I go about preventing my code from failing to compile on a Radeon 9700 for instance? (Though I hope if a user has the latest driver it might support the new stuff)

Steven Lu
  • 41,389
  • 58
  • 210
  • 364

1 Answers1

9

It seems as though we have come to a point where the server-client concept isn't... particularly relevant

Actually it's very relevant. The whole Buffer Objects terminology is in terms of server and client. The buffers are server side, and the client just issues drawing commands referring to the server side buffers.

The main reason for replacing glEnableClientState with glEnableVertexAttribArray is, that since OpenGL-3 always uses vertex arrays (there's no longer an immediate mode), and the distinction if the data is client or server side, is made by the binding states of the various buffer object slots. If buffer object 0 is bound, the data is client side, if the bound buffer object is nonzero it's server side.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • The pointer and draw calls which use a pointer (such as `glVertexAttribPointer` and `glDrawElements`) all take index offsets into the bound buffers when the buffers are bound. That means that this is a server-side operation because those bound buffers have already had their data transferred over to graphics memory. When they are not bound, I'd need to pass in a pointer to a local buffer with the data, which would make that a client-side operation. Yes? Otherwise you've got me totally confused with that last sentence. – Steven Lu Jan 11 '12 at 23:49
  • @StevenLu: Exactly like that. Unfortunately the OpenGL API got messed up with that passing of offsets in disguise of pointers. There's no way one can pass an offset to OpenGL in C by the functions as they're defined at the moment, without invoking undefined behaviour. Either you cast a number to a pointer, which is undefined for numbers, not resulting from casting a pointer to an int, or you cast the function signature to taking a uintptr_t, which may severely alter the way the parameter gets passed. Only sane solution: A new OpenGL function `glVertexAttribOffset` – datenwolf Jan 12 '12 at 10:27
  • Yes, I agree it would definitely cause less confusion to make a version that doesn't take a pointer. I have seen people use a macro which casts NULL to char * and then add offsets to that. It seems like the pointer is interpreted as a byte-offset integer. – Steven Lu Jan 12 '12 at 12:09
  • 1
    @StevenLu: See what I wrote about the topic for some in-depth insight: http://stackoverflow.com/a/8284829/524368 – datenwolf Jan 12 '12 at 12:26