Blame me for my ignorance, but looking at the OpenUT code didn’t really help me in
understanding the way SDL_GL_LoadLibrary/SDL_GL_GetProcAddress should be used.
What are the basics steps to getting e.g. glViewport’s address registered ?
I could use LD_PRELOAD with xmms to make SDL use libGL, but since I’m only writing
a plugin, requiring changes to the way xmms get’s loaded would not be appropriate.
I tried linking libGL using -lGL on gcc’s command line when creating libfx.so (the xmms
plugin) which should work as far as I know, but SDL doesn’t cope. (see previous post ->
SDL 1.1. OpenGL problem?)
Well, UT does it by only using OpenGL in one class so it simply shadows
the global declaration. You could create a static class and then do
something like OpenGL::glVertex3f if you need it globally. I wonder
which glVertex3f would get called if you use namespace OpenGL… hmmm…
I should think before I write…
you can do something like
namespace OpenGL
{
//declare it here
}
and then do OpenGL::glVertex3f. Usually the compiler will bug because of
ambigouity (spelling?) if you do “using namespace OpenGL” and have
included gl.h.
Yeah, except i’m coding this thing in c. I don’t like loading the libs dynamically, anyway.
Loading each of the functions for a plugin that size seems like overkill and portability goes
down the drain (at least for some platforms).
What i don’t understand is why the rest of the plugin seems to find the gl symbols alright,
just not sdl??--------------------------------------------------------------
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
LIBS = -lGL gtk-config --libslibglade-config --libssdl-config --libs -lGL–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
I didn’t quite understand what your problem is exactly Basically I
suggested the above because linking order is important and this way you
can be sure that all GL symbols get resolved. Basically you want to
place -lGL at the end and not in the beginning in general. But if that
had been the cause the linker would have complained I guess - at least
under Linux.
in a function and it worked. Using the declaration globally fails, though, since that
results in a conflict with the declaration in gl.h.
How do I get by this?
Well, UT does it by only using OpenGL in one class so it simply shadows
the global declaration. You could create a static class and then do
something like OpenGL::glVertex3f if you need it globally. I wonder
which glVertex3f would get called if you use namespace OpenGL… hmmm…–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
in a function and it worked. Using the declaration globally fails, though, since that
results in a conflict with the declaration in gl.h.
How do I get by this?--------------------------------------------------------------
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
Well, UT does it by only using OpenGL in one class so it simply shadows
the global declaration. You could create a static class and then do
something like OpenGL::glVertex3f if you need it globally. I wonder
which glVertex3f would get called if you use namespace OpenGL… hmmm…
I should think before I write…
you can do something like
namespace OpenGL
{
//declare it here
}
and then do OpenGL::glVertex3f. Usually the compiler will bug because of
ambigouity (spelling?) if you do “using namespace OpenGL” and have
included gl.h.–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
Well, UT does it by only using OpenGL in one class so it simply shadows
the global declaration. You could create a static class and then do
something like OpenGL::glVertex3f if you need it globally. I wonder
which glVertex3f would get called if you use namespace OpenGL… hmmm…
I should think before I write…
you can do something like
namespace OpenGL
{
//declare it here
}
and then do OpenGL::glVertex3f. Usually the compiler will bug because of
ambigouity (spelling?) if you do “using namespace OpenGL” and have
included gl.h.
Yeah, except i’m coding this thing in c. I don’t like loading the libs dynamically, anyway.
Loading each of the functions for a plugin that size seems like overkill and portability goes
down the drain (at least for some platforms).
What i don’t understand is why the rest of the plugin seems to find the gl symbols alright,
just not sdl??
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
SDL is doing dlopen on the running program to find the OpenGL symbols. It works fine here, I
don’t know why it wouldn’t work for you. Are you actually making any GL calls from your
program?
Well, UT does it by only using OpenGL in one class so it simply shadows
the global declaration. You could create a static class and then do
something like OpenGL::glVertex3f if you need it globally. I wonder
which glVertex3f would get called if you use namespace OpenGL… hmmm…
I should think before I write…
you can do something like
namespace OpenGL
{
//declare it here
}
and then do OpenGL::glVertex3f. Usually the compiler will bug because of
ambigouity (spelling?) if you do “using namespace OpenGL” and have
included gl.h.
Yeah, except i’m coding this thing in c. I don’t like loading the libs dynamically, anyway.
Loading each of the functions for a plugin that size seems like overkill and portability goes
down the drain (at least for some platforms).
What i don’t understand is why the rest of the plugin seems to find the gl symbols alright,
just not sdl??
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
SDL is doing dlopen on the running program to find the OpenGL symbols. It works fine here, I
don’t know why it wouldn’t work for you. Are you actually making any GL calls from your
program?
–Sam Lantinga
im not sure if im right as ive only skimmed the posts but i think i think i might know the answer.
he is writing a plugin for a program not a program, when his plugin uses SDL for opengl SDL
dlopens the program(xmms) to look for the symbols and not the plugin so the opengl symbols arent
there.
Basically I