PDA

View Full Version : My suggestions



Dardan
03-04-2012, 12:51 PM
OK. So as far I as I have experienced the OPenGL API, I really find this API very powerful. But there are some weak points I like to see improving:
- The extensions, I really don't get why you should call extensions in such a rather elaborated way. Can't there be a function inside the APi which can enable the extensions directly?
- The versions, OpenGL GSLS etc. all these varialbes + the available extensiosn. You should generalise this more. I tried to make an app which shows all the extensions, though I later found out you also should call wgl as well, to get the complete list on windows. Why this? And I tried to get the shader langauge. I used glgetstring, but I didnt got any result!!! I cant believe that. So i used glew, a kind of 3rd party OpenGL library which could find it. I really wish to see a more generalised and centralised version!!!

Dardan

kRogue
03-04-2012, 02:06 PM
- The extensions, I really don't get why you should call extensions in such a rather elaborated way. Can't there be a function inside the APi which can enable the extensions directly?


The point of extensions are to allow vendors to offer functionality above and beyond the OpenGL specification. Except for those extensions affecting GLSL, there is not some something to "enable" and extensions. Indeed, extensions, again outside of those affecting GLSL, are of the following forms:
New functions. The function pointers are fetched by a platform specific call. For MS-Windows it is a wglGetProcAddress, for X11 it is glXGetProcAddress (or possibly glxGetProcAddressARB). Allowing for existing functions to take on new/more values which in turn does new stuff or allows for new/more stuff A combination of both of the above.
Extensions might affect many portions of GL operation or very few or even be relatively isolated. It depends on the extension.


To see what extensions are available there are two choices:
glGetString(GL_EXTENSIONS). This will return a long string, the contents of the string are space separated labels, each label corresponding to an extension. The documentation of the extensions can be found at the OpenGL Registry (http://www.opengl.org/registry/). The main ugly with using glGetString(GL_EXTENSIONS) is that it is all extensions listed space separated and it is deprecated in core profiles. glGetStringi(GL_EXTENSION, i) with 0<=i<M, where M is from glGetIntegerv(GL_NUM_EXTENSIONS, &amp;M). This is the "preferred way", and found in GL3.x and higher.


For extensions that affect GLSL, the GLSL specification specifies the "#extension" jazz which allows for a blob of GLSL code to enable, require or disable a named extension.



- The versions, OpenGL GSLS etc. all these varialbes + the available extensiosn. You should generalise this more. I tried to make an app which shows all the extensions, though I later found out you also should call wgl as well, to get the complete list on windows. Why this? And I tried to get the shader langauge. I used glgetstring, but I didnt got any result!!! I cant believe that. So i used glew, a kind of 3rd party OpenGL library which could find it. I really wish to see a more generalised and centralised version!!!


There are two ways to get the GL version:

glGetString(GL_VERSION) gives a human readable string with version number (i.e. what version of the specification it is) plus extra bits of info glGetIntegerv using GL_MAJOR_VERSION and GL_MINOR_VERSION to just get numbers.

The reason why there are version numbers is because there are different generations of hardware (and drivers to drive them). To get the shading language version number, as a string, use glGetString(GL_SHADING_LANGUAGE_VERSION). The GLSL version is typically tied to the GL version.. though one can use a different version of GLSL than the "default" as reported by glGetString(GL_SHADING_LANGUAGE_VERSION) by using "#version" in one's GLSL source.

Lastly, all the GLEW really is a bit of header file/macro jazz that fetches functions pointers for you. Nothing more.

As a side note, there is an OpenGL Wiki (http://www.opengl.org/wiki/) and an article (http://www.opengl.org/wiki/OpenGL_Loading_Library) on the wiki detailing this.

In all nasty, brutal honesty, it is not exactly rocket science to set up one's own automagic system to get the function pointers.

Alfonse Reinheart
03-04-2012, 06:49 PM
As a side note, there is an OpenGL Wiki and an article on the wiki detailing this.

There's also the article that explains how to manually load these functions (http://www.opengl.org/wiki/Load_OpenGL_Functions).

V-man
03-04-2012, 06:50 PM
This thread sounds like http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&amp;Number=243517&amp;page=1

That last few pages where Brandon J posts and the conversation after that.

Dardan
03-06-2012, 12:08 AM
Ok, but it is confusing in my eye, loading all these function pointers. Though I managed to retrieve and order the extensions available on a OS, I heard that you need a wgl version to get "the real full" list on windows.

Anyway, OpenGL is a lowlevel API, so I shouldn't expect a lot of these precoded functions etc. Though it would make life a lot easier.

V-man
03-06-2012, 02:52 AM
Ok, but it is confusing in my eye, loading all these function pointers. Though I managed to retrieve and order the extensions available on a OS, I heard that you need a wgl version to get "the real full" list on windows.

Yes, that is correct for windows.
On AOS, it isn't like that?