I got my hands on an older cvs snapshot of sdl (1.1) today, one that still allowed
specifying the --enable-dynamic-opengl option to configure. I compiled and tried that
library and it works just fine.
Using SDL 1.1.1 however, SDL fails. Is there some sort of undocumented environment
In article <89t8g5$him$1 at ftp.lokigames.com>, @Christian_Zander wrote:
I got my hands on an older cvs snapshot of sdl (1.1) today, one that still allowed
specifying the --enable-dynamic-opengl option to configure. I compiled and tried that
library and it works just fine.Using SDL 1.1.1 however, SDL fails. Is there some sort of undocumented environment
variable that needs to be set?
Ok, I’m not an expert on this, looking through the source (sdl-1.1.1), this block in
SDL_x11gl.c looked rather odd to me:
/* load the gl driver from a default path */
if ( ! this->gl_config.driver_loaded ) {
/* no driver has been loaded, use default (ourselves) */
if ( X11_GL_LoadLibrary(this, NULL) < 0 ) {
return(-1);
}
}
With the default path being NULL, nothing should be loaded … Anyway, I changed it to
/* load the gl driver from a default path */
if ( ! this->gl_config.driver_loaded ) {
/* no driver has been loaded, use default (ourselves) */
if ( X11_GL_LoadLibrary(this, "libGL.so") < 0 ) {
return(-1);
}
}
And that fixed it for me … Am I missing something, or is this really the error’s source?--------------------------------------------------------------
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
hi`
could you try -rdynamic (linking) and see if that helps?
phoenix at minion.de wrote:>
I got my hands on an older cvs snapshot of sdl (1.1) today, one that still allowed
specifying the --enable-dynamic-opengl option to configure. I compiled and tried that
library and it works just fine.Using SDL 1.1.1 however, SDL fails. Is there some sort of undocumented environment
variable that needs to be set?
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
In article <38C27F6F.6310FD8E at grafzahl.de>, Daniel Vogel <666 at grafzahl.de> wrote:
hi`
could you try -rdynamic (linking) and see if that helps?
-rdynamic has always been there (produced by gtk-config --libs)--------------------------------------------------------------
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
phoenix at minion.de wrote:
/* no driver has been loaded, use default (ourselves) */ if ( X11_GL_LoadLibrary(this, NULL) < 0 ) {
this means that dlopen will try to resolve the symbols from your program
(you will have to link against libGL).
With the default path being NULL, nothing should be loaded … Anyway, I changed it to
if ( X11_GL_LoadLibrary(this, "libGL.so") < 0 ) {
because that worked I assumed there was a missing -rdynamic. I don’t
know whether this option is ‘global’ like it exports all symbols or only
those that come after passing the argument or whatever. Oh, and you
could try --export-dynamic.
from some man/info page:
`–export-dynamic’
When creating a dynamically linked executable, add all symbols to
the dynamic symbol table. The dynamic symbol table is the set of
symbols which are visible from dynamic objects at run time.
If you do not use this option, the dynamic symbol table will
normally contain only those symbols which are referenced by some
dynamic object mentioned in the link.
If you use `dlopen' to load a dynamic object which needs to refer
back to the symbols defined by the program, rather than some other
dynamic object, then you will probably need to use this option when
linking the program itself.--
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
In article <38C28CCD.45EEC2F9 at grafzahl.de>, Daniel Vogel <666 at grafzahl.de> wrote:
@Christian_Zander wrote:
/* no driver has been loaded, use default (ourselves) */ if ( X11_GL_LoadLibrary(this, NULL) < 0 ) {this means that dlopen will try to resolve the symbols from your program
(you will have to link against libGL).
ok, sounds reasonable - like i said, i’m not an expert on this (yet hopefully).
the problem is that dispite the fact that i am linking against libgl, sdl can’t dlsym the
glx symbols. in reply to a previous post of mine, somebody (jeff) suggested, that that
might be related to the nature of the ‘application’ i’m writing. it’s a plugin, loaded
dynamically on startup of another application (xmms) - if sdl is dlopening globally, it’ll
access xmms’s symbol table. xmms is not linked agains libgl, however, the plugin is.
With the default path being NULL, nothing should be loaded … Anyway, I changed it to
if ( X11_GL_LoadLibrary(this, "libGL.so") < 0 ) {because that worked I assumed there was a missing -rdynamic. I don’t
know whether this option is ‘global’ like it exports all symbols or only
those that come after passing the argument or whatever. Oh, and you
could try --export-dynamic.
–export-dynamic didn’t help. Now that i’ve spent some time looking through the sdl
sources, it occured to me that sdl is reopening libgl anyway. I fixed my problem by
putting a dummy dlopen in my code. - i dlopen libgl before calling SDL_SetVideoMode,
with RTLD_GLOBAL as you suggested and as sdl does.
Thanks a lot for your assistance.
PS: the ut sdl driver doesn’t work with the glide renderer--------------------------------------------------------------
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
phoenix at minion.de wrote:
might be related to the nature of the ‘application’ i’m writing. it’s a plugin, loaded
dynamically on startup of another application (xmms) - if sdl is dlopening globally, it’ll
access xmms’s symbol table. xmms is not linked agains libgl, however, the plugin is.
Well it sure is related to the nature of the application 
Maybe
recompiling xmms with --export-dynamic would help, but your solution is
’faster’. In theory it should be possible to get this to work but surely
would require much further investigation…
putting a dummy dlopen in my code. - i dlopen libgl before calling SDL_SetVideoMode,
with RTLD_GLOBAL as you suggested and as sdl does.
That makes the code less portable, but if you don’t care for that it is
the quickest hack.
PS: the ut sdl driver doesn’t work with the glide renderer
AFAIK it is possible to get it to work I am just to lazy to install
Linux properly on my Voodoo box to verify it myself. I know I should do
once (especially to verify that it is UTs mouse code that sucks even
with high frame rates).–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
ok, sounds reasonable - like i said, i’m not an expert on this (yet hopefully).
the problem is that dispite the fact that i am linking against libgl, sdl can’t dlsym the
glx symbols. in reply to a previous post of mine, somebody (jeff) suggested, that that
might be related to the nature of the ‘application’ i’m writing. it’s a plugin, loaded
dynamically on startup of another application (xmms) - if sdl is dlopening globally, it’ll
access xmms’s symbol table. xmms is not linked agains libgl, however, the plugin is.
Ahh yes, this sounds like the problem.
–export-dynamic didn’t help. Now that i’ve spent some time looking through the sdl
sources, it occured to me that sdl is reopening libgl anyway. I fixed my problem by
putting a dummy dlopen in my code. - i dlopen libgl before calling SDL_SetVideoMode,
with RTLD_GLOBAL as you suggested and as sdl does.
Great! 
I’m glad that’s fixed.
Let me know when your plugin is ready - I’m really curious to see what it is.
See ya,
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
In article <38C2CA60.E325C51A at grafzahl.de>, Daniel Vogel <666 at grafzahl.de> wrote:
Well it sure is related to the nature of the application
recompiling xmms with --export-dynamic would help, but your solution is
’faster’. In theory it should be possible to get this to work but surely
would require much further investigation…
yes, and i don’t feel like investigating, i feel like coding
as to the xmms recompilation - it could work for me, but try telling users of the
plugin that in order for it to work, their binary package needs to be deinstalled
and xmms recompiled by themselves …
That makes the code less portable, but if you don’t care for that it is
the quickest hack.
Since I’m using glx in other places of the plugin, it’s limited to X11 environments
anyway. the xmms plugin system only works on systems that allow dynamic
linking, so portability shouldn’t be limited by that.
AFAIK it is possible to get it to work
Linux properly on my Voodoo box to verify it myself. I know I should do
once (especially to verify that it is UTs mouse code that sucks even
with high frame rates).
yeah, probably - i’m considering the purchase of another graphics adapter
to get in window acceleration (i don’t really trust the 3dfx solution) - that will
render the glide driver useless - unless somebody writes a glide wrapper for
linux …--------------------------------------------------------------
Christian Zander ** N?ckersberg 76 ** 45257 Essen ** Germany
email: mbox at minion.de ** www: www.minion.de ** icq#: 5322926
AFAIK it is possible to get it to work
Linux properly on my Voodoo box to verify it myself. I know I should do
once (especially to verify that it is UTs mouse code that sucks even
with high frame rates).
BTW, as of SDL 1.1.1, the DGA mouse code is enabled by default, which
should vastly improve mouse performance in UT. There is also code to
change the acceleration parameters for the X11 mouse. See the FAQ for
details.
Check it out!
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Sam Lantinga wrote:
BTW, as of SDL 1.1.1, the DGA mouse code is enabled by default, which
should vastly improve mouse performance in UT. There is also code to
change the acceleration parameters for the X11 mouse. See the FAQ for
details.Check it out!
I guess the problem is on UTs side - the mouse code is sluggish with the
XDrv either (it uses DGA mouse). Fiddling with the acceleration could
help but I think the problem is buried deeper in UTs code making some
assumptions about the mouse that are not true under Linux. Or maybe the
event system is a bit different for the Windows driver. Well, I will
have a look at this some time after the 406 patch.–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
In article , Sam Lantinga wrote:
Let me know when your plugin is ready - I’m really curious to see what it is.