Graphical differences between Mac OS X on Intel and PowerPC

SDL Development
1

Hi all,
I created an Universal Binary on Mac OS X 10.4.11 on an Intel Mac Book.
This executes correctly and looks and behaves the way it was designed to
work. This application ( GameMaker ) uses OpenGL and SDL for rendering.

I then got hold of a Mac Mini, G4 1.42Gz PowerPC, running 10.4.11. Running
exactly the same Universal exe on the Mac Mini produces the correct
behaviour, but an incorrect appearance. On the Mac Mini there seems to be
serious issues with transparency and an overall pink tinge to the images
produced on screen.

  1. Has anyone seen this sort of thing before?
  2. Could this be an OpenGL driver issue? If so, how do I update drivers on
    the Mac Mini because “Software Update” does not seem to pick up any new
    drivers for the graphics card.
  3. Any other suggestions?

I believe the error may be caused by the following IFDEFed code…

{$IFDEF CPUPOWERPC}
tempSurface := SDL_CreateRGBSurfaceFrom( aWordArray, aWidth, aHeight,
32, aWidth * 4, $FF000000, $00FF0000, $0000FF00, $000000FF );
{$ENDIF}
{$IFDEF CPUi386}
tempSurface := SDL_CreateRGBSurfaceFrom( aWordArray, aWidth, aHeight,
32, aWidth * 4, $000000FF, $0000FF00, $00FF0000, $FF000000 );
{$ENDIF}
{$IFDEF CPUARM}
tempSurface := SDL_CreateRGBSurfaceFrom( aWordArray, aWidth, aHeight,
32, aWidth * 4, $000000FF, $0000FF00, $00FF0000, $FF000000 );
{$ENDIF}

The CPUi386 code looks 100% correct, but the CPUPOWERPC does not. I’m not
familiar with the differences between how Mac OS X handles OpenGL on Intel
and PowerPC machines. I’m not really worried about CPUARM for now, but I’ve
left it there in case someone here knows that side of things as well.

I’m open to any suggestions.

Thanks,

Dominique.

2

I then got hold of a Mac Mini, G4 1.42Gz PowerPC, running 10.4.11.
Running
exactly the same Universal exe on the Mac Mini produces the correct
behaviour, but an incorrect appearance. On the Mac Mini there seems
to be
serious issues with transparency and an overall pink tinge to the
images
produced on screen.

  1. Has anyone seen this sort of thing before?

Jupp, have seen very similar behaviour.

  1. Could this be an OpenGL driver issue? If so, how do I update
    drivers on
    the Mac Mini because “Software Update” does not seem to pick up any
    new
    drivers for the graphics card.

No, I think it is a problem in SDL itself. You are using software
surfaces here and AFAIK, all of the blitting should be done in
software (only the final blit to the screen is done via OpenGL).

  1. Any other suggestions?

I believe the error may be caused by the following IFDEFed code…

{$IFDEF CPUPOWERPC}
tempSurface := SDL_CreateRGBSurfaceFrom( aWordArray, aWidth,
aHeight,
32, aWidth * 4, $FF000000, $00FF0000, $0000FF00, $000000FF );
{$ENDIF}
{$IFDEF CPUi386}
tempSurface := SDL_CreateRGBSurfaceFrom( aWordArray, aWidth,
aHeight,
32, aWidth * 4, $000000FF, $0000FF00, $00FF0000, $FF000000 );
{$ENDIF}
{$IFDEF CPUARM}
tempSurface := SDL_CreateRGBSurfaceFrom( aWordArray, aWidth,
aHeight,
32, aWidth * 4, $000000FF, $0000FF00, $00FF0000, $FF000000 );
{$ENDIF}

Yes, I stumbled upon exactly the same problem. It seems, if you use this

#define ALPHASURFACE_RMASK 0x00ff0000
#define ALPHASURFACE_GMASK 0x0000ff00
#define ALPHASURFACE_BMASK 0x000000ff
#define ALPHASURFACE_AMASK 0xff000000

