Testing on OS X 10.4 PPC.

Attached is what it looks like when loading the mysha PNG image. The PCX version worked. (TGA did not.) I've mentioned that before; there was some discussion, but no resolutions.

I tried running the speed demo, but it just failed complaining that "dyld: Symbol not found: __al_kcm_aqueue_driver".

This is just an FYI to anybody who cares. I'm not going to actively debug anything, and as far as I'm concerned a proper fix is simply dropping support for PPC altogether.

It is supposed to work, yes.
This

is more a problem with 10.4 than PPC though. I'm sure I fixed a similar problem ages ago, should be easy to fix (the driver can't be built on 10.4 and should be disabled and unreferenced).

Do you know if it's the native image loader, or the libpng loader? Mainly curious.

FYI I intend to release RC3 soon, and it would be nice (not important) to have either of these issues fixed.

PNG works with libpng, but not on native loader. TGA doesn't work on either, but I don't even know if the native loader handles TGAs.

I think so; the list of formats handled by the native loader is written to the log file.

I'll try looking into it this week.

I added this to the image.m file:

   fp = al_fopen("image.dump", "wb");
   al_fwrite(fp, pixels, w * h * 4);
   al_fclose(fp);

immediately before looping over it. The output definitely does not correspond perfectly to the raw image data. There appears to be areas of garbage (particularly at the beginning of the image).

So A) is there a different way to load that pixel data or b) can we disable the native image loader on PPC?

I think there still is the issue of the built-in TGA loader.

The code itself looks fine to me, so I'm not sure what's going on. It doesn't look like an endianess problem?

That should be relatively easy (certainly by hand), but does that solve the problem?

That's part of the problem.

If I change the highlighted line from ABGR to RGBA it works. I don't know why the code would even work on Intel, it doesn't seem right to me.

(Edit: Or maybe ALLEGRO_PIXEL_FORMAT_ABGR_8888_LE would be appropriate. The documentation is confusing, as it talks about not being dependent on endian and then later says it is.)

Note that I changed ex_bitmap to not pre-multiply that way I could edit the block of code that let me easily change the parameters around. (Although I ended up just changing the pixel format, which would affect both parts.)

Now with the above change, there are still some artifacts. See the attached picture vs the attached picture in the first post. I verified that the image is correct on disk.

I created a 256x256 PNG image with RGBA of 0x112233FF. The raw image dump of the pixel data had 256 pixels (0x400 bytes) of 0x000000FF to begin with, which makes no sense. Also, the data ended up as 0x132133FF, which is close but not the exact pixels.

The parrot JPEG ends up looking like a black and white photograph that is skewed by 45 degrees (as if the source lines are longer than expected).

libpng and libjpeg work. I think there may still be endian issues with Allegro's TGA loader.

PPC is big endain system and require byte swap in some places.

I'm aware of that; it's just the documentation is a bit confusing.

I think what it's trying to say is that if you use ALLEGRO_PIXEL_FORMAT_ABGR_8888, then the following is not guaranteed to work:

// dest_ptr = 8 bit
*dest_ptr++ = r;  
*dest_ptr++ = g;  
*dest_ptr++ = b;  
*dest_ptr++ = a;

But that this should work:

// dest_ptr = 32 bit
*dest_ptr++ = (a << 24) | (b << 16) | (g  << 8) | r;

For this code, though, I think using ALLEGRO_PIXEL_FORMAT_ABGR_8888_LE would cause it to work on both PPC and Intel OS X.

However, none of this directly explains the other oddities with the image loading on PPC.

Update

I just committed the updates to fix the endian issues to Allegro's TGA loader (seemed to only affect 32-bit images) and the native image loader. However, the native loader still produces garbage (although the colors are right now).

A screenshot of a JPEG file is attached.

{"name":"602953","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/f\/1fc009815097739a7eea46c4742363c9.png","w":640,"h":502,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/f\/1fc009815097739a7eea46c4742363c9"}

TGA files are as posted earlier. (Almost correct, but with some horizontal artifacts.)

This could be an OS X 10.4 issue... whatever the problem is, the source data after loading the image is not the expected raw RGB values.