Register
Events
Popular
More
Post #1
Hello. I've created an OpenGL loading header-only library (a GLEW alternative if you will). It is designed to be lighter and possibly faster then GLEW at the expense of being much, much less user-friendly (it also involves a lot more typing). It's really designed for someone like myself who would love to write a loading library that has a flexible OpenGL version control system but don't love to type function names and types for thousands of extensions. As mentioned you can control precisely which OpenGL extensions and core versions you want. It works via the macro LIFT_FUNCTION which provides three things about every OpenGL function up to version 4.2; it provides their name, type, and a unique numeric identifier increasing by version I use as an error code. This system is further explained in the documentation (readme.txt) and there is an example document included with it. Keep in mind to use this library you should have a full knowledge of the OpenGL extension system. The documentation does not cover Macintosh, but with proper knowledge it could be made to work on that platform. Again this is for major projects, so if you just need something small 'n' simple use GLEW. If you are writing a game engine and plan on selling the game you may want to consider this.
Lift can be downloaded from this SVN repository: http://opengl-lift-loading-library.g...com/svn/trunk/
Feedback is appreciated. Thank you for your time.
-
-
Maybe it's just me, but your explanation and example makes no sense to me at all. Could you demonstrate a case where this would be preferable over GLEW?
In fact, this looks more difficult to use than loading the extensions yourself using the WGL API.
-
No offense man, but that looks like some spaghetti code. You have #defines that include files rely on in the application itself, you're #including stuff in the body of functions, it bundles the OpenGL headers, and it uses backlashes in #includes, which breaks on most OSes.
As for the actual design, you claim it to be lighter weight at the expense of usability, which is pretty much the dealbreaker as far as I'm concerned, and 'possibly faster' than GLEW. Now, when you say usability, you're not just talking about APIs. You're actually talking about making spaghetti code in the example programs.
GLEW also generates its whole extension init system and variable names at build-time. Yours kind of does the same thing, but it's a maintenence nightmare by the looks of it.
I'd say the worst thing about this is that it's not a library. It's a bunch of headers, that are designed to generate TONS of code.
-
It's certainly not more difficult, because essentially that's what it is. Like I said it's for those who want to write their own library without writing thousands of function names and types over and over. So essentially a thousand lines of code becomes one, but you have still written the code yourself. Another way of putting it is the headers are basically a list. A list that can be parsed easily by a compile though. A case in which this would be better is a project I'm working on myself. It uses only OpenGL versions 1.2 1.5 2.0 and a few extensions. Using GLEW I would be wasting global memory on function pointers I would never use.
Edited:
No offense taken, thanks for the feedback. Backslashes aren't really a problem because you can move the headers around so there are none. I understand that usability is a big factor and it's definitely only worth it if you have a working knowledge of the extension system. I've always defined spaghetti-code to be code that looks unreadable probably due to spacing or odd looking code, and while the example code does contain strange use of #includes it ends up being still readable imo. For my purposes it's worth it in the end, but your complaints are understandable, thanks again.
-
Spaghetti code == tangled code. I.e. the program flow is haphazard or difficult to follow. You can fix formatting with a pretty print routine, but the same can't be said for spaghetti code.
I'm not really sure where you're going with this. I'll take a better look in the morning, when I'm feeling a bit fresher.
-
I'd say this becomes less of a worry very quickly with larger projects.
-
To be honest I just needed a big list of all the functions easily accessible. However typing them all obviously isn't physically possible unless you have a big work force so I figured I would save anyone who wanted the same kind of list from writing their own parser.
-
GLEW provides this.
-
I meant a custom formatted list. One that has type name and an error code in one line. I can see I may as well take it down, as I'm the only one that seems to be seeking this. I suppose I'll do so in the morning unless anyone else seems even remotely interested. Thanks for checking it out though.
-
You deleted the entire project within 36 hours just because two people didn't like the sound of it?
-
Having more people agree with you doesn't make you any more right. These 2 people had great arguments, I don't see how it matters that 50 other people didn't post to agree with them.
-
That was basically my mind set when deleting it. Looking back on it I just wanted to spare anyone from having to type out functions and at the same time have the same amount of freedom as typing them up. But people would just prefer to use an actual loading library anyway. The cost on memory is insignificantly small and the knowledge required is 0.
-
Sorry but what does selling the game have to do with using this over GLEW?
-
Well first of all the project is closed. Second if you are selling then it should be taken as a larger more serious project with tighter memory and speed constraints.Sorry but what does selling the game have to do with using this over GLEW?
Artistic x 1
Agree x 1
