Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


http://www.opengl.org/registry/ABI relevance


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 15 September 2012 - 09:35 AM

Is http://www.opengl.org/registry/ABI still up to date? What confuses me is that:

3.4. The libraries must export all OpenGL 1.2, GLU 1.3, GLX 1.3, and ARB_multitexture entry points statically.
It's possible (but unlikely) that additional ARB or vendor extensions will be mandated before the ABI is finalized. Applications should not expect to link statically against any entry points not specified here.

Does that mean any core functionality for OpenGL 2 and higher should be accessed by glXGetProcAddress() (Yet its defined in gl.h/glext.h)?

Also should I explicitly load anything with glXGetProcAddress() if all the prototypes are actually defined in glext.h? I am not talking about checks for extention support but about linking.

Sponsor:

#2 ic0de   Members   -  Reputation: 909

Like
0Likes
Like

Posted 17 September 2012 - 06:30 PM

Just make it easy for yourself and use GLEW http://glew.sourceforge.net/

you know you program too much when you start ending sentences with semicolons;


#3 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 22 September 2012 - 11:01 AM

Just make it easy for yourself and use GLEW http://glew.sourceforge.net/

glew is a nice helper library but still I want to figure out ho to do things properly without external dependencies.

#4 clb   Members   -  Reputation: 1787

Like
0Likes
Like

Posted 22 September 2012 - 11:37 AM

On Windows OpenGL 3, I have had to resort to using GLEW. On Mac OS X with OpenGL 3, I have not needed to query any entry points or use GLEW, just including the headers has worked for me so far (although I don't know if there are some extensions for which static linking doesn't exist on OS X). On Android and iOS with GLES 2, I haven't needed to query any entry points either, and just including the headers and linking statically has been enough.
Me+PC=clb.demon.fi | C++ Math and Geometry library: MathGeoLib, test it live! | C++ Game Networking: kNet | 2D Bin Packing: RectangleBinPack | Use gcc/clang/emcc from VS: vs-tool | Resume+Portfolio | gfxapi, test it live!

#5 tanzanite7   Members   -  Reputation: 1378

Like
0Likes
Like

Posted 22 September 2012 - 12:13 PM

glew is a nice helper library but still I want to figure out ho to do things properly without external dependencies.

Then you have to do what glew does yourself - there is no other way.

Read http://www.opengl.or...tting_Functions for more information.

Edited by tanzanite7, 22 September 2012 - 12:19 PM.


#6 mhagain   Crossbones+   -  Reputation: 8271

Like
0Likes
Like

Posted 22 September 2012 - 12:30 PM


Just make it easy for yourself and use GLEW http://glew.sourceforge.net/

glew is a nice helper library but still I want to figure out ho to do things properly without external dependencies.

I wouldn't call GLEW an external dependency - since the number of entry points is so huge an extension loader is more of an essential tool.

Sure, if you want to know how it's done, then try it out for a few - up to, say, GL1.5 - then say "life's too short to load this crap by hand" and spend your time being productive instead. :)

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#7 Chris_F   Members   -  Reputation: 2459

Like
0Likes
Like

Posted 23 September 2012 - 12:42 PM

Well, on Windows, OpenGL32.dll only exports OpenGL 1.x functions which makes it absolutely mandatory to use wglGetProcAddress if you want to use anything newer than 1.x.

It's probably different with Linux because as far as I know ELF automatically exports all functions from a shared library.

#8 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 24 September 2012 - 12:26 PM

Then you have to do what glew does yourself - there is no other way.

Read http://www.opengl.or...tting_Functions for more information.


See, there is a point in clb's post:

On Mac OS X with OpenGL 3, I have not needed to query any entry points or use GLEW, just including the headers has worked for me so far (although I don't know if there are some extensions for which static linking doesn't exist on OS X). On Android and iOS with GLES 2, I haven't needed to query any entry points either, and just including the headers and linking statically has been enough.


The same approach works for GNU/Linux, hence the question: Also should I explicitly load anything with glXGetProcAddress() if all the prototypes are actually defined in glext.h and imlicit linkage suits my needs?

#9 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 24 September 2012 - 12:34 PM

I wouldn't call GLEW an external dependency - since the number of entry points is so huge an extension loader is more of an essential tool.

Well lots of extentions have been adopted into OpenGL core and currently I am planning to use a couple of them only.

Sure, if you want to know how it's done, then try it out for a few - up to, say, GL1.5 - then say "life's too short to load this crap by hand" and spend your time being productive instead. Posted Image

You live only once :)

#10 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 24 September 2012 - 12:38 PM

On Windows OpenGL 3, I have had to resort to using GLEW.

Well, on Windows, OpenGL32.dll only exports OpenGL 1.x functions which makes it absolutely mandatory to use wglGetProcAddress if you want to use anything newer than 1.x.

Thats sounds bad. I have no Windows under my hand to check stuff but AFAIK default OpenGL32.dll should be owerwritten with `native' version on video driver installation so imlicit linkage without wglGetProcAddress should work, right?

#11 Brother Bob   Moderators   -  Reputation: 8570

Like
0Likes
Like

Posted 24 September 2012 - 12:42 PM

No, they should not. Windows provides opengl32.dll as a part of their OpenGL system and drivers provide a layer on top of this dll. Your program communicates with opengl32.dll, and opengl32.dll communicates with the driver.

#12 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 24 September 2012 - 01:14 PM

Ok, so what we got:
- on UNIX based platforms OpenGL can be used as any other library: headers and dynamic librarires are shipped with vendor's video drives (nvidia or ati binary drivers) or with mesa (if we go free software way) so all we need to do is include gl.h, glext.h and link our application with libGL.so (still we need to check if our HW supports opengl extentions we need, glGetString(GL_EXTENSIONS) + search does the trick).
- on Windows platform we are stuck to wglGetProcAddress as OpenGL32.dll only exports OpenGL 1.x functions.
On the other hand all the troubles can be eliminated with glew library.
Correct me if something is wrong.

#13 tanzanite7   Members   -  Reputation: 1378

Like
0Likes
Like

Posted 24 September 2012 - 02:24 PM

Nope, i got nothing to add now. :)

PS. glew is not the only option (although i would recommend it over others because of it extensive coverage), the link i gave previously gives a few alternatives also (which may or may not be more suitable to you).




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS