Here’s what I think they’re getting at. If you use the legacy vertex attribs, you do glEnable/DisableClientState and gl*Pointer, where * is Vertex, Color, Normal, etc., to set up the vertex attribute array. With these you specify the vertex attrib by legacy “name”.
If you instead use the new-style generic vertex attribs, you instead do glEnable/DisableVertexAttribArray and glVertexAttribPointer to set up the vertex attribute. Same thing, just different APIs, and you specify the attribute by integer “index” rather than by legacy name.
Note that despite an incorrect assertion above (Simon misspoke), this has nothing to do with client arrays vs. VBOs (i.e. server arrays). You can use generic vertex attribs with either, and you can use legacy vertex attribs with either.
The glEnable/DisableClientState deprecation is merely meant to encourage you to use the new generic vertex attribs rather than the legacy vertex attribs.
The openGL core is a C API and I don’t see any need to demonstrate it using C++ anyway, this just excludes some of the user base.
Did you actually read the code, or did you just look at the .cpp extension and think, “well, that’s C++, so I can’t possibly understand it.”
The only thing C++ in those code files is the fact that it defines variables at arbitrary locations within a function (and even that’s standard C99). There are no classes, operator overloading, function overloading, templates, template metaprogramming, RAII, or anything that is even remotely C++. It even uses the braindead “typedef struct” syntax for its structs.
I know it’s a shock to realize this, but C++ is also C.
BTW, the OpenGL API is not a C API. It is usually exposed through C, but the OpenGL specification is language-neutral.
Whoops, deleted most of the post before I noticed these responses, since it seemed slightly obnoxious.
Anyway, no, I haven’t had a look yet. I do think it is just bad form to strap a bunch of extraneous detail into a demo HOWEVER, I still don’t know what those demos are for, so I can’t really call any of the details “extraneous”. Extraneous to my purposes, anyway. It’s not so much a matter of being “unable”, it’s more a matter of convenience – eg, I like having shortcuts to common directories, tho I am generally able to find them one node at a time if not.
All apologies.
Yep, that’s where I’m headed. I suspect there are/will be enough other people in the same boat to justify the tutorial as a “transitional” step.
Anyway, no, I haven’t had a look yet. I do think it is just bad form to strap a bunch of extraneous detail into a demo HOWEVER, I still don’t know what those demos are for, so I can’t really call any of the details “extraneous”. Extraneous to my purposes, anyway.
How can you say that? You are judging a demo you admit to not having seen, saying that it has “extraneous detail”. How could you possibly know that anything in that code is “extraneous to my purposes.”
You’re literally judging code based solely on the presence of the “pp” at the end of the filename extension. Even a cursory inspection of the code would show it to be C+±in-name-only.
:eek: Okay, you got me on some semantics there AR. I did take a glance.
To be fair, pretty sure those are actually files left by Illian Dinev at dropbox because of this (much thanks!) so were NOT written for the purpose of educating me. Guess I got a little defence and thought it was someone again trying to prove this is adequately documented on line.
And yeah, I should be able to figure it out now, or later today.
So, sorry again. I promise: from now on I count to 10 before posting.
