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.
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 ? http://glew.sourceforge.net/
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…
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.
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?
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.
Thanks
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:In Review :Turbo Explorer
Please do publish the package on google code. Other people may find it useful as well.
@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.
