Suggestion for the SDK

Would not be nicer to include the following:

The latests OpenGL Red/Blue/Orange books as open pdf versions?

Thanks.

Would not be nicer to include the following:
I’d prefer that they included an actual SDK (as in, a kit people can use to help develop software), rather than a list of reference pages and some links to external code. What they have now is a Joke Development Kit.

In any case, the man pages serve adequately to replace the reference manual.

Originally posted by Korval:
[quote]Would not be nicer to include the following:
I’d prefer that they included an actual SDK (as in, a kit people can use to help develop software), rather than a list of reference pages and some links to external code. What they have now is a Joke Development Kit.
[/QUOTE]Agreed

I agree with Korval; I’m hoping with the changes coming in Longs Peak and Mt. Evans and the (as I read it) move away from the opengl32.dll/lib dependancy we currently have a REAL SDK can be turned out along with the collection of everything in one place online, docs wise.

I’d prefer that they included an actual SDK
Please enlighten me: What would be included in an actual SDK?

Well, the most interesting bits of the DX SDK are the libraries, documentation, samples, and tools. Of the tools, the most interesting is PIX, a source-level debuger/profiler.

But the fact of the matter is that all this stuff is available for OpenGL, just not in one tidy download (this would be nice), and not in the same formats. The differences in utilities really have more to do with the nature of the API itself, like an offline compiler, which obviously doesn’t make sense in GL (yet).

Other than that sort of thing, I think it’s mostly psychological :wink:

Other than that sort of thing, I think it’s mostly psychological :wink:
That’s what I figured :wink:

So what people really want is not content, but an automatic setup program that installs everything for them, and preferably also reads the wiki and a few beginner tutorials :stuck_out_tongue:

just not in one tidy download (this would be nice), and not in the same formats.
Yes. The entire point of asking for an SDK was to create a one-stop-shop for getting started with OpenGL. You download and install this one thing, and you are ready to go in developing your OpenGL applications.

Making a web-page with some reference documentation and a bunch of links is not an SDK.

again, I totally second Korval; online references are nice and all but nothing beats having a real SDK on your machine with all you need in one place.

A real GL SDK would be:

1 - the drivers ICSs which are already there
2 - OS specific interface libraries: please update opengl32.dll, or provide one by the ARB/Khronos or whatever…
3 - Documentation:
Specification (OK)
Red
Blue
Orange books in pdf format (and the latest)
NO ONE MENTIONED THAT

please update opengl32.dll
I’m pretty sure it’s been stated many times that they legally can’t.

At least the ARB/Khronos or whatever…should be responsible for maintaining an up to date .lib .so or whatsoever…for every supported platform.

But the best thing to have again the SDK is a true docs like in the DX SDK, red/blue/roange books for free.

I wouldn’t hold my breath for the free books.

Besides, GL documentation is second to none. The DX SDK docs are mighty thin compared to what you get in the specs, damn near invisible.

But the best thing to have again the SDK is a true docs like in the DX SDK, red/blue/roange books for free.
There’s too much money to be made in selling actual books to give them away for free. That being said, one can go pretty far in terms of a manual without getting into the book range. And modern GL 2.1 really needs a good introductory text; Longs Peak won’t need as much of one because of what it is.

The DX SDK docs are mighty thin compared to what you get in the specs, damn near invisible.
They may be thin on the deep specifics, but they’re great reference for an API.

Specifications are written for implementors, not users of the implementations. And the OpenGL spec may be comprehensive, but it’s also incredibly dense and foreboding to actually sit down and read. As a manual, it’s terrible.

As a reference text, it’s even worse. Because it’s written for people making implementations, finding the specifics of how something works will often require jumping back and forth across multiple chapters just to piece together some information. A good reference manual (see the current pages on the OpenGL “SDK”) deals in functions and what they do, not “state” or other details that only implementers need to know.

Well, put it this way: Given a choice, I’d take the GL specs over the DX docs any day.

The GL reference pages give a nice overview of things, so you get that, plus the deep thoughts in the specs, for when a light synopsis just won’t do. You don’t even have that option in DX, and that kind of concrete detail is really valuable at times, sorely missed when it’s not there, yet all too easy to take for granted when it is.

I mean it’s nice if the authors giveaway the rights to get those books as pdf included in the SDK. Those are the only official books that describe the language for the users, in addition to the inner details provided by the specs. The spec manual does tutor or give step by step detail of the pipeline…

That really would be so generous from the authors.

2 - OS specific interface libraries: please update opengl32.dll, or provide one by the ARB/Khronos or whatever…
The extension mechanism is NOT a workaround for not updating opengl32.dll.

Imagine Khronos would really update the dll (giving it a new name, because the old dll can’t be changed as it is part of windows). Let’s say this dll would support OpenGL 2.0. When you use this dll, your program won’t work on any hardware that doesn’t support OpenGL 2.0. It won’t even start, because the DLL is not there. You have no chance to give a sensible error message to the user, let alone code a fallback path.

Have a look at Linux: There is an extension mechanism there, too, even though the .so is regularly updated.

Ok, for Longs Peak it’s a bit different, one could argue for a new .dll there. But for Mt Evans and every following version you have the same problems.

Glfreak, just for kicks, what exactly would go into the dream SDK, and precisely in what formats?

And please, no more ruminations from never never land about free books, or complimentary happy meals from McDonald’s.

Heh, I don’t mean to be a jerk bonehead, but you state:

Glfreak, just for kicks, what exactly would go into the dream SDK, and precisely in what formats?
The “dream” portion tells him to ignore reality. Then, in the second statement:
And please, no more ruminations from never never land about free books, or complimentary happy meals from McDonald’s.
you tell him to be realistic. You may want to revise your statement since you’re presenting him with contradicting goals.

ok then. I would love to be able to PURCHASE electronic versions (pdf) for the 3 books.

The idea is not getting something free. It’s about making the SDK more integrated and professional.

Thanks.