Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

benjamin bunny

GLee 2.2 is up - update: v3.0 released

This topic is 5329 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

GLee 2.2 is complete. It has full support for OpenGL 1.5, and supports all these extensions. If anyone needs a way to link extensions automatically, this library may come in handy. UPDATE: I've just finished GLee 3.0, and it deals with all the issues raised in this thread, including the missing WGL extensions and C compatibility issues (the library is now written in pure C). It looks stable to me, but more testing is always appreciated. [edited by - benjamin bunny on January 15, 2004 8:48:22 AM]

Share this post


Link to post
Share on other sites
Advertisement
I tried building with it and ran into one minor issue.

When the compiler gets to the following lines:
//Additional types needed for extensions
#ifndef GL_VERSION_1_5
typedef ptrdiff_t GLintptr;
typedef ptrdiff_t GLsizeiptr;
#endif
ptrdiff_t isn't defined. It gets defined a few lines later when stddef.h is included, so if you move that up it compiles and works without a problem (other than a few warnings in VC6 due to indentifier truncation).

Share this post


Link to post
Share on other sites
quote:
ptrdiff_t isn''t defined. It gets defined a few lines later when stddef.h is included, so if you move that up it compiles and works without a problem (other than a few warnings in VC6 due to indentifier truncation).

Thanks. For some reason it compiled on my system, so I probably wouldn''t have noticed that if you hadn''t pointed it out. The 2.21 version fixes the problem.

Share this post


Link to post
Share on other sites
Just out of curiosity, what is the purpose of the ifdef __gl_h_ #error #endif set of pre-processor directives in the GLee.h header? That check gave me a bit of trouble until I commented out the #error after building from source for Linux, due to where in my project I included the GLee initialization and checking functionality. The other directives were okay, since I don't include any of the other headers (glext, etc...). Will Bad ThingsTM result from me commenting out that #error directive? GLee.h #includes gl.h almost immediately after the check, so I figure I should be okay, but...

Anyway, great job and thanks for saving me a bunch of work. My version of glext.h doesn't include most of the newer extensions stuff, and I'm getting ready to start playing with vertex programs, so GLee will come in handy...

Josh
vertexnormal AT linuxmail DOT org


Check out Golem: Lands of Shadow, an isometrically rendered hack-and-slash inspired equally by Nethack and Diablo.

[edited by - VertexNormal on January 14, 2004 9:49:08 PM]

Share this post


Link to post
Share on other sites
quote:
Just out of curiosity, what is the purpose of the ifdef __gl_h_ #error #endif set of pre-processor directives in the GLee.h header? That check gave me a bit of trouble until I commented out the #error after building from source for Linux, due to where in my project I included the GLee initialization and checking functionality. The other directives were okay, since I don''t include any of the other headers (glext, etc...). Will Bad ThingsTM result from me commenting out that #error directive? GLee.h #includes gl.h almost immediately after the check, so I figure I should be okay, but...

The point is to stop you including GL.h and just include GLee.h instead. But do it your way if it works.

Share this post


Link to post
Share on other sites
Yeah, I figured that''s what it was. That''s why I went ahead and changed all of my gl.h includes to GLee.h. Search and replace wasn''t really all that hard.

But thanks for the reply.


Josh
vertexnormal AT linuxmail DOT org


Check out Golem: Lands of Shadow, an isometrically rendered hack-and-slash inspired equally by Nethack and Diablo.

Share this post


Link to post
Share on other sites
Hi Ben

Just wanted to say, congrats on GLEE, it certainly has saved me a lot of time.

I noticed in your extensions list it doesn''t have support for
* WGL_EXT_swap_control
I had to fiddle around with the GLEE header to get this to work -any chance of fixing this?

Also, is there any way you could create a non-STL version of GLEE? (Everytime I upgrade to a new version of GLEE, I have to convert from STL to standard c stuff - as I am trying to avoid STL)

Cheers
FReY

Share this post


Link to post
Share on other sites
no offense, but why should we prefer GLee over GLEW (glew.sf.net)? i mean, do you have some kind of feature comparison table?

[edited by - eyebex on January 15, 2004 3:28:25 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by eyebex
no offense, but why should we prefer GLee over GLEW (glew.sf.net)?


For one thing, the function names are the same in GLee as in OpenGL, which means you have transparent support for OpenGL versions after 1.1.

GLEW on the other hand, prefixes all function pointers with "glew" in order to avoid naming conflicts at link time (a problem on Unix/Linux systems apparently). GLee gets around this problem by declaring the function pointers with a prefix and using #defines to rename function names at compile time (eg: #define pglMultiTexCoord2f glMultiTexCoord2f).

Having function names the same as they''re defined by OpenGL is pretty useful, especially if you''re developing cross-platform. For example, if you''re developing on a system with native OpenGL 1.1 support and GLee, and a system with native OpenGL 1.3 support and GLee, the 1.2 and 1.3 functions will be the same on both systems.

Aside from that, there''s not much to choose between them, except that GLEW currently supports more platforms. GLee could probably be persuaded to compile on Apple, SGI etc, but without access to such machines, it''s not possible to test, and besides, nobody has requested it yet.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!