This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch made from the sdl-devel mail by Paolo Bonzini (sdl-coregraphics.patch, text/plain, 2009-09-11 02:47:29 +0000, 28827 bytes)
• Updated version of Paolo's patch. (SDL12-snow-leopard.diff, text/plain, 2009-09-12 08:13:58 +0000, 33957 bytes)
• test program (main.c, text/plain, 2009-09-12 14:35:28 +0000, 2043 bytes)
• Test program in windowed mode (Screen shot 2009-09-15 at 5.39.24 PM.png, image/png, 2009-09-15 16:15:17 +0000, 11445 bytes)
• Test program in fullscreen mode (Screen shot 2009-09-15 at 5.39.42 PM.png, image/png, 2009-09-15 16:15:48 +0000, 11055 bytes)
• Updated version of Paolo's patch rev 2 (SDL12-snow-leopard-2.patch, text/plain, 2009-09-18 05:14:46 +0000, 35068 bytes)

Reported in version: 1.2.13
Reported for operating system, platform: Mac OS X 10.6, PowerPC

Comments on the original bug report:

On 2008-05-03 00:37:16 +0000, Paolo Bonzini wrote:

Leopard deprecated QuickDraw and actually makes it unaccessible in 64-bit mode. The bare minimal changes needed to use CoreGraphics instead are at the URL linked at the top of the page.

Note that the patch disables dirty rectangle handling in windowed mode. For testsprite and a few other test applications this is actually faster.

An alternative approach is to always create an NSOpenGLContext if in windowed mode, even if SDL_OPENGL is not requested. Since the surface pointer returned to the program is an offscreen area, you can then blit to the surface using OpenGL. This would be a much smaller hammer than what 1.3 does, and would not be subject to bugs like # 580.

On 2008-11-20 04:05:24 +0000, Paolo Bonzini wrote:

Update - this bug applies to 1.2.x.

On 2009-08-30 08:33:13 +0000, John Barberio wrote:

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)

On 2009-08-30 08:34:01 +0000, John Barberio wrote:

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

On 2009-09-11 02:47:29 +0000, Max Horn wrote:

Created attachment 352
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.

On 2009-09-11 02:54:00 +0000, Max Horn wrote:

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 :/)

On 2009-09-11 03:37:20 +0000, Paolo Bonzini wrote:

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...

On 2009-09-11 21:25:03 +0000, Ryan C. Gordon wrote:

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.

On 2009-09-11 21:26:22 +0000, Ryan C. Gordon wrote:

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

On 2009-09-12 02:04:55 +0000, Paolo Bonzini wrote:

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.

On 2009-09-12 08:13:58 +0000, Ryan C. Gordon wrote:

Created attachment 353
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.

On 2009-09-12 08:17:37 +0000, Ryan C. Gordon wrote:

Changed platform to 10.6 in Bugzilla.

--ryan.

On 2009-09-12 14:03:21 +0000, Max Horn wrote:

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.

On 2009-09-12 14:35:28 +0000, Paolo Bonzini wrote:

Created attachment 354
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?

On 2009-09-13 16:33:03 +0000, Ryan C. Gordon wrote:

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.

On 2009-09-15 15:41:12 +0000, Kenny Root wrote:

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.

On 2009-09-15 16:07:36 +0000, Paolo Bonzini wrote:

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

On 2009-09-15 16:15:17 +0000, Kenny Root wrote:

Created attachment 357
Test program in windowed mode

Only changes in brightness if I press a key

On 2009-09-15 16:15:48 +0000, Kenny Root wrote:

Created attachment 358
Test program in fullscreen mode

Only changes in brightness if I press a key

On 2009-09-15 16:28:28 +0000, Paolo Bonzini wrote:

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.

On 2009-09-15 16:35:19 +0000, Kenny Root wrote:

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.

On 2009-09-17 20:17:31 +0000, Kenny Root wrote:

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

On 2009-09-17 23:00:05 +0000, Paolo Bonzini wrote:

Would you please attach a new patch?

Thanks!

On 2009-09-18 05:14:46 +0000, Kenny Root wrote:

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

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

On 2009-09-20 23:16:48 +0000, Ryan C. Gordon wrote:

An updated version of Kenny's patch (Attachment # 361) 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.

On 2009-09-21 07:49:04 +0000, Per Olofsson wrote:

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...

On 2009-09-21 09:22:22 +0000, Max Horn wrote:

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.

On 2009-09-21 13:22:23 +0000, Sam Lantinga wrote:

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

On 2009-09-22 10:01:46 +0000, Per Olofsson wrote:

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.

On 2009-09-27 21:47:59 +0000, Ryan C. Gordon wrote:

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.