for all architectures, it works fine.

This seem to be the case because these are hardcoded like that in
SDL_video.c in SDL_DisplayFormatAlpha. (Not sure anymore about the
details, that is what my comment in the code says about it…)

Perhaps try that out.

Transparence issues could be another thing: It seems to require a
SDL_FillRect() with pure black color (without alpha) on your video
screen at the very beginning. At least that fixed some problems for us.Am 07.06.2009 um 13:02 schrieb dominique at savagesoftware.com.au:

3

Caveat: as my last attempt to help someone demonstrated, it’s been a while since I’ve done any of this so check this works before deciding whether to thank me.

However, if I remember right it’s not quite so straightforward between all systems as accounting for the swap in endianness. What the graphics hardware expects on those systems can be difficult as well and some systems only swap parts.

What it might be worth trying is swapping the RGB parts of the mask but leaving the Alpha in the same place eg

i386 ABGR $000000FF, $0000FF00, $00FF0000, $FF000000
PPC ARGB $00FF0000, $0000FF00, $000000FF, $FF000000

One way to check things would be to create a small program to load a bitmap (as in .bmp so as not to rely on SDL_Image) and output the Uint32 numbers from SDL_Surface->format->RMask, Gmask, Bmask and Amask. This should give the masks for the data after it’s been converted for display by SDL.

Have a look at http://docs.huihoo.com/sdl/1.2/sdlsurface.html and http://docs.huihoo.com/sdl/1.2/sdlpixelformat.html for the struct definitions.

wrote:> From: dominique at savagesoftware.com.au

Subject: [SDL] Graphical differences between Mac OS X on Intel and PowerPC…
To: sdl at lists.libsdl.org
Date: Sunday, June 7, 2009, 11:02 AM
Hi all,
? I created an Universal Binary on Mac OS X 10.4.11 on
an Intel Mac Book.
This executes correctly and looks and behaves the way it
was designed to
work. This application ( GameMaker ) uses OpenGL and SDL
for rendering.

I then got hold of a Mac Mini, G4 1.42Gz PowerPC, running
10.4.11. Running
exactly the same Universal exe on the Mac Mini produces
the correct
behaviour, but an incorrect appearance. On the Mac Mini
there seems to be
serious issues with transparency and an overall pink tinge
to the images
produced on screen.

  1. Has anyone seen this sort of thing before?
  2. Could this be an OpenGL driver issue? If so, how do I
    update drivers on
    the Mac Mini because “Software Update” does not seem to
    pick up any new
    drivers for the graphics card.
  3. Any other suggestions?

I believe the error may be caused by the following IFDEFed
code…

???{$IFDEF CPUPOWERPC}
? ? tempSurface := SDL_CreateRGBSurfaceFrom(
aWordArray, aWidth, aHeight,
32, aWidth * 4, $FF000000, $00FF0000, $0000FF00, $000000FF
);
? ? {$ENDIF}
? ? {$IFDEF CPUi386}
? ? tempSurface := SDL_CreateRGBSurfaceFrom(
aWordArray, aWidth, aHeight,
32, aWidth * 4, $000000FF, $0000FF00, $00FF0000, $FF000000
);
? ? {$ENDIF}
? ? {$IFDEF CPUARM}
? ? tempSurface := SDL_CreateRGBSurfaceFrom(
aWordArray, aWidth, aHeight,
32, aWidth * 4, $000000FF, $0000FF00, $00FF0000, $FF000000
);
? ? {$ENDIF}

The CPUi386 code looks 100% correct, but the CPUPOWERPC
does not. I’m not
familiar with the differences between how Mac OS X handles
OpenGL on Intel
and PowerPC machines. I’m not really worried about CPUARM
for now, but I’ve
left it there in case someone here knows that side of
things as well.

