Ugly Core Profile Creation

[Alfonse Reinheart]

While struggling with running my own OpenGL API loader

What is it with people who want to constantly reinvent the wheel? The only reason I wrote an OpenGL loader was because GLEW was (and still kinda is) flakey with regard to core OpenGL function loading. I also took the opportunity to separate out core and compatibility so that you could get a core-only header if you choose to.

Trust me: writing your own loader will not give you wisdom. Completing this task will not move you towards enlightenment. It is not a worthwhile exercise that every OpenGL programmer should undertake. Use libraries to make your life easier; that's what they're there for. You should only write your own if there is some feature that you absolutely need which current GL loaders do not provide.

[Janika]

What is it with people who want to constantly reinvent the wheel?

Simply because the wheel they want to reinvet sucks.

Trust me: writing your own loader will not give you wisdom. Completing this task will not move you towards enlightenment. It is not a worthwhile exercise that every OpenGL programmer should undertake. Use libraries to make your life easier; that's what they're there for.

I would agree if there were an official (provided by the ARB) well maintained "library" or headers, up to date and clean.

[thokra]

Simply because the wheel they want to reinvet sucks.

Which wheel? GLEW? Well, did you ever think about just not creating a core context? Unless you can proove with hard facts that you get anything out of creating a core context performance wise, then just use a compat context und GLEW. Developing core conforming GL apps doesn't mean you need a core context. There are many, many OpenGL apps out there using GLEW. In this case my personal advice is: Don't blame your tools.

I would agree if there were an official (provided by the ARB) well maintained "library" or headers, up to date and clean.

There has never been an official loader. We've seen this discussion many times and the verdict always is: There's enough out there which works perfectly fine.

[Janika]

Unless you can proove with hard facts that you get anything out of creating a core context performance wise, then just use a compat context und GLEW.

There has never been an official loader. We've seen this discussion many times and the verdict always is: There's enough out there which works perfectly fine.

[thokra]

Uhm ... ok ...

[Alfonse Reinheart]

Simply because the wheel they want to reinvet sucks.

Reiterating Thokra's question, which one? There are quite a few options available to you. Are you telling me that out of all of these options, none of them do what you need? Why? What exactly is missing from them?

Or to put it another way, what is your tool going to do that none of those other tools do?

[mark ds]

Janika has got a valid point.

Current OpenGL is a pain in the arse to deal with. I personally have my own "opengl42.h", "opengl3.3.h" and "opengl3.0.h" headers, each of which includes a small class to enable functionality and to allow querying of extensions.

Yes, there are many ogl loaders, but none of them actually *work* all the time. Defending them is pointless.

What is actually needed, is an ARB dll which does the work for a user, and returns valid function addresses depending on the context version required.

[Alfonse Reinheart]

Yes, there are many ogl loaders, but none of them actually *work* all the time.

Here's an idea; I know it's kinda crazy but bear with me.

Explain how they don't "actually *work* all the time."

Simply stating that there's a problem isn't a way to get it fixed. Go to the GLEW guys and write them a bug. File a bug in the SDK. If you find a failing in a loader tell someone; don't just keep it to yourself.

Or even better, why don't you fix the problems in the loaders, and then make patches and submit them to their various maintainers.

What is actually needed, is an ARB dll which does the work for a user, and returns valid function addresses depending on the context version required.

Well that's not going to happen. The ARB isn't going to write code for us. So you can continue to write it yourself, or you can actually do something productive to the "not you" demographic.

I hear a lot of talk on this forum about how "somebody ought to do something about X." But when push comes to shove, when it comes down to actually getting something done, it's all talk, no walk.

We get the OpenGL that we have built. Which means we have the OpenGL we deserve. If you want it to be better, then do something useful about it.

Otherwise quit complaining.

[mark ds]

This was a joke post, yes?

"Explain how they don't "actually *work* all the time."

It never works... call a function that isn't supported, means you call an unsupoorted function! Gl_ERROR vs not supported. Call a Win16 function... it won't work - rather than trick you into thinking it *does* work.

As to your reference to the GLEW library, I've never used it. Because it is out of date! It's always out of date. Is that so hard to understand?

The ARB *SHOULD* write code for us. The future of OpenGL depends on it.

More to the point - if you read my post, you'd understand that I *have* alreay written my own code to support the various Gl versions!


Maybe you don't appreciate the size of the problem. OpenGL faces D3D. Which works. out of the box. No fucking around. OpenGL doesn't. Which is wholly down to the ARB. This is a driver API, not an OS one. Why don't the ARB see this?

[Alfonse Reinheart]

It never works... call a function that isn't supported, means you call an unsupoorted function! Gl_ERROR vs not supported. Call a Win16 function... it won't work - rather than trick you into thinking it *does* work.

I don't understand what you're saying. What do you mean by "a function that isn't supported?" And what does Win16 have to do with OpenGL?

As to your reference to the GLEW library, I've never used it. Because it is out of date! It's always out of date. Is that so hard to understand?

It is? In what way is it out of date? It seems to work. It has some quirks with core contexts, but they have a workaround for it, and it's documented. So in what way is it out of date?

More to the point - if you read my post, you'd understand that I *have* alreay written my own code to support the various Gl versions!

Yeah, so have I. Unlike you however, I documented my code and gave it away, thus solving the same problem for other people.

What have you done to make OpenGL better for others?

Maybe you don't appreciate the size of the problem.

I understand the problem. But complaining about it isn't solving it.

This "problem" has existed since OpenGL 1.2 fourteen years ago. The ARB hasn't solved it. When someone hasn't done something for 14 years, you might think it would occur to people that this means they aren't going to solve it. So either we, the OpenGL community, gets together and solves it, or nothing is going to change.

I'm doing my part. The folks who maintain GLEW are doing their part.

Are you going to pitch in? Or are you just going to sit on the sidelines and complain while nothing gets done? If you are, I wish you'd do it somewhere else; the complaints to nobody that's listening are becoming tiresome.

The future of OpenGL depends on it.

Please. The "future of OpenGL" is exactly where it is today, regardless of what the ARB does. Do you think that if there were some widely adopted library for loading functions (which GLEW technically is, since 90+% of tutorials will direct you to it) that this would magically cause AAA game developers to start using OpenGL? That it would increase OpenGL usage among people who don't already use it?

No. People aren't going to rewrite their codebases to use OpenGL just because we have a function loading API signed off on by the ARB. OpenGL is the only means for accessing hardware accelerated 3D graphics on non-Windows platforms. In most cases, this is the only reason it is used: to write platform-neutral 3D code, or to write Linux/MacOSX-specific 3D code.

So either the scope of your project requires OpenGL (because it's on a platform where there are no alternatives), or you're using Direct3D. That's not "the future"; that's the last 5 years.