SDL_SetVideoMode and threads

Hello all, one hopefully quick question,

in SDL 1.3, it seems that I am only able to draw graphics (I’m using
opengl on linux) if I do my graphics loop from the initial process. If
I use SDL_CreateThread and supply my graphics loop as the function
then I get nothing rendered ( but the loop does run and consumes about
the same amount of cycles )

Any ideas?

Thanks

Ian

That’s by design. It’s the same in Windows. You can only render
from the main thread.>----- Original Message ----

From: Ian Norton
Subject: [SDL] SDL_SetVideoMode and threads

Hello all, one hopefully quick question,

in SDL 1.3, it seems that I am only able to draw graphics (I’m using
opengl on linux) if I do my graphics loop from the initial process. If
I use SDL_CreateThread and supply my graphics loop as the function
then I get nothing rendered ( but the loop does run and consumes about
the same amount of cycles )

Any ideas?

Excellent thanks, I had a feeling that would be the case.

2010/1/20 Mason Wheeler :> That’s by design. It’s the same in Windows. ?You can only render

from the main thread.

----- Original Message ----
From: Ian Norton <@Ian_Norton>
Subject: [SDL] SDL_SetVideoMode and threads

Hello all, one hopefully quick question,

in SDL 1.3, it seems that I am only able to draw graphics (I’m using
opengl on linux) if I do my graphics loop from the initial process. If
I use SDL_CreateThread and supply my graphics loop as the function
then I get nothing rendered ( but the loop does run and consumes about
the same amount of cycles )

Any ideas?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Mason Wheeler wrote:

That’s by design. It’s the same in Windows. You can only render
from the main thread.

Mason, do you know why that is? Can you point me to a discussion why this being
done? What’s special about the main thread that can’t replicated with other threads?

(I’m genuinely curious. Not trying to start an argument.)

CE

Mason Wheeler wrote:

That’s by design. It’s the same in Windows. You can only render
from the main thread.

Mason, do you know why that is? Can you point me to a discussion why this being
done? What’s special about the main thread that can’t replicated with other threads?

(I’m genuinely curious. Not trying to start an argument.)

Sorry, can’t help you there. I don’t know enough about the way it works. I just know
that this is a requirement imposed by Windows, and I think I remember people saying
that the same requirement exists in X11. If I were to try an educated guess, I’d say
that there’s something in the windowing APIs for both systems that isn’t thread-safe.

Bob, if you’re reading this, could you add a bit of enlightenment? Apparently you
know a whole lot about X11 internals…>----- Original Message ----

From: Chris Eineke
Subject: Re: [SDL] SDL_SetVideoMode and threads

Mason Wheeler wrote:

That’s by design. It’s the same in Windows. You can only render
from the main thread.

Mason, do you know why that is? Can you point me to a discussion why this being
done? What’s special about the main thread that can’t replicated with other threads?

(I’m genuinely curious. Not trying to start an argument.)

Sorry, can’t help you there. I don’t know enough about the way it works. I just know
that this is a requirement imposed by Windows, and I think I remember people saying
that the same requirement exists in X11. If I were to try an educated guess, I’d say
that there’s something in the windowing APIs for both systems that isn’t thread-safe.

Bob, if you’re reading this, could you add a bit of enlightenment? Apparently you
know a whole lot about X11 internals…

On Windows, Mac OS X and Linux you can get away with using OpenGL in secondary threads, provided that they are the same thread that created the context, this seems to be the rule of thumb on all
OpenGL implementations.

However you must NEVER call windowing functions from multiple threads at the same time, so you basically have to mutex lock the main thread (because even polling for events can crash), let the
secondary thread do its thing, then release the lock and continue.

Usually this is only done for a “game thread” with a child window of an application UI, which is not even possible on Mac OS X (somehow the Java web plugin pulls it off but I never figured it out).

There are a whole joyous range of nightmare bugs to deal with if you thread a game like this, many of which I ran into on the QuakeLive porting where I had to maintain the status quo (the Windows game
plugin ran a separate game thread that did its own window management and rendering), ultimately I think you’re better off running the main game processing from the main thread and only using other
threads as sound mixers, file streamers, and job queue workers.

Without knowing the exact context I can’t comment further, but I can at least say you’re “living dangerously” with this approach.On 01/20/2010 06:23 PM, Mason Wheeler wrote:

----- Original Message ----
From: Chris Eineke
Subject: Re: [SDL] SDL_SetVideoMode and threads


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier