#### Archived

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

# GLee 2.2 is up - update: v3.0 released

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

## 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 on other sites
Cool. GLee is a very handy little thing.

##### Share on other sites
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_5typedef 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 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 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 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 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.

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 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 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 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.

1. 1
Rutin
26
2. 2
3. 3
4. 4
5. 5

• 9
• 11
• 10
• 13
• 20
• ### Forum Statistics

• Total Topics
632948
• Total Posts
3009389
• ### Who's Online (See full list)

There are no registered users currently online

×