SDL_WM_SetIcon on Intel Mac (using the universal SDL framework)

I’m using the universal build (Mac) of the SDL framework to create a
universal version
of my game. Everything has gone well, except one item: When I call
SDL_WM_SetIcon to set the icon, the call works, but the result has
colour
problems. The icon ends up displaying with a very red bias.

This is probably an endian issue, so I tried manually swapping the
byte values
around, but it doesn’t seem to help… I just get other strange
colour versions
of the icon :slight_smile:

Any ideas? Perhaps this portion of the SDL source wasn’t modified
when the
universal version was built?

Thanks for the help,

Ryan

Ryan Clark wrote:

I’m using the universal build (Mac) of the SDL framework to create a
universal version of my game. Everything has gone well, except one
item: When I call SDL_WM_SetIcon to set the icon, the call works, but
the result has colour problems. The icon ends up displaying with a
very red bias.

I’ve never used SDL_WM_SetIcon, but upon a cursory glance at the source
(QZ_SetIcon() in SDL_QuartzWM.m), it seems that there are several things
wrong with it:

  • It uses a big endian surface (even explicitly says so in a comment)
    that should be little endian on little endian machines. Obviously this
    was written before there were little endian Macs. That’s probably the
    bug you’re seeing.

  • It seems to make all pixels whose mask bits are set (which are all
    that are not completely transparent if the mask was autogenerated from
    an alpha channel) completely opaque, even if they should be
    semi-transparent.

  • It creates an intermediate surface, passes its pixels to
    [NSBitmapImageRep initWith…], which does not copy the pixels, and
    then frees the surface again. Depending on whether [NSApp
    setApplicationIconImage: img] copies or retains the image, this could
    lead to problems. This should probably be done by letting the
    NSBitmapImageRep allocate the space and using SDL_CreateRGBSurfaceFrom()
    on it.

  • It passes non-premultiplied alpha data to [NSBitmapImageRep
    initWith…], which wants premultiplied alpha.

I’ll have a closer look and see if I can come up with a patch. I don’t
have an Intel Mac to test it on, though. Can you file a bug in the
meantime (for your initial observation only, not for my unconfirmed
suspicions, to be on the safe side :slight_smile: )? http://bugzilla.libsdl.org/

-Christian

Thanks for the help, Christian. I’ve added the bug report to
bugzilla (Bug 208).

In the meantime, can you recommend a workaround? Is there some way I
can modify my surface before calling SDL_WM_SetIcon such that it will
end up displaying properly? I’ve take a look at the QZ_SetIcon
source, but I must admit, it’s difficult for me to follow.

RyanOn 30-Apr-06, at 4:40 AM, Christian Walther wrote:

Ryan Clark wrote:

I’m using the universal build (Mac) of the SDL framework to create a
universal version of my game. Everything has gone well, except one
item: When I call SDL_WM_SetIcon to set the icon, the call works, but
the result has colour problems. The icon ends up displaying with a
very red bias.

I’ve never used SDL_WM_SetIcon, but upon a cursory glance at the
source
(QZ_SetIcon() in SDL_QuartzWM.m), it seems that there are several
things
wrong with it:

  • It uses a big endian surface (even explicitly says so in a comment)
    that should be little endian on little endian machines. Obviously this
    was written before there were little endian Macs. That’s probably the
    bug you’re seeing.

  • It seems to make all pixels whose mask bits are set (which are all
    that are not completely transparent if the mask was autogenerated from
    an alpha channel) completely opaque, even if they should be
    semi-transparent.

  • It creates an intermediate surface, passes its pixels to
    [NSBitmapImageRep initWith…], which does not copy the pixels, and
    then frees the surface again. Depending on whether [NSApp
    setApplicationIconImage: img] copies or retains the image, this could
    lead to problems. This should probably be done by letting the
    NSBitmapImageRep allocate the space and using
    SDL_CreateRGBSurfaceFrom()
    on it.

  • It passes non-premultiplied alpha data to [NSBitmapImageRep
    initWith…], which wants premultiplied alpha.

I’ll have a closer look and see if I can come up with a patch. I don’t
have an Intel Mac to test it on, though. Can you file a bug in the
meantime (for your initial observation only, not for my unconfirmed
suspicions, to be on the safe side :slight_smile: )? http://bugzilla.libsdl.org/

-Christian


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

In the meantime, can you recommend a workaround? Is there some way I
can modify my surface before calling SDL_WM_SetIcon such that it will
end up displaying properly? I’ve take a look at the QZ_SetIcon
source, but I must admit, it’s difficult for me to follow.

If you don’t have to modify the icon at runtime, on the Mac, just set it
up in the app’s Info.plist file, and point it at a real .icns
file…this is probably why no one noticed the bug before. :slight_smile:

–ryan.

Thanks, Ryan. I should’ve realized that!On 30-Apr-06, at 1:17 PM, Ryan C. Gordon wrote:

In the meantime, can you recommend a workaround? Is there some way I
can modify my surface before calling SDL_WM_SetIcon such that it will
end up displaying properly? I’ve take a look at the QZ_SetIcon
source, but I must admit, it’s difficult for me to follow.

If you don’t have to modify the icon at runtime, on the Mac, just
set it
up in the app’s Info.plist file, and point it at a real .icns
file…this is probably why no one noticed the bug before. :slight_smile:

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl