Are you composing the 32bit colours yourself with fixed code? If so then you may face compatibility issues - not all Windows machines go RGB and I dare guess that not all OS X machines go BGR. I definitely wouldn't be surprised if the order of colours within a word varies between Intel and PowerPC for obvious reasons. makecol32 will sort things out for you though...

Only if they're using the same video cards in the same video modes.

Windows (pre-Vista) makes applications write straight to the framebuffer. OS X keeps a buffer of the current state of each application which, starting with 10.2, is in VRAM (so the graphics card can do window composition).

So, in Windows, RGB/BGR/whatever ordering is determined by the order used by the framebuffer.

In OS X, BGR/RGB/whatever ordering is determined by the order OS X selects for its texture format. After that it is purely hardware driven - OS X will not and cannot impose any legacy order if the hardware doesn't support it.

Neither OS guarantees either order. Allegro figures out the order at runtime, and provides makecol32 so that you can build your 32bit words correctly.

If you assume a byte order based solely on OS then your program will not work on all hardware.

If there is a way to detect what order OSX is using then it should be used instead. In either case I believe this issue has been discussed many times for OSX but I've never seen a solution that caused a good working patch to the lib... Maybe someone with better skills on OSX can create a patch for set_gfx_mode that detects the RGB/BGR order and sets things up appropriately.

Eh?

@OP: Make sure you're loading/creating your graphics after you call set_gfx_mode. Allegro doesn't know the RGB ordering until you call set_gfx_mode(). You may get lucky on one system, but it will fail on others.
If that doesn't help, try reproducing the problem with the Allegro examples.

This makes no sense to me... what do you mean? Can you post some sample code to show what you're doing?

Aside, can a moderator move this topic to Programming Questions instead of Allegro Development?

Right.
As said, this has nothing to do with Windows or MacOS X. The problem is that you hard-code the colour numbers in 16 bits, with a specific RGB ordering (say RGB). Allegro will use the system's native colour ordering, which may be RGB or BGR (or something else entirely). If you're lucky, the ordering you used to encode your colour constants and the one used by the system are the same. If not, you'll end upwith the wrong colours, as you have seen.

Solution: extract the components from your encoded numbers manually (it only takes a shift and a logical and), or store them as RGB triplets.

I meant what I wrote.
Phrased differently, no, you should not be using get[r,g,b]15 on the colour values you hard-coded because you can't predict the order of RGB components on any system.

I don't know the GBA colour encoding, but if it's 15 bit then something like:

... somewhere in your source before you use them ...
#define gba_getb(v) (v&31)
#define gba_getg(v) ((v >> 5)&31)
#define gba_getr(v) (v >> 10)

... to use them ...
r = gba_getr(col);
g = gba_getg(col);
b = gba_getb(col);

Though I may have r, g and b the wrong way round. "&31" effectively says "throw away all but the lowest five bits" and ">> 5" says "move all the bits 5 positions to the right, throw away any that cross the decimal point".

Harte's macros will do exactly that.

indeed, I get better results by multiply the composites by 8.
also, I have to use the makecol24 function instead of makecol and things seems to be ok on Windows.

I'll tell you tonight how it is on the Macintosh. If I understood well, normally, with this method, it should get the same display results no mater the platform and OS. right?

I call makecol24 after the extraction of the 15bits RGB values before applying the color to the pixel. Why?

Any way, I have just tried on Mac OS X what we did today on Windows that is manully extracting the RGB composites and convert them manually to 32 bits colors.

While it is working on Windows, again, colors are still reverted on Mac OS.
I have tried on my Mac Pro with an nVidia video card and on my MacBook Pro with an ATI video card. Both give the same results on Mac OS X: colors are BGR, even when it is handly recoded.

That's really odd!!!

My goal is to have a unique source code based on allegro, no matter the OS it will run on.

For better results, I wish to keep the hard coded 15 bits colors in palettes that I apply to the tile sets when loading them.

I have supplied the ApplyPalette function to see how I apply the colors.

If you have any idea to solve this reversion problem, let me know, I'm opened to any idea.

I'm stucked!