Interest in specialized GL function loader.

Quote:

---

Originally Posted by thokra

He said quite clearly, provide a basic version(core or compat) which would be a mutual exclusive switch and perhaps default to core if not specified and a list of extension.

---

Do you think 90% of people trying to use OpenGL know what extensions they need? I wouldn't bet on it.

Quote:

---

Originally Posted by thokra

The problem with your suggestion is that code needs to exist so you can run the script. What if you start a new project and you know you're gonna need a GL4.3 core header? What code is there to parse?

---

Yes, it requires a code. A new project does not have any GL calls so there is no need for the extensions either. Only oglext.h, for example, should be included, and before compilation that function loader should be called (and it would fill oglext.h/.cpp). It could be some kind of plugin for VS, but it is better having a platform independent tool.

Quote:

---

Originally Posted by thokra

I guess you mean a native executable.

---

Yes, I still think it is a better solution. Alfonse would probably provide both code and executable for Windows. Knowing myself and many programmers around me, a executable is much better solution (if it works correctly), than having a code that have to be compiled, or script that requires its on environment.

Quote:

---

it is much better to parse all files in the project searching for the GL calls and generate two files (.h/.cpp or .c) with appropriate pointers.

---

There are two major problems my tool is intended to solve:

1: Less-than-helpful IDE code completion. Using an all-in-one solution means that typing "gl" or "GL_" will cause your IDE to suggest everything. With this tool as I defined it, you can at least restrict it to a specific subset that you consider valuable, thus getting rid of 90+% of the IDE suggestions you won't be using.

2: Preventing you from accidentally using something you don't want to. If you forget that most 3.x hardware doesn't support ARB_draw_buffers_blend, and you use it, an all-in-one solution will just assume you know what you're doing.

The tool as you want it will undermine both of these. Your parse-generated header is based on existing functions/enums. OK, but that doesn't solve the problem of using a function I've never used before. The IDE will be massively unhelpful until I type the name and run the parse-generator again. If you already have a codebase that uses all of the functions you intend to use, then you're OK, but if you're trying to get to that point, it's all a big pain.

Further, your tool has no provisions to prevent you from accidentally using functions you don't want to use. Indeed, it will "helpfully" generate functions/enums for anything you ask of it. Thus it acts exactly like the all-in-one tool.

It's just not solving the problems of interest.

Quote:

---

Do you think 90% of people trying to use OpenGL know what extensions they need? I wouldn't bet on it.

---

True. But I bet that those 90% also don't care. They're probably happy with a "give me all of OpenGL" loader. They also wouldn't want to set up an automated code-generator that they have to run every time they use a new OpenGL function. Nor would they likely be willing to install a plugin into their IDE of choice (assuming that their IDE supported such a plugin).

The people who don't know what they want already have a tool. This tool is for the people who do know what they want.

Quote:

---

Could you make command prompt applications instead of scripts? Some of us are allergic on LUA/PHP/Ruby solutions.

---

There are limits to how much I'm willing to accommodate people's eccentricities. Small applications are already being written entirely in scripting languages. A major distributed VCS is mostly written in Python, and the main GUI for it is almost 100% Python. So the sooner they get over this nonsense the better.

I'm not going to take my perfectly functioning code generation Lua code and port it all to C++ just because some people want to write "ExeName -options" instead of "lua LuaName.lua -options". And if someone is really that lazy (yet is somehow perfectly willing to build such an application), then I'm fine with them not using my code.

Having a targeted loader is something I have always wanted and had mused about doing it - so I am glad someone is going ahead.

Just a crazy thought, could this be run on a web server somewhere (perhaps - dare I suggest even Opengl.org?)
You have a web page that lists the versions/extensions with check boxes and then download the generated zip?

Could it? Yes.

I have absolutely no idea how to go about doing that of course. But it could certainly be done. It's going to be a simple command-line script, and the outputs should be readily identifiable via tool. The hard part (from my perspective) is the input/output part: building the web page, getting data from it to the server so that it runs the tool, and returning that data to the user. I know nothing about any of those processes.

I would find such tool very useful. Especially if it could generate a C++:ish interface that puts everything in a gl namespace.

It would be even more useful if it had some support for multiple rendering paths using different OpenGL versions in the same program. So when I program for example the GL 2.1 path, it would prevent me from using GL 3 stuff, etc.

Sorry, Alfonse! I didn't get the point of your tool at first glance. I was not aware of the intention to confine IDE code completion to a predefined GL version. What I proposed is the absolute minimal function importer regardless of GL version.

I'm just curious, how do you plan to handle vendor specific and/or experimental extensions? Would it be used for the core functionality only?

Quote:

---

It would be even more useful if it had some support for multiple rendering paths using different OpenGL versions in the same program. So when I program for example the GL 2.1 path, it would prevent me from using GL 3 stuff, etc.

---

I suppose you could generate two sets of headers/loaders, each exposing different versions of OpenGL and sets of extensions. To do this, I need to expose a way for two loaders to co-exist in the same exe (ie: don't stomp on each others' global variables/functions).

I should do that.

Quote:

---

I'm just curious, how do you plan to handle vendor specific and/or experimental extensions? Would it be used for the core functionality only?

---

You list the extensions of interest, either on the command-line or via a file.

I normally write my own loaders for opengl functions. Like I have a self contained FBO class that loads its own extensions. Just makes life easier for me. A lot easier re-using them in different projects too.

OK, so a basic implementation is now available. Feel free to download it and have a go. The link goes to a page explaining the basics of how to use it.

Not much has been tested. I ported a basic GL 3.x "Hello World" application to it, so I can verify that it does compile and generate code well enough to load functions. I verified that the WGL generation compiles, but I haven't tested using it. I have absolutely no idea about the GLX stuff (I'm between Linux distros: fed up with Ubuntu's Unity garbage, but not enough free-time to install Linux Mint yet).

It's actually pretty amazing how small the OpenGL headers are when you're not importing hundreds of extensions that you really don't care about.

Feel free to drop off bug reports for anything that doesn't work. Especially on Linux, which I haven't been able to test yet.

Quote:

---

Originally Posted by Alfonse

fed up with Ubuntu's Unity garbage

---

Simple solution: Use Kubuntu. ;)

Gonna check it under Linux tonight.