Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » is A5 supposed to work on PPC?

This thread is locked; no one can reply to it. rss feed Print
is A5 supposed to work on PPC?
Matthew Leverton
Supreme Loser
January 1999
avatar

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.

Evert
Member #794
November 2000
avatar

It is supposed to work, yes.
This

"dyld: Symbol not found: __al_kcm_aqueue_driver".

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

Peter Wang
Member #23
April 2000

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.

Matthew Leverton
Supreme Loser
January 1999
avatar

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.

Evert
Member #794
November 2000
avatar

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.

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

I'll try looking into it this week.

Matthew Leverton
Supreme Loser
January 1999
avatar

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.

Evert
Member #794
November 2000
avatar

A) is there a different way to load that pixel data

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

Quote:

b) can we disable the native image loader on PPC?

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

Matthew Leverton
Supreme Loser
January 1999
avatar

Evert said:

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's part of the problem.

image.m#SelectExpand
96 ALLEGRO_LOCKED_REGION *lock = al_lock_bitmap(bmp,
97 ALLEGRO_PIXEL_FORMAT_RGBA_8888, ALLEGRO_LOCK_WRITEONLY);
98 int i; 99 if (!premul) { 100 int x; 101 for (i = 0; i < h; i++) { 102 unsigned char *src_ptr = (unsigned char *)pixels + w * 4 * i; 103 unsigned char *dest_ptr = (unsigned char *)lock->data + 104 lock->pitch * i; 105 for (x = 0; x < w; x++) { 106 unsigned char r, g, b, a; 107 r = *src_ptr++; 108 g = *src_ptr++; 109 b = *src_ptr++; 110 a = *src_ptr++; 111 // NOTE: avoid divide by zero by adding a fraction 112 float alpha_mul = 255.0f / (a+0.001f); 113 r *= alpha_mul; 114 g *= alpha_mul; 115 b *= alpha_mul; 116 *dest_ptr++ = r; 117 *dest_ptr++ = g; 118 *dest_ptr++ = b; 119 *dest_ptr++ = a; 120 } 121 } 122 } 123 else { 124 for (i = 0; i < h; i++) { 125 memcpy(lock->data + lock->pitch * i, pixels + w * 4 * i, w * 4); 126 } 127 } 128 al_unlock_bitmap(bmp);

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

Quote:

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

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

Michał Cichoń
Member #11,736
March 2010

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

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Matthew Leverton
Supreme Loser
January 1999
avatar

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"}602953

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.

Go to: