I’m surprised that nobody’s spoken about this , even though it’s been on the main page for days.
In any case, here’s my take.
Good:
-
The existence of the newsletter itself. I’m very glad to see some form of communication out of the ARB.
-
Bill Licea-Kane’s section. Now, the information contained in his section on New Texture Functions frightens me to say the least. No, what I like about it is that someone’s taking the time out to educate us on something that is an implementation detail so that we can avoid pitfalls in the future. This is all to the good, and I wouldn’t mind seeing more in later newsletters/the SDK.
-
Doing away with the old-and-busted OpenGL state-based object model. I’m all for that.
Neutral:
- ARB merging with Kronos. They didn’t exactly explain what this would do for OpenGL very well. The substantive question, to my mind, that was not answered was, “Does this mean that greater resources will be devoted to OpenGL in the future?” The biggest problem with the ARB, from an outsider’s perspective, seems to be just the lack of resources they have. They’re a volunteer service; a member can’t actually take the time to write an SDK, because each of these people have tasks for their respective companies to perform. Does Kronos have an actual Kronos-only staff that would be responsible for such tasks as the SDK?
Bad:
-
The substance of Bill’s article. Isn’t this the kind of thing that an abstraction should, you know, abstract? Really, is this something that a high-level language should force upon the user? Sure, the user should have texture+derivative texturing functions. But for them to have to specify them explicitly just because of a varying in a conditional? It’s not like a varying is a runtime-thing; you knew it was a varying when you compiled the shader. Come on, guys; you can do better than that.
-
Doing away with the old-and-busted OpenGL state-based object model. That’s going to be one brutally massive extension, if this will extend to all objects everywhere. It may as well be a new API, because that’s what it will be.
-
Speaking of which, absolutely nothing was said about the most important thing in that GameDev article: the new API. Is it coming? Is it going to be some ES/GL merger? What’s going on in this department? The new API is the future of OpenGL; it’d be really nice if you could tell us something more substantial than that article did (like, whether it’s still happenning, etc).
Comically Ironic:
- Superbuffers Working Group Update. They’re making a new OpenGL object model. And the async guys are going to use it for their async thing. Good for all involved.
It’s funny; I seem to recall that we already had a new OpenGL object model. It did everything that the Superbuffers people needed. It was even implemented and well-proven with the ARB-extension verison of glslang.
But the ARB decided to throw it away in favor of the old-and-busted state-based version. Allegedly because maintaining 2 object models would be considered confusing to the user (also funny, considering that’s what they’re doing now).
Maybe if they hadn’t done that, and instead used the new one in all core 2.0 technologies, we wouldn’t need to be making a second new object model.