I’m open to any suggestions.

Thanks,

Dominique.

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

4

Thanks to everyone who replied.

I did try shifting the colour values around and tried various combinations,
but the closest I could get to it working correctly was the one mentioned
by Paul Duffy.
Namely…
i386 ABGR $000000FF, $0000FF00, $00FF0000, $FF000000
PPC ARGB $00FF0000, $0000FF00, $000000FF, $FF000000

This gives the attached following results.

http://www.savagesoftwaresolutions.com/download/Mac OS X Intel.jpg
and
http://www.savagesoftwaresolutions.com/download/Mac OS X PowerPC.jpg

The Correct one is the “Mac OS X Intel.jpg”, while as you can see the
PowerPC version correctly handles
transparency, but all the tiles have a blue hue to them.

Is there such a things a GBRA or GRBA or varitions thereof?

Btw, I’m using SDL 1.2 if that makes any difference.

Dominique.

5

Well, looking at the screenshots it’s clear that some elements are displaying entirely correctly. They look like basic rectangles which SDL would be converting the colourspace for, yes?

If you load a bitmap on PPC and display that without blitting it to any surface other than the video surface, does it display correctly?

If so, I’d look at the mask, loss and shift values in the surface ‘format’ struct and use those values for creating the surface (studying what createRGBSurface does may also help, one of the advantages of access to the source code).

What are the mask/loss/shift values for the compositing surface? The display surface?

I’d like to be of more help, but I’ve not done anything on OS X never mind on PPC. I only know what I’ve picked up from other people.— On Sun, 6/7/09, dominique at savagesoftware.com.au wrote:

From: dominique at savagesoftware.com.au
Subject: Re: [SDL] Graphical differences between Mac OS X on Intel and PowerPC…
To: sdl at lists.libsdl.org
Date: Sunday, June 7, 2009, 5:22 PM
Thanks to everyone who replied.

I did try shifting the colour values around and tried
various combinations,
but the closest I could get to it working correctly was the
one mentioned
by Paul Duffy.
Namely…
i386 ABGR $000000FF, $0000FF00, $00FF0000, $FF000000
PPC ARGB $00FF0000, $0000FF00, $000000FF, $FF000000

This gives the attached following results.

http://www.savagesoftwaresolutions.com/download/Mac OS
X Intel.jpg
and
http://www.savagesoftwaresolutions.com/download/Mac OS
X PowerPC.jpg

The Correct one is the “Mac OS X Intel.jpg”, while as you
can see the
PowerPC version correctly handles
transparency, but all the tiles have a blue hue to them.

Is there such a things a GBRA or GRBA or varitions
thereof?

Btw, I’m using SDL 1.2 if that makes any difference.

Dominique.

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

6

Have you tried using the pixel format? Perhaps add a printf or whatever
and see what it reports on each target ?

http://www.libsdl.org/cgi/docwiki.cgi/SDL_PixelFormat

I would try myself but only have powerpc mac. This is what i use and
works here. I stated this before in another thread, I got bitten by
assuming RGBA and endian.

mattOn Sun, 7 Jun 2009, dominique at savagesoftware.com.au wrote:

Hi all,
I created an Universal Binary on Mac OS X 10.4.11 on an Intel Mac Book.
This executes correctly and looks and behaves the way it was designed to
work. This application ( GameMaker ) uses OpenGL and SDL for rendering.

I then got hold of a Mac Mini, G4 1.42Gz PowerPC, running 10.4.11. Running
exactly the same Universal exe on the Mac Mini produces the correct
behaviour, but an incorrect appearance. On the Mac Mini there seems to be
serious issues with transparency and an overall pink tinge to the images
produced on screen.

  1. Has anyone seen this sort of thing before?
  2. Could this be an OpenGL driver issue? If so, how do I update drivers on
    the Mac Mini because “Software Update” does not seem to pick up any new
    drivers for the graphics card.
  3. Any other suggestions?

I believe the error may be caused by the following IFDEFed code…

{$IFDEF CPUPOWERPC}
tempSurface := SDL_CreateRGBSurfaceFrom( aWordArray, aWidth, aHeight,
32, aWidth * 4, $FF000000, $00FF0000, $0000FF00, $000000FF );
{$ENDIF}
{$IFDEF CPUi386}
tempSurface := SDL_CreateRGBSurfaceFrom( aWordArray, aWidth, aHeight,
32, aWidth * 4, $000000FF, $0000FF00, $00FF0000, $FF000000 );
{$ENDIF}
{$IFDEF CPUARM}
tempSurface := SDL_CreateRGBSurfaceFrom( aWordArray, aWidth, aHeight,
32, aWidth * 4, $000000FF, $0000FF00, $00FF0000, $FF000000 );
{$ENDIF}

The CPUi386 code looks 100% correct, but the CPUPOWERPC does not. I’m not
familiar with the differences between how Mac OS X handles OpenGL on Intel
and PowerPC machines. I’m not really worried about CPUARM for now, but I’ve
left it there in case someone here knows that side of things as well.

I’m open to any suggestions.

Thanks,

Dominique.

7

The PowerPC version has red and blue channels swapped. Use this instead:

i386 RGBA $000000FF, $0000FF00, $00FF0000, $FF000000
PPC ARGB $000000FF, $0000FF00, $00FF0000, $FF000000

(same for both)

Remember, with PPC, the way the numbers themselves are stored is reversed,
so 0xAABBGGRR would be stored as AA, BB, GG, RR (MSB first) on PPC, and as
RR, GG, BB, AA (LSB first) on i386, which is apparently what you need.On Sunday, 7 June 2009 13:22:38 dominique at savagesoftware.com.au wrote:

Namely…
i386 ABGR $000000FF, $0000FF00, $00FF0000, $FF000000
PPC ARGB $00FF0000, $0000FF00, $000000FF, $FF000000

This gives the attached following results.

http://www.savagesoftwaresolutions.com/download/Mac OS X Intel.jpg
and
http://www.savagesoftwaresolutions.com/download/Mac OS X PowerPC.jpg

The Correct one is the “Mac OS X Intel.jpg”, while as you can see the
PowerPC version correctly handles
transparency, but all the tiles have a blue hue to them.

8

i386 RGBA $000000FF, $0000FF00, $00FF0000, $FF000000
PPC ARGB $000000FF, $0000FF00, $00FF0000, $FF000000

(same for both)

Remember, with PPC, the way the numbers themselves are stored is
reversed,
so 0xAABBGGRR would be stored as AA, BB, GG, RR (MSB first) on PPC, and
as
RR, GG, BB, AA (LSB first) on i386, which is apparently what you need.

Hi Kenneth,
When I tried the same for both, the PowerPC version just comes out as
Green and the transparency does work.
Or maybe I misunderstand what you mean exactly.

Dominique.On Tue, 9 Jun 2009 05:32:36 -0400, Kenneth Bull wrote:

9

ok… At this point I’d say use MapRGBA and GetRGBA. If you run into the same
problem then, make sure your images are formatted correctly on disk and submit
a bug report.

if you’re using floating point values you can also do this:
pixel = (unsigned)(red * format->Rmask) & format->Rmask ||
(unsigned)(green* format->Gmask) & format->Gmask ||
(unsigned)(blue * format->Bmask) & format->Bmask ||
(unsigned)(alpha * format->Amask) & format->Amask;
and
red = (double)(pixel & format->Rmask) / format->Rmask;
etc.On Wednesday, 10 June 2009 04:32:52 dominique at savagesoftware.com.au wrote:

Hi Kenneth,
When I tried the same for both, the PowerPC version just comes out as
Green and the transparency does work.
Or maybe I misunderstand what you mean exactly.