GP2X Anyone Up For Go On Gp2x?


I just got hooked on Go but I don't think I'm a good enough programmer to make this run on GP2X. GNU Go can be found here.

LOL another one hooked by Hikaru No Go. I've tried to learn on my one, but that game as it stands just beats me too easily. I tried to find a Go club in london as I quite liked the idea of learning a bit more and the only one I found on the web was a little stale.

BTW have you seen the GO Linux Live-CD they seem to have one of those for everything. Sorry to steal your thread :).

I personally belive that the gnu board games are a must chess/backgammon etc. I think they add long term playability an arcade game does not offer.http://www.hikarunix.org/
 
Last edited by a moderator:
I've actually not seen Hikaru no Go but I'm planning to. It's the national game week here in Sweden and I had the chance to learn Go yesterday. I find the strategy to be far more interesting then Chess or Othello. I've never tried backgammon.

For those unfamiliar with go it's an ancient Chinese board game that's over 3000 years old. You play with white and black stones that represents military units of 2 armies. The goal of the game is to capture and secure territory and to take enemy units as prissoners. The rules are very simple but the game is very hard to master.
 
Stunningly good board game... indeed, I'd say its the best I've come across.

I'd offer to port it, but my knowledge with C/C++ is limited such that it'd be an empty offer; no chance of it happening by my hands.

On the other hand, I'd be *very* grateful if someone could bring across one of the versions of GNUgo... although if they could make it wait between 3 and 10 seconds for its moves (even after it knows where to play), that'd be cool, since it'd give it much more of a feeling of playing a human player imo.
 
You're right, Go is a great game, and GNU go is just screaming to be ported.

If I have spare time I'll try and have a crack at it. (No promises though, I haven't ported anything ever yet...)
 
I've managed to cross compile GNU Go, I don't know if it will work because:

1) I don't have a GP2X to test it on :(

2) As part of the build process, GNU Go creates some executables (mkpat, mkeyes and joseki) that it uses to generate other files. Unfortunately, when cross compiled, they won't run, so I first compiled them for x86 Linux and used the resulting executables to replace the arm-linux versions.

Could someone please try it out?

Get it here
 
Just cross-compiling won't be very useful by itself I guess, because it runs from a terminal.

So an additional (SDL) GUI needs to be written.

I've just managed to compile GNU Go into my SDL program... on to the interface! (And afterwards a cross-compile... stay tuned)
 
RiX0R posted on Dec 9 2005 at 10:25 PM said:
Just cross-compiling won't be very useful by itself I guess, because it runs from a terminal.

So an additional (SDL) GUI needs to be written.

I've just managed to compile GNU Go into my SDL program... on to the interface! (And afterwards a cross-compile... stay tuned)

The point of my original post was that now sterm is available it might be possible to run GNU Go without modification. I agree that a proper SDL program will be far better but will take longer than the hour it took me to produce a version for sterm.
 
Last edited by a moderator:
How would you execute it from sterm? (the two ways I tried didn't work, so I don't know if I did something wrong or it sterm couldn't execute it)
 
Parkydr posted on Dec 9 2005 at 11:18 PM said:
The point of my original post was that now sterm is available it might be possible to run GNU Go without modification.  I agree that a proper SDL program will be far better but will take longer than the hour it took me to produce a version for sterm.

You're right. I'm way too short-sighted today...

In any case, I just tried it under sterm, and it does indeed work.

Could you explain in a bit more detail how you did get it to compile for arm-linux? Seeing as I'm going to have to go through the same thing shortly... I'd very much appreciate some prior caveats :).


Edit: the game does not need extra "thinking delay". It's taking its merry time as it is right now: on the average 30 seconds to a minute for a move (during the opening, I'm guessing the response speed may increase when the number of possible moves is reduced and the game gets to use its cache).
 
Last edited by a moderator:
RiX0R posted on Dec 10 2005 at 12:42 AM said:
Parkydr posted on Dec 9 2005 at 11:18 PM said:
The point of my original post was that now sterm is available it might be possible to run GNU Go without modification.  I agree that a proper SDL program will be far better but will take longer than the hour it took me to produce a version for sterm.

You're right. I'm way too short-sighted today...

In any case, I just tried it under sterm, and it does indeed work.

Could you explain in a bit more detail how you did get it to compile for arm-linux? Seeing as I'm going to have to go through the same thing shortly... I'd very much appreciate some prior caveats :).


Edit: the game does not need extra "thinking delay". It's taking its merry time as it is right now: on the average 30 seconds to a minute for a move (during the opening, I'm guessing the response speed may increase when the number of possible moves is reduced and the game gets to use its cache).

The thinking delay's interesting, my PC only has a 800MHz processor and the opening moves are more or less instantaneous, but later on gets up to 20 seconds. I don't know how this was built (it's part of the Debian distribution) but the README file in gnugo does give some options for improving the performance. I just used the defaults.

GNU Go is built in the standard way i.e. using configure and make, the only problem was that some of the pattern code files are generated by programs which are themselves compiled, so when cross compiling the executables produced won't run. I got round this by building GNU Go twice, first for x86 Linux to produce the file generators and a second time for arm Linux. You could just compile the bits needed for the generators but it only took a few minutes to run the whole thing anyway.

Anyway, what I did was ...

1) I installed the
GPH_SDK

2) Downloaded GNU Go and extracted it

3) cd to gnugo-3.6 and run configure

4) Run make

5) Copy the following executables from the patterns directory: mkpat, mkeyes and joseki to somewhere safe

6) Run make clean to blow away the object/executables

7) Run configure --host arm-linux

8) Run make and each time it fails because a generator won't run (the first will be mkpat), replace the executable in the patterns directory with the one you saved in step 5 and run make again.

9) gnugo can be found in the interface directory

Hope this helps
 
Last edited by a moderator:
Found this in the Displaying Text thread

woogal posted on Dec 10 2005 at 12:49 AM said:
RiX0R posted on Dec 9 2005 at 11:32 PM said:
I'm having the same problem.

Does the GP2X even have a floating point unit?
No, which is why a lot of stuff is compiled with soft-float so it can use the optimised arm floating point support in gcc. Without soft-float and a recent version of gcc, any app that makes extensive use of floating points will grind to a halt on the gp2x. But the thing is if one lib uses soft-float, everything else used in the app (including the app itself) must also be compiled with soft-float.

GNU Go uses floating points extensively and I haven't used the -msoft-float flag

Coincidence? Maybe...
 
Last edited by a moderator:
To show you all that I'm at least doing something...:

shot-20051212.162116.gif
 
Back
Top