glest will not start properly [ppc]

[xavier]

Hello,

I have installed glest using on my gentoo linux Powerbook g4 (I used the gentoo way of doing the install, via emerge). It supports Opengl and direct rendering.

When I start the game, I get a black screen and cannot switch back to the X desktop. The only solution is to go to a text console and to kill glest. By the way, I can see that glest uses all the cpu in top (almost 100 %).

Any ideas ?

[xavier]

Ok, I just found the line below in a README I found in the glest source tarball:

Code: [Select]

* The game does not work on ppc (big endian architectures) yet

I had not seen this remark before I compiled the game and tried to use it, since I use the gentoo port (emerge), which does not issue any remark about the architecture (it usually does and will not install a program on a computer it is not supposed to work on).

As a consequence, I change my question:
- is the message above still valid ?
- is there any plan to make it wrong soon in case it is still valid ?

By the way, I will try to install this on a x86 tomorrow.

[martiño]

Yes, the game does not run on big endian architectures, I think that someone made a patch for an old version that fixed the issue, but since ppc architectures represent a very small fraction of the market there is no current plans to make Glest processor independant.

[xavier]

Yes, the game does not run on big endian architectures, I think that someone made a patch for an old version that fixed the issue, but since ppc architectures represent a very small fraction of the market there is no current plans to make Glest processor independant.

Too bad, the game looked nice; I will not be able to run it    
What are the reasons why it is endian-dependant ? (if I find time, I may consider trying to patch it).

[martiño]

Too bad, the game looked nice; I will not be able to run it Sad Sad Sad
What are the reasons why it is endian-dependant ? (if I find time, I may consider trying to patch it).

It is endian dependant because of some binary files used by the game, that as far as I remember include gbm, tga, bmp, wav and g3d files. To be fair it wouldn´t be very dificult to fix it, but I just don´t have the time.

[xavier]

Ok, then I may look at this issue if I find time.

[benh]

Xavier, any news ? Did you make any progress ? Even something partial, I can try to help too...

Martinho:  I understand you don't have time to maintain big endian properly, but would you accept patches attempting to make the game a little bit more endian neutral (not I haven't looked yet how hard it would be) and maybe, in the future, try to use endian-safe accessors for datas on the wire (disk/network) ?

Cheers,
Ben.

[xavier]

Xavier, any news ? Did you make any progress ? Even something partial, I can try to help too...

Unfortunately, no news: I have had a quick look one month or so ago, but did not write anything at this time and I am too busy now (and I expect to be for roughly another month). I have not lost hope to devote some time to this, but cannot do it now...