Ugly Core Profile Creation

[Janika]

get it! so
hdll = LoadLibrary("opengl32.dll");
wglGetProccAdress = GetProcAddress(hdll, "wglGetProccAdress");
then use wglGetProccAdress...

Customized error reporting in case OpenGL is not installed.

[thokra]

Or you can simply link to the export lib and use wglGetProcAddress directly.

[mhagain]

You don't install OpenGL; OpenGL is not software and opengl32.dll will always be present (unless you really must run on pre-OSR2 Win95 or pre-NT3.5). The real question is: does the user have an OpenGL driver for their hardware? If a driver is present then opengl32.dll just acts as a proxy for the vendor's implementation, so options are to (1) check your pixel format flags, (2) check your GL_VENDOR string or (3) check for an absolutely ubiquitous extension that will be present on all civilized hardware released within the past 15-odd years - something like GL_ARB_multitexture should suffice. Of course, if you want to run on hardware older than that too then you're probably going a little too far, and will have to cope with the joyous world of minidrivers (and don't forget that some of these were game-specific and may not even have been called "opengl32.dll"), missing blend modes, software fallback left-right-and-center, and other weird behaviours from the time. Since that seems to be the OpenGL world you want to go back to, you may well welcome it! I wouldn't. But that's the only scenario in which OpenGL may be "not installed".

[Janika]

Yup. So no body can just search for OpenGL32.dll file and hit Delete?

[mhagain]

I believe that opengl32.dll is covered by Windows System File Protection, so they'll have to also disable that. If they go so far then you're dealing with active user stupidity and it's their problem, not yours.

[Janika]

Anyway after all this mess I've been through trying to find a nice way to create a core profile I came up with an idea that may work, but it worth trying. Now I fully understand that the ARB is not responsible for platform dependent stuff I thought we, OpenGL developers, who work on different platforms, could come up with a standard platform independent API for OpenGL context creation management. Then IHVs may start implementing a prototype and make it public for testing.

As a starting point, lets just forget there's OpenGL32.DLL.

All context creation functions should be accessible through Win32 GetProcAddress and before creating a context, unlike what we have now.

I suggest creating a separate forum specialized for this and all people are welcome. We need a moderator though. Any volunteer?

[Alfonse Reinheart]

I thought we, OpenGL developers, who work on different platforms, could come up with a standard platform independent API for OpenGL context creation management.

Come up with an API, or write and maintain an implementation of this API? Because just saying, "here are some functions and what they should do" will do precisely nothing. And if you're talking about an implementation, then it must run on top of the existing infrastructure (and thus is limited by that infrastructure).

[Janika]

Come up with an API, or write and maintain an implementation of this API?

First we create the specification for context management on desktop platforms, as EGL for embedded systems.

Next step, we get feedback from IHV driver developers.

Do necessary changes to the specification if there's any technical problems reported by IHVs.

Then they can start implementing it.

[Janika]

Here's something to start with:

// This approach will eliminate the necessity to create a temporary profile first 
// in order to access the new versions...
 
glDll = LoadLibrary("libgl.dll");
 
xglCreateContext = GetProcAddress(glDll, "xglCreateContext");
xglMakeContextCurrent = GetProcAddress(glDll, "xglMakeContextCurrent");
xglGetFunction = GetProcAddress(glDll, "xglGetFunction");
 
XGL_CONTEXT_DESC desc;
desc.profile = XGL_CONTEXT_CORE; // XGL_CONTEXT_COMPAT;
desc.hWnd = hWnd;
desc.FSAA = true;
desc... // Specify other parameters
 
XGL_CONTEXT ctx = xglCreateContext(&desc);
 
xglMakeContextCurrent(&ctx);
 
glXXXXX = xglGetFunction("...");
 
// Or even better, no need to have a context in order to link to all GL functions
// In this case the "libGL" file should contain all the functions in the supported version.

[Alfonse Reinheart]

First we create the specification for context management on desktop platforms, as EGL for embedded systems.

Next step, we get feedback from IHV driver developers.

Do necessary changes to the specification if there's any technical problems reported by IHVs.

Then they can start implementing it.

And how do you plan to have steps 2 and 4 work? Do you honestly expect IHVs to care about some specification written by some people on a forum? Especially when all it would do is give them more work to do?

Your basic assumption is "if you write it, they will come." That the reason we don't have this yet is because nobody has been presented with that perfect specification. And if someone were to just create that perfect specification, that perfect API design, the IHVs would see it's perfection and realize that it absolute must be implemented.

Writing a spec is not the hard part; anyone can do that. Getting everyone to agree to it and implement it in a timely fashion is. And if you're not an ARB member or someone with inside knowledge and contacts with ARB members, you're not going to get it implemented, period.

Your problem is that you have all of these idealistic visions and lofty ideas, but absolutely no workable plan for getting them done. Your basic "plan" can be boiled to:

1. Write a spec.
2. ...
3. Profit!

That's not exactly a workable plan for achieving something.

Step 1 for any such plan is to get the IHVs on-board immediately. Because if they're not on-board, nothing gets done. And if you do not have a means to achieve this, then nothing is going to happen.

Here's something to start with:

Well let's see.

You used a HWND in what is supposed to be a cross-platform API (not to mention the lack of any HDC, which is very important). You use a binary true/false for "FSAA" when multisampling has many possible variations, including number of samples. And worst of all, you used a fixed-size struct for what should be an extensible context creation mechanism, thus destroying any possibility of extending it without writing a new context creation function. Even in D3D, the first parameter of most structs is the size of the struct, so that later they can make the struct bigger, and the function can tell which struct you passed in based on its size.

In short: all of this API is terrible.