Ah, now I see, the correlation between BobVodka and Phantom… 
Nice to see you still visit after switching to DX10.
As I said, still hanging around for the post-GL3.0 aftermath… also I need something to read while at work 
OpenGL specification is written for the C language and I think C language should be used for the SDK tutorials too. C is also quite nice while C++ can be complicated for the new comers. GLUT (as in FreeGLUT which is maintained) is a good choice for the portability framework, another good one is SDL.
Boost is not a good idea IMO. You should keep the tutorials simple, clean and right to the point.
These are my thoughts…
It’s true that, ideally, an SDK should impose the fewest prerequisites possible, which precludes Boost and even C++. But like I said, if that’s the only way this project can get off the ground, then it’s unquestionably better than nothing.
If the project manages to get off the ground, then it would be worth considering reediting the articles to remove the C++/Boost stuff.
If somebody can make a really good OpenGL SDK and post all the articles online, then they could probably make enough money off of advertising to justify spending a day a week on improving it.
Edit: I see there’s been significant discussion about this over here. Pretend I never responded to the splinter discussion in this thread >:)
What was that? Did someone respond to the splinter discussion? I thought someone did, but now I’m not sure 
For the record, if anyone else feels the urge to comment:
[ul][]If it’s constructive, please post it in the thread Rick just linked to.[]If it’s not constructive, please refrain from posting it. We’re trying to have a serious discussion about this SDK, not a flamewar[*]If it’s to complain about how horrible the ARB “SDK” (and I use those quotes with a certain malice), feel free to send a mass email to the ARB members, with special attention to the Ecosystem guys.[/ul]
Activision-Blizzard is bigger than EA. Activision-Blizzard is on the ARB (Khronos OpenGL contributor).
Philipp
I’ve a question… when available, if I install a compliant OpenGL 3 driver on a computer, will OpenGL 2 app’s still running??
Other manner to explain: Can be OpenGL 2 and OpenGL 3 installed in the same computer?
DirectX allow to run oldies… those apps using older DirectX libs and classes available from newer releases.
This is the bigger problem I see in all this mess.
when available, if I install a compliant OpenGL 3 driver on a computer, will OpenGL 2 app’s still running??
Yes.
In order to even get a GL 3.0-compliant rendering context, you must call a special extension function (ARB_context_create). Otherwise, the context you get will be 2.1 (or lower).
Not only can 2 and 3 co-exist on the same computer… they can co-exist within a single application! If/when a future version breaks backward compatibility, legacy code can continue to run, and you can incrementally add new code which takes advantage of the new version. Switch between rendering pipelines with MakeCurrent. (This was the backward compatibility plan originally developed for Longs Peak, btw… and was approved by the same evil CAD vendors who are incorrectly credited with the ARB’s change of direction.)
If this is your biggest concern with 3.0, then I guess its not so bad after all.
So if not the CAD guys, who are then the culprit(s)?
Why, the ARB of course. And that’s all you’re getting from me, unless you want to write me a really, really big check. 
But seriously, Barthold already explained what happened here.
Okay, but it still boils down to whether or not AMD will produce working OpenGL3 drivers. Until that happens, the situation is exactly the same as before; only NVidia fully supports OpenGL. If AMD can be counted on to do this, applications can start to be written now using NVidia’s drivers, and they can just say “Requires OpenGL3 hardware/drivers” until AMD gets it together.
I have noticed ATI seems to be putting more effort into their OpenGL drivers since shortly before the AMD aquisition. They have been good at processing bug reports, in my experience, but there is still a long way to go for their drivers to be OpenGL3-compliant.
http://www.khronos.org/developers/librar…BOF%20Aug08.pdf
AMD has committed to producing OpenGL 3.0 drivers including the GL3 extensions such as geometry shader and instanced rendering.
Have they made any quality commitments?
I’m not being facetious, I really wonder if they’re going to be serious about supporting GL3. Is this profile stuff going to mean better ATI drivers? Have they said that?
Shameless plug
I have posted a list of forward-compatible core OpenGL 3.0 entry points on my blog at http://www.devklog.net/2008/08/23/forward-compatible-opengl-3-entry-points/. I will be continuing to improve that list by adding function sub-groups and additional deprecation notices related to deprecated constants.
It seems to me that these types of questions can’t really be answered until you have a release in your hands to evaluate, since they are mostly subjective. I’m looking forward to seeing what AMD comes up with as well. Since they mentioned a series of beta releases between now and their Q1 2009 goal for completion of GL3, there will likely be a few opportunities to generate feedback and test cases as we go.
Re profiles and subsetting, no profiles are yet defined beyond the base profile. Note that vendors cannot make up profiles, only the Khronos working group can. So no, I don’t see profiles having any effect on the first round of 3.0 implementations.
Thanks, that’ll be quite useful to a lot of people =)
EDIT: This is target at the non-deprecated GL3 entrypoint list. Stupid cross-posting…
Well then, my seething rage is starting to lessen, a little bit. My personal experience dealing with AMD reinforces what this slide says. Their commitment to OpenGL now appears to be much better than they committment to OpenGL one year ago, at least.
Apparently, Intel is “excited” about OpenGL 3.0, but that doesn’t really mean anything. No matter, their built-in chips wouldn’t be able to run our engine anyways. I think Intel’s “future platforms” probably means their Larabee chip.
If in q2 2009 I can revamp our renderer and get rid of most of our crazy fallbacks and hardware limitations, that would be a pretty good situation.
is there a machine readable list of all deprecated functions and enums available? (like a simple text file or header files without the deprecated functionality?)
Overall, after analyzing everything about OpenGL 3, all i can say is:
Thanks to peoples who make it possible. Yes, maybe is not perfect, or what some of us expected, but is here. I think ARB members did a great job. In the begining i was a bit angry/confused, but now i realize that having OpenGL 3 is better that nothing.
I want to apologize if i was a bit aggressive.