SDL/GL/Win98/WinNT question

I’m able to use the SDL video functions as documented, and I have been
hoping to use the SDL blitting functions for my outside-game UI, and then
when I get into the game, switch over to using SDL’s OpenGL support.

I read the documentation which states that OpenGL and SDL blitting can’t be
done on the same window, so one question I have is whether it’s recommended
in cases like this to create a SDL blitting window for the outside-game
work, and then close that when going into the game, and creating an OpenGL
window for the game work? Or is there a simpler fashion that can reuse the
window, but reinitialize the SDL_screen living inside it?

It’s actually really easy. The first time, call SDL_SetVideoMode()
without the SDL_OPENGL flag, and the second time call it with the flag.
SDL should re-use the same window, so you’ll hopefully get seamless
switching between the two. Let me know if you have any problems with
it because it isn’t as well tested on Windows as it has on Linux.

The other issue being that I’m not able to create an SDL-OpenGL window in my
project, though the tests/testGL app runs just fine. I traced into the SDL
code (at the recommendation of Lion Kimbro, who works upstairs from me, and
wrote the VisualC.html documentation for SDL), and found that
GetModuleHandle is failing to find the Opengl32.dll library. I’ve written
small programs that simply try that call (without SDL) and no module handle
is acquired on my home or work machines. So I’m puzzled how the test code
manages to get a module handle - and I’ve traced across the call; it’s
making the same Windows call, and it’s finding the library.

Is it possible that I’m neglecting to configure something in my compile/link
environment that makes the test app work properly?

That’s very strange, although several people have reported a problem
like this. Try dropping your code into the testgl source file and
see if it works. Keep modifying the project to match your settings
until it no longer works. Make sure you’re using the latest CVS snapshot.

Let me know what you find! :slight_smile:

Thanks,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

I’m able to use the SDL video functions as documented, and I have been
hoping to use the SDL blitting functions for my outside-game UI, and then
when I get into the game, switch over to using SDL’s OpenGL support.

I read the documentation which states that OpenGL and SDL blitting can’t be
done on the same window, so one question I have is whether it’s recommended
in cases like this to create a SDL blitting window for the outside-game
work, and then close that when going into the game, and creating an OpenGL
window for the game work? Or is there a simpler fashion that can reuse the
window, but reinitialize the SDL_screen living inside it?

It’s actually really easy. The first time, call SDL_SetVideoMode()
without the SDL_OPENGL flag, and the second time call it with the flag.
SDL should re-use the same window, so you’ll hopefully get seamless
switching between the two. Let me know if you have any problems with
it because it isn’t as well tested on Windows as it has on Linux.

Or you can try SDL_OPENGLBLIT. Sorry, just had to say that :slight_smile:

The other issue being that I’m not able to create an SDL-OpenGL window
in my
project, though the tests/testGL app runs just fine. I traced into the SDL
code (at the recommendation of Lion Kimbro, who works upstairs from me, and
wrote the VisualC.html documentation for SDL), and found that
GetModuleHandle is failing to find the Opengl32.dll library. I’ve written
small programs that simply try that call (without SDL) and no module handle
is acquired on my home or work machines. So I’m puzzled how the test code
manages to get a module handle - and I’ve traced across the call; it’s
making the same Windows call, and it’s finding the library.

Is it possible that I’m neglecting to configure something in my
compile/link
environment that makes the test app work properly?

That’s very strange, although several people have reported a problem
like this. Try dropping your code into the testgl source file and
see if it works. Keep modifying the project to match your settings
until it no longer works. Make sure you’re using the latest CVS snapshot.

Let me know what you find! :slight_smile:

I think I know this one.
If you haven’t actually used an OpenGL function, and build a Release
executable,
the optimizing linker will strip references to OPENGL32.LIB, etc., so
OpenGL won’t
automatically be loaded at app launch, and (for me at least) SDL dies.
If you add a code snippet like

     static unsigned char* glversion = glGetString(GL_VERSION);

then the OpenGL references wil not be optimized away.

Note that this does not address the underlying problem,
which is that SDL is apparently unable to load OPENGL32.DLL
by itself.

– Mike

the optimizing linker will strip references to OPENGL32.LIB, etc., so
OpenGL won’t
automatically be loaded at app launch, and (for me at least) SDL dies.
If you add a code snippet like

     static unsigned char* glversion = glGetString(GL_VERSION);

then the OpenGL references wil not be optimized away.

Note that this does not address the underlying problem,
which is that SDL is apparently unable to load OPENGL32.DLL
by itself.

Well, if you link with the opengl library, then SDL should be able
to load it from your process address space (unless stripped out by
the optimizing linker). If you don’t link with the opengl library,
you can always use SDL_GL_LoadLibrary(“OPENGL32.DLL”) to explicitly
load it. If that fixes your problem, let me know, and I’ll add code
to do that if loading from the process space fails.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software