Bug 185850

Created attachment 126326 [details]
Screenshot with not correctly displayed objects

Hmm,

I though that RPM_OPT_FLAGS contained -fsigned-char on ppc, guess not I'll add
it and push a built (once the other issue is resolved, otherwise the game is
barely playable anyway).

Now about the other issue that seems a bigger problem. I have no clue where to
look for this unlike worminator I only packaged raidem, it didn't need any
porting. Can yuo report this upstream please and add any usefull replies here?

Sorry but I think that is the best path to go for now, if upstream is
unresponsive we'll see from there.

Thanks!

Ok, will do. But I'd like to gather some more information first. This may take a
while, because I have to work the next three nights. I'll set you on CC.

I've had contact with upstream about some other stuff and I also brought this
up, it doens't look like upstream si going to be able to fix this so I'm
reopening it.

Created attachment 127406 [details]
Patch with some debuginfo

Can you please try with this patch? and don't forget to add -fsigned-char too.
I don't think this will fix it, but if you run it from the cmdline it should
generate some output which might be of some help.

Damn, forgot about it over upgrading my main box to FC5... ;)

AFAICS, only PNGs with transparent background are affected.
Tried your patch, which doesn't change anything:

[frank@notebook ~]$ LANG=C nohup raidem
nohup: appending output to `nohup.out'
[frank@notebook ~]$ sort -u nohup.out
0 joystick(s) detected.
bingo
c: 117506563 [7][1][2][3]
c: 197121 [0][3][2][1]
Can use page-flipping.

Thanks for testing, hmm okay, so on i386 and x86_64 the output overhere is:
c: 117637633 [1][2][3][7]
c: 197121 [1][2][3][0]

But because I'm using a char pointer first and this is LSB, to read this
correctly as 8 bit parts of an int (as should be done for color formats) it
really is:
c: 117637633 [7][3][2][1]
c: 197121 [0][3][2][1]

KEY: 7 = alpha, 1 = R, 2 = G, 3 = B.
So in other words for alpha using sprites it is ABGR and for the normal case its
BGR, strange but true. Then again allegro calls this format in its docs RGBA so
I guess allegro is just seeing things as an array here not as ints, which would
cause it to be reversed when interpreting it as ints on LSB


On your machine however things are even stranger:
c: 117506563 [7][1][2][3]
c: 197121 [0][3][2][1]

This can be read as is since PPC is MSB so for alpha sprites it is ARGB, but for
normal sprites it is BGR. Now in your screenshot not only are the green
artifacts a problem but also has the colors wrong for the background and the
score panes Red and Blue are Swapped so this is a BGR vs RGB thing.

For the (alpha) sprites however things are even more of it seems that what
should be transparent shows up as a hard green, so the transparent color of the
png seems to get loaded at the place where green should be loaded and
transparency seems to get initialised with 0 (which is logical, for a full
transparent part RGB would all be 0 and transparency 100%).

Long thinking pauze ......

I think I've got this figured out, please try the new attached patch.

Created attachment 127419 [details]
new patch which might fix this

Created attachment 127422 [details]
Screenshot with applied patch

Once again, you're awesome... seems to fix it.

Screenshots looks good, this indeed seems to fix it, luckily since the fix is
kinda guess work not hard science but if it works it works :)

I'll put this in CVS and request a build.