I just installed SDL 1.3, and it runs fine with non-deprecated old-school OpenGL functions. The new functions give an error.
Does that mean we still need GLEW etc to do extension handling for us?
I used to do this manually like this in the past:
glCreateShader = (PFNGLCREATESHADERPROC) wglGetProcAddress("glCreateShader");
but that doesnt work with the GL3.h header so I’m guessing the function pointer return-types have changed.
I thought SDL 1.3 would make that ugly platform specific code obsolete, but it looks like not…
SDL 1.3 is not going to fix this ugly platform specific code obsolete … unfortunately!
GLEW is quite unmaintained so in anyway we are quite struggling here…
The best I get by now is SDL + GLEW to load OpenGL 2.1 functions. for the rest, I do it myself.
When creating an OpenGL 3.2 context on nVidia, the OpenGL 3.0 functions are not loaded… When creating an OpenGL 3.1 context on nVidia, the OpenGL 3.1 functions are loaded. Works fine on ATI, I don’t know about S3.
It would be nice to have a official library or one developed by AMD or nVidia.
I plan to make one but that’s some more do to!
What do you mean ?
There is GL 3.2 support on glew, last version updated end of february, so I wonder what would be something more maintained ?
Something that works for example?
I tried as soon as I could GLEW 1.5.3 to see if it fix the nVidia OpenGL 3.2 context problem but it doesn’t.
nVidia OpenGL 3.2 context => glGetError() != GL_NO_ERROR after glewInit() => OpenGL 2.1 functions loaded only.
What went wrong? I think I explicitly ask SDL for an OpenGL 3.2 context instead of letting it find one. Why? Because according to a guy, who work on Wine that report the problem to me using one of why project for testing, creating an OpenGL context using the higher OpenGL version it’s a standard, just a use of nVidia but there is somewhere (yes I forgot where…) it’s specify that this default context should be OpenGL 2.1…
Nightmare nightmare nightmare
I suspect the problem come from GLEW as GLEW generate an error. However, I actually start to have this issue after an update of my nVidia drivers. SDL is not so maintained either so maybe?
Basically, GLEW is maintained by one guy called Nigel and I really thank him for that. This guy just used to fix GLEW bugs and as nobody else taking care of GLEW, he quiet manage it now. I submit files to support OpenGL 3.1 and 3.2 months before GLEW 1.5.2 get released and he end up to do the work. A trouble with GLEW is that it can’t generate the source files on a platform different than Linux (probably with a specific setup). I tried with MSys, Cygwin, MacOS X… it didn’t worked. Unfortunate as GLEW mainly aim Windows.
I’m still using it but I would be glade to have an alternative.
There is another library to manage extensions, GLee.
OpenGL 3.0… Unmaintained…
So, how would you do it manually?
As I said, I did it manually without SDL using the wglGetProcAddress but SDL doesnt like it. I suppose I should be using SDL_GL_GetProcAddress like mentioned here: http://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress
But that requires using a variable with a ‘different’ name than the original function, so something like glCreateShader would have to be named glCreateShader_ptr.
Could someone outline some simple steps for how they load the extensions manually, using original function names as defined in GL3.h?
BTW, Glee is not unmaintained. It was updated only a few months ago. OpenGL is changing faster than anyone can keep up unfortunately.
What I do with GLEW is:
glCreateShader = (PFNGLCREATESHADERPROC)wglGetProcAddress (“glCreateShader”);
Directly because most of the function pointers are declared, just null sometimes when they should not.
Sometimes, pointers are declared and I get an error “glCreateShader unknowned identifier” so I declare them:
PFNGLCREATESHADERPROC glCreateShader = 0;
That’s pretty much it.
I maintain a library named gle that seems quite similar to GLEW, glee…
Ready to use package for developer is not actually provided. But, i can do it at least for Visual C++ 2008 quickly.
Or i can write the documentation explaining how to build the library if needed.
^Npapier, that would be great. I could help port it for RAD Studio 2009 (C++ Builder 2009) if you wish. That should make it compatible with all borland C compilers.
@Groovounet: Thats what I was doing before SDL. For some reason, with SDL 1.3, that method doesnt work anymore and I am guessing I have to use SDL_GL_GetProcAddress somehow…
@Fugitive: I gladly accept any help to support a new platform. gle is built regularly using gcc 4.4 on Fedora x86_6 and on Windows Vista 32/Seven 64 using Visual C++ 2008. Version 2010 RC2 and 2005 works too, but they are no more installed on my computer.
gle has no external dependency except c++ runtime, so it should be easily port to C++ builder by building files found in include and src directories in the subversion repository.
I don’t have access to C++ Builder (no free version ?).
If you want to build the library, i will publish the package on google code.
Actually, there is a free version of C++ builder: Turbo Explorer
The name is different(for branding purposes), but it is essentially C++ Builder 2006 (ive used it), and its free. It ‘should’ be available at: http://www.turboexplorer.com/
The website is down at the moment so i cannot confirm wether its still available. You can find it on other download sites though, like rapidshare.
Some info about it:http://www.onecore.net/in-review-turbo-explorer.htm
Please do publish the package on google code. Other people may find it useful as well.
Is there a proper release or we have to get the code from the repository?
@Fugitive: Is shared library produced by Turbo Explorer/C++ Builder 2006 compatible with C++ Builder 2009 you are using ?
@Groovounet: Not yet, but i’ll create the package for Visual C++ 2008 this sunday. Are you interested in another compiler ?
I’m interested by compiler independent
Do you know CMake?
@npapier: Yes. From what I have seen, the libs are compatible across all versions of Builder. Infact, IMHO, libs are compatible across all Borland compilers regardless of IDE.
Proper GL 3.x context support for GLEW might come along later in the year - it just happens that the product(s) I work on don’t need it (yet), and nobody else has come forward to make those changes either.
But I encourage y’all to join the GLEW the email list and help get GLEW straightened out for OpenGL 3.x and OpenGL 4.0. It’s mostly that I’m not trying to everything at once.
I just upload the first ready to use package for gle. As written before, only Visual C++ 2008 version is available. More to come.
@Groovounet: I’m interested by compiler independent too
I have choose a different solution by using SCons to build my projects.
I have written a lot of SCons code to construct a system that automate the building of libraries/executables, doxygen documentation, portable application, NSIS installer generation and so on. It’s called SConsBuildFrameWork and is available here. However, I must make a little effort and update the documentation before publishing it.
@Nigels: Great effort! Keep up the good work on GLEW. Lets hope we see 3.x support sooner rather than later.
@NPapier: Perhaps you wouldnt mind writing a little tutorial on how to use gle? I would rather not have to reverse engineer it all.