Update - this bug applies to 1.2.x.

Bumping this to critical. Quickdraw has gone from deprecated, to disabled on OS X 10.6

SDL will no longer compile at all on OS X 10.6 and the binary support for Quickdraw is gone. Also, correcting the above comment. The Quick Draw API has been deprecated since 10.4. It only had 32bit binary support on 10.5. It has no support at all on 10.6.

Not bumping to blocker as this appears to be fixed in SVN, but if 1.3.0 isn't going to be released soon, it needs to be backported to 1.2 for a maintenance release.

(additionally, bugzilla needs a 10.6 platform string)

*** Bug 700 has been marked as a duplicate of this bug. ***

Created attachment 352 [details]
Patch made from the sdl-devel mail by Paolo Bonzini

This patch is made against latest SDL 1.2 SVN, based on the original patch by Paolo Bonzini.

The patch doesn't work quite right for me yet, 16 bit surfaces I obtain with it applied have the wrong pixelformat set. But it does run.

The attached patch has another issue: With it, the SDL_NSQuickDrawViewPointer env variable would have to be removed. Code for handling it is still in there, but any app that relies on it would be broken with this patch applied. Hrm :/. (Bad hacks like that haunt you for your whole life, sadly :/)

Thanks for testing.  Indeed I hadn't tested 16-bit surfaces.

Regarding SDL_NSQuickDrawViewPointer, http://google.com/codesearch?hl=en&sa=N&filter=0&q=SDL_NSQuickDrawViewPointer+-file:SDL_QuartzVideo.m shows just one user (an Atari 800 emulator).  NSView is a superclass of NSQuickDrawView so it might even just work...

Wow, how did I miss this patch? Thanks, Paolo, I'll be looking at it soon for inclusion in SDL 1.2.

Max: SDL_NSQuickDrawViewPointer can go. If people need a legacy Mac OS X interface, they can use a legacy SDL build.  I'll probably have SDL_SetVideoMode() fail if the environment variable is set at all.

--ryan.

*** Bug 792 has been marked as a duplicate of this bug. ***

> If people need a legacy Mac OS X
> interface, they can use a legacy SDL build.

I think actually no one is using the envvar to do quickdraw operations, but rather to embed the SDL video into a more complex UI.  If the application is modified to just pass a normal NSView, that should work.

Created attachment 353 [details]
Updated version of Paolo's patch.


Here's an updated version of the patch...the QuickDraw YUV stuff is #ifdef'd out for now, and a few other 10.6 SDK cleanups are in there. I'm mostly posting this so I don't lose it, but it's not ready for inclusion in Subversion yet.

The todo list is:
- Replace the YUV code with something else that doesn't use QuickDraw or QuickTime.
- Do something about the overridden class things (cglContext and setFrame).
- test.
- probably other things.

--ryan.

Changed platform to 10.6 in Bugzilla.

--ryan.

This patch leads to graphical regressions in ScummVM, compared to SDL 1.2.13 or the SDL-1.2 SVN trunk. I am testing with ScummVM SVN trunk, on Mac OS X 10.5.8, on a MacBook Pro.

The issue: When starting ScummVM in windowed mode, then with this patch applied, colors are messed up (it looks as if channels are swapped, resp. a wrong pixelformat is used. Like 555 vs 565 mode).

Details: I am not yet sure what is going on, but the visible issue is that colors are messed up, everything looks greenish. I can provide a screenshot if desired. Note that ScummVM requests a 16bit surface, but with the new code, SDL creates a 32 bit surface internally. SDL then sets up a shadow surface to be able to return a 16bit surface.
Now, if run in windowed mode (where colors are messed up), a 565 mode is returned. This is the pixelformat SDL returns to ScummVM:
  loss 0x3 / 0x2 / 0x3 / 0x0, mask 0xf800 / 0x7e0 / 0x1f / 0x0, shift 0xb / 0x5 / 0x0 / 0x0
This is the same format an unpatched SDL yields, but somehow SDL internally screws up conversion.

Interestingly, no such issue in fullscreen mode, where (as in the past), a 555 surface is returned:
loss 0x3 / 0x3 / 0x3 / 0x8, mask 0x7c00 / 0x3e0 / 0x1f / 0x0, shift 0xa / 0x5 / 0x0 / 0x0


I am pretty sure that the issue is in this patch and not ScummVM, since (a) it works without this patch, (b) the graphics output code in ScummVM has been tested on tons of systems over many years, and (c) we get the exact same pixelformats without the patch and things work fine there.

Also, I wonder why we return a 555 shadow surface in one case and a 565 in the other anyway. With the old code, that may have made sense, for some weird reasons, but with the new code, which uses a 32bit surface internally anyway, it seems to be pointless.

Created attachment 354 [details]
test program

Yes, I'm also sure that the issue is in the patch.  Max, I don't have access anymore to a Mac, can you test the attached program?

Tagging this bug with "target-1.2.14" so we can try to resolve it for SDL 1.2.14.

Please note that we may choose to resolve it as WONTFIX. This tag is largely so we have a comprehensive wishlist of bugs to examine for 1.2.14 (and so we can close bugs that we'll never fix, rather than have them live forever in Bugzilla).

--ryan.

In windowed mode, the test program displays squares of the colors (starting from the upper-left and going clockwise): black, red, yellow, green.

In full screen, it is: blue, green, white, red.

Please post a PNG snapshot of windowed mode.  Do the colors change if you press a key, or do they just change brightness?

Created attachment 357 [details]
Test program in windowed mode

Only changes in brightness if I press a key

Created attachment 358 [details]
Test program in fullscreen mode

Only changes in brightness if I press a key

So blue goes away completely, and the color intensities of green and red are correct but swapped.  It's a bug in the creation of the MacOS surface since FillRect and writing to memory works equally.  So this is an endianness problem due to the fact that I was working on a big-endian (PowerPC) Mac.

These lines in SDL_QuartzVideo.m

            case 32:   /* (8)-8-8-8 ARGB */
                amask = 0x00000000;
                rmask = 0x00FF0000;
                gmask = 0x0000FF00;
                bmask = 0x000000FF;

should be changed to this:

            case 32:   /* (8)-8-8-8 ARGB */
                amask = 0x00000000;
#ifdef __LITTLE_ENDIAN__
                rmask = 0x0000FF00;
                gmask = 0x00FF0000;
                bmask = 0xFF000000;
#else
                rmask = 0x00FF0000;
                gmask = 0x0000FF00;
                bmask = 0x000000FF;
#endif

Though to be sure the program should be run also on a PPC Mac.

Indeed that does fix the observed color problem on an Intel Mac.

I can try the patch on a PPC Mac later on tonight if no one beats me to it.

This compiles and runs the test program with correct color output on a PPC Mac running 10.4.11 with some minor changes, but should compile without any changes in 10.5.

There are two typedefs needed for compatibility; they are types introduced in 10.5 for 64-bit abstraction. You need to add them somewhere appropriate in the headers.

#ifndef NSINTEGER_DEFINED
typedef unsigned int NSUInteger;
typedef SInt16 FSIORefNum;
#endif

Would you please attach a new patch?

Thanks!

Created attachment 361 [details]
 Updated version of Paolo's patch rev 2

This compiles and works on 10.4, 10.5, and 10.6.

An updated version of Kenny's patch (Attachment #361 [details]) just went into revision control as svn revision #4762.

The YUV stuff is simply ripped out. The QuickDraw/QuickTime code was crap, and there wasn't really a reasonable replacement either. Ripping it out means SDL will handle the YUV-RGB conversion behind the scenes, so overlays will still work on the Mac: binary and source compatible with existing apps based on SDL 1.2.

The overridden Cocoa mess is still used on PowerPC builds, as it will compile and work on all Mac OS X versions the PowerPC supports. On Intel Macs, we don't use them, as we have better interfaces guaranteed. This is all behind the scenes stuff and doesn't affect SDL-based applications.

The environment variables are gone. Sorry. If you needed them, use 1.2.13. But you're counting on QuickDraw being present, and it's simply not any more.

Please test the crap out of the latest in Subversion. It touches almost every piece of functionality in the SDL video subsystem on Mac OS X, very late in the game, and it's a totally different block of code than what you'd find in SDL 1.3.

So basically, if this is broken when 1.2.14 ships, it's probably going to stay broken. So test it now!

--ryan.

Is building with Xcode still supported? The Xcode project doesn't seem to have been updated since 2007. Building with Xcode 3.2 under 10.6 fails with "Invalid value '3.3' for GCC_VERSION_ppc".

Grafx2 bug 184 (http://code.google.com/p/grafx2/issues/detail?id=184) which is what I'm really trying to solve depends on this bug...

Ryan, is there already a time frame on SDL 1.2.14?

It would be nice if there was sufficient time to let a lot of people test this release. Besides the QuickDraw changes, some other big changes went in (like configure.in was just changed in a way I fear might cause breakage, see bug #674).

My plan would be to make a "beta release" of SDL 1.2.14 as a Fink package, based on an SVN snapshot -- I usually dislike doing that, but in this case I'd make an exception in the hopes of attracting lots of testers.

Yes, the Xcode projects are being worked on as I type this.

The updated Xcode project builds (although with 36 warnings and 100 analyzer results), and runs on my 10.6 machine. However, there are two deprecated calls in SDLMain.m:

2009-09-22 18.52.41	/Users/pelle/Applications/Grafx2.app/Contents/MacOS/Grafx2[8778]	CPSGetCurrentProcess(): This call is deprecated and should not be called anymore.
2009-09-22 18.52.41	/Users/pelle/Applications/Grafx2.app/Contents/MacOS/Grafx2[8778]	CPSSetForegroundOperationState(): This call is deprecated and should not be called anymore.

It might be a good idea to fix those as well before releasing 1.2.14.

There are deprecated calls in SDL itself, too. frankly, I wouldn't have fixed the ones I did, if they weren't removed for 64-bit apps.

The rest of the deprecated functions will be cleaned up in SDL 1.3.

--ryan.