PDA

View Full Version : SDL 1.3 and GLEW



Fugitive
03-24-2010, 02:24 PM
Hi,

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:


PFNGLCREATESHADERPROC glCreateShader;
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...

Kind regards,
Fugi

Groovounet
03-24-2010, 05:11 PM
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!

ZbuffeR
03-24-2010, 05:50 PM
GLEW is quite unmaintained so in anyway we are quite struggling here...
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/

Groovounet
03-24-2010, 06:43 PM
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
--SDL--+--GLEW--+--Drivers--

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.

robmx
03-24-2010, 09:04 PM
There is another library to manage extensions, GLee.

http://elf-stone.com/glee.php

Groovounet
03-25-2010, 03:07 AM
OpenGL 3.0... Unmaintained...

Fugitive
03-25-2010, 05:07 AM
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?

Kind regards,
Fugi

Fugitive
03-25-2010, 05:11 AM
BTW, Glee is not unmaintained. It was updated only a few months ago. OpenGL is changing faster than anyone can keep up unfortunately.

Groovounet
03-25-2010, 05:56 AM
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.

npapier
03-25-2010, 07:06 AM
I maintain a library named gle (http://code.google.com/p/oglpp/wiki/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.

Fugitive
03-25-2010, 09:46 AM
^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...

npapier
03-26-2010, 03:52 AM
@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

Fugitive
03-26-2010, 09:30 AM
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.

Groovounet
03-26-2010, 09:57 AM
Is there a proper release or we have to get the code from the repository?

npapier
03-26-2010, 10:54 AM
@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 ?

Groovounet
03-26-2010, 11:08 AM
I'm interested by compiler independent ;)

Do you know CMake?
http://www.cmake.org/cmake/resources/software.html

Fugitive
03-26-2010, 11:21 AM
@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.

nigels
03-27-2010, 02:46 PM
Hi!

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

- Nigel

npapier
03-28-2010, 10:06 AM
I just upload the first ready to use package for gle (http://oglpp.googlecode.com/files/gle0-3_win32_cl9-0Exp.zip). 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 (http://scons.org/) 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 (http://code.google.com/p/sbf/). However, I must make a little effort and update the documentation before publishing it.

Fugitive
03-28-2010, 01:30 PM
@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.

npapier
03-29-2010, 03:09 AM
@Fugitive: A little tutorial is available here (http://code.google.com/p/oglpp/wiki/gle). I just update this wiki page and add a link on the doxygen documentation.

I plan to write an example using SDL/glut and of course expand the documentation.

Fugitive
04-01-2010, 03:48 PM
It won't run on C++ Builder 2010 Trial Version.


Error: Declaration syntax error

in gl.h:
WINGDIAPI void APIENTRY glAccum (GLenum op, GLfloat value);


When doing it manually (without glew, gle etc), the last time I had that conflict was when I tried to include both gl3.h and gl.h at the same time...

npapier
04-03-2010, 10:37 AM
This errror is typical when windows.h file is not included before the gl headers (for the symbol WINGDIAPI and APIENTRY).

In the beginning of gle/gle.hpp (included by gle/gl.h), you can find :

#ifdef WIN32

* * * * #if defined(_WIN32) && !defined(APIENTRY) && !defined(__CYGWIN__)
* * * * #define WIN32_LEAN_AND_MEAN 1
* * * * #ifndef NOMINMAX
* * * * #define NOMINMAX
* * * * #endif
* * * * #include <windows.h> // contains all WGL Functions.
* * * * #endif

* * * * #include <GL/gl.h>
* * * * #include <GL/glext.h>
* * * * #include <GL/wglext.h>
* * * * //#include <GL/glu.h>

#elif __MACOSX__

* * * * #define WINGDIAPI
* * * * #define APIENTRY
* * * * #include <GL/gl.h>
* * * * #include <GL/glext.h>
* * * * //#include <GL/glu.h>

* * * * //#include <OpenGL/gl.h>
* * * * //#include <OpenGL/glext.h>
* * * * //#include <OpenGL/glu.h>
* * * *
#else // POSIX

* * * * #define __STDC_VERSION__ * * * *199901L
* * * * #include <GL/gl.h>
* * * * #include <GL/glext.h>
* * * * //#include <GL/glx.h>
* * * * //#include <GL/glxext.h>
* * * * //#include <GL/glu.h>

#endif
So I suspect that the symbol WIN32 is not defined by Turbo C++. Try to add it to the project settings to fix this problem.

Fugitive
04-05-2010, 07:28 AM
^I thought that I wouldnt have to re-include windows.h since it was already included as you pointed out. Anyhow, I did include it at the top, so thats fine.

It still doesnt recognize the class functions though. It could be that it doesnt recognize the dll that I converted to Borland format via implib, though I have not had much problems with doing that in the past.



gle::OpenGLExtensionsGen gleContext(std::cout); <== problem
gleContext.initialize();
gle::gleSetCurrent( gleContext );

[BCC32 Error] tutorialMain.cpp(109): E2285 Could not find a match for 'gle::OpenGLExtensionsGen::OpenGLExtensionsGen(ost ream)'

npapier
04-07-2010, 06:00 AM
It still doesnt recognize the class functions though. It could be that it doesnt recognize the dll that I converted to Borland format via implib, though I have not had much problems with doing that in the past.

This is a problem at compilation stage and not at the linking stage. So the dll produced by implib has no influence.
Have you included the file OpenGLExtensionsGen.hpp using #include <gle/OpenGLExtensionsGen.hpp> ?

idwakest
05-05-2010, 02:42 PM
Hi,

SDL and glew work fine together. You just have to specify which version of OpenGL you want to use before calling SDL_Init.

SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 2);
SDL_Init(SDL_INIT_VIDEO);
..
SDL_CreateWindow();
SDL_GL_CreateContext();
..
glewInit();


The tutorial (http://www.opengl.org/wiki/Tutorial2:_VAOs,_VBOs,_Vertex_and_Fragment_Shaders _%28C_/_SDL%29) does not work because it creates a 2.1 OpenGL context and not a 3.2 as planned.

przemo_li
02-07-2011, 05:00 AM
How exactly glew works?
After idwakest code, will I get only opengl 3.2 set of functions? Or all supported by driver?

Eg. how to get OGL4.1 (Core Profile if possible), with SDL and with glew.