Bug 185850 - Raidem doesn't start on ppc
Raidem doesn't start on ppc
Product: Fedora
Classification: Fedora
Component: raidem (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-03-19 14:53 EST by Frank Arnold
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-06 16:16:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Screenshot with not correctly displayed objects (205.32 KB, image/png)
2006-03-19 14:53 EST, Frank Arnold
no flags Details
Patch with some debuginfo (1.46 KB, patch)
2006-04-06 07:43 EDT, Hans de Goede
no flags Details | Diff
new patch which might fix this (1.57 KB, patch)
2006-04-06 14:41 EDT, Hans de Goede
no flags Details | Diff
Screenshot with applied patch (289.13 KB, image/png)
2006-04-06 15:10 EDT, Frank Arnold
no flags Details

  None (edit)
Description Frank Arnold 2006-03-19 14:53:06 EST
Me again... :)

Raidem hangs on startup, using 100% CPU without displaying anything.
Solution is the same as it was for worminator. Add -fsigned-char to CFLAGS.

Some of the "sprites" are odd looking. When there is some action the whole
screen is filled green. See attached screenshot. Not tested on other archs.
Comment 1 Frank Arnold 2006-03-19 14:53:06 EST
Created attachment 126326 [details]
Screenshot with not correctly displayed objects
Comment 2 Hans de Goede 2006-03-19 15:44:27 EST

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.

Comment 3 Frank Arnold 2006-03-20 12:06:42 EST
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.
Comment 4 Hans de Goede 2006-04-06 07:41:05 EDT
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.
Comment 5 Hans de Goede 2006-04-06 07:43:58 EDT
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.
Comment 6 Frank Arnold 2006-04-06 12:22:24 EDT
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.
c: 117506563 [7][1][2][3]
c: 197121 [0][3][2][1]
Can use page-flipping.
Comment 7 Hans de Goede 2006-04-06 14:40:27 EDT
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.
Comment 8 Hans de Goede 2006-04-06 14:41:19 EDT
Created attachment 127419 [details]
new patch which might fix this
Comment 9 Frank Arnold 2006-04-06 15:10:32 EDT
Created attachment 127422 [details]
Screenshot with applied patch

Once again, you're awesome... seems to fix it.
Comment 10 Hans de Goede 2006-04-06 16:16:06 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.