I’ve been working with embedding SDL in a cross-platform application for
video playback using the SDL_WINDOWID hack. On OS X my application is
Carbon-based so I made a few changes to support this. Sorry that this
is based on 1.2.11, but I was unaware of the 1.3 work when I began this
a while ago. Apple’s documentation is lacking so I’ve had to use a
lot of trial and error to get this to work. Also I must excuse myself
for not being a real mac developer.
To use this feature, set these environment variables like this example
before calling SDL_SetVideoMode() :
SDL_WINDOWID=12345234 (your carbon WindowRef cast to a long)
SDL_VIDEO_WINDOW_POS=100,200 (x and y position of the origin,
specified relative to the top-left of the carbon window)
IMHO it would be better if SDL environment variable “hacks” were
promoted to full-fledged API features (but i wanted to remain consistent
with what’s there now). Is that in the plans for 1.3?
My app is able to successfully do this once, show some video, then reset
SDL_VIDEO_WINDOW_POS to a different origin and call SDL_SetVideoMode()
again to reposition the origin on the same SDL_WINDOWID. I have not
tested changing SDL_WINDOWID between calls to SDL_SetVideoMode().
Note that with this patch, if an external window is being specified, SDL
will no longer close it since it doesn’t own it. I’ve attempted to make
this the case also for the alternative SDL_NSWindowPointer hack (for
embedding SDL video in a cocoa window) since this seems to be the right
thing to do in either case, but maybe it would be better not to change
the behavior in that case in case some apps might expect the existing
behavior (seems like a bug to me though). That would be a simple matter
of omitting the first instance of
qz_window_should_be_closed = FALSE;
Also note that this has so far only been tested on OS 10.4. The
underlying carbon/cocoa integration support may be missing in older OS X
On a related topic, I’ve found what I think is a bug in the thread code
for OS X. My application creates threads, and I see scary run-time
warnings in stderr about leaking of various cocoa objects that were
allocated in those threads. According to Apple, "If you are making
Cocoa calls outside of the Application Kit’s main thread, however, you
need to create your own autorelease pool. This is the case if you are a
Foundation-only application or if you detach a thread."
I find that calling the following code from my newly created thread
fixes the leaking warnings:
pool = [[NSAutoreleasePool alloc] init];
Then when the thread is being destroyed we should release the pool:
I believe that SDL should be doing these things in its thread creation
and destruction code, but I’m not sure where the right place is to put this.
I hope this is useful to others.
-------------- next part --------------
A non-text attachment was scrubbed…
Size: 7133 bytes
Desc: not available