GNU Go for S60

Bye CVS, Hello SVN

2010-05-08T22:14:00.005+01:00

I have switched over the source control for gnugos60 on sourceforge from CVS to Subversion now. Here's the instructions for anyone that cares. This should hopefully make it a bit easier for me to to actually make some changes to the code.

The 0.2 version where any new features are doesn't compile at the moment, so I think I'll just go ahead and release a 0.1.2 that only contains the memory usage / speedup fix and an up to date certificate so it can actually be installed.

Tune in next week. Same bat time. Same bat channel.

Or not, as the case may be.

Certificate Expired Problems

2008-03-01T01:10:00.002Z

Someone reported a problem that when installing getting a "Certificate Expired" message. I thnk this is because it's one year since I did the self signing on the SIS, and self signing lasts only one year.

I'll upload a re-signed version later, but in the meantime anybody who experiences might try just setting the clock back a few months, and see if the install can succeed. You can reset the clock back to the correct date after install.

GNUGoS60 v0.1.1 is released

2007-12-04T13:40:00.000Z

GNUGoS60 v0.1.1 is released for S60 2nd FP2 phones.

GNUGoS60v20-FP2-0.1.1.sis

It fixes only this FP2 specific error, quite possibly only partially:

Out of Memory after 1 or 2 moves on 6680

I have reduced the cache size from 2MB to 400k, and this seems to allow it to do some moves. I was able to make 10 or so on the 6680 RDA before I got fed up waiting for it :)

Please let me know if the out of memory still persists on any FP2 phones, and after approximately how many moves.

Note: For other S60 2nd users with low memory phones, (like 7610 or 6600) this may be worth a try also if you are experiencing this bug, but I haven't tried this release on anything other than 6680, and it was built with the FP2 SDK:

7610 gives an out of memory error after several (2-10) moves

GNUGoS60 v0.1 for S60 2nd FP2 released

2007-12-03T17:24:00.000Z

I just uploaded a v0.1 package for S60 2nd FP2 phones now.

GNUGoS60v20-FP2-0.1.sis

I found that the reason it didn't work on them before was because there is a bug in the firmware for all phones based on that release that means ECompXL doesn't work at all. Staffan Ulfberg (of EEMame) had wrote in a forum about a similar problem, and mentioned he had a workaround, so I emailed him for the solution, and he kindly responded with help.

It now launches on 6680, but honestly I think anybody installing it is going to be disappointed, because you get out of memory so easily. Even after 1 move or something. I have read that 6630, 6680 and 6681 have even lower memory than 2.0 or FP1 devices like 6600 or 7610, which get out of memory too, but after 10-20 moves.

Anyway, the game is basically unplayable on those devices I would say.

Debugging the 6680: Forum Nokia's Remote Device Access

2007-12-01T16:13:00.000Z

There is a longstanding bug in the S60 2nd editon port of GNUGoS60 that affects the 6680. I think it is probably also the same as reported by several people (including Dániel again a couple of days ago) for 6630 since those phones are basically identical in SW terms, the 6680 just having non-hideous mechanical design :)

[ 1651164 ] can't install/run on nokia 6680

The symptom is that it installs, but doesn't run. I have been wondering how I can begin to solve this, since I don't have access to a 6680 or 6630 to try and debug it on. I remember reading a while ago about Forum Nokia's Remote Device Access program before, but at the time it was only for S60 3rd devices. I checked back today though, and the have a couple of 2nd edition devices now, including the 6680:

I was able to logon to the server, connect the phone and install GNUGoS60v20-0.1.sis to the 6680, all through a java interface. It's pretty neat.

And yes, I was able to reproduce the bug easily, since the program does not start at all despite the successful installation. Well, now I have to go and create a test build with some logging enabled to start to track the problem. Unfortunately I also need to recreate a 2^nd edition SDK build environment, since I had a hard disk fail, and my old one is kaput. I've been only working on 3^rd edition for the last few months while adding the new features.

Anyway, I recommend any developer to use the Forum Nokia RDA service. It seems really useful. It would be nice to have more S60 2nd devices though.

Anti-aliasing in Symbian

2007-11-29T14:12:00.000Z

As you can see in this zoomed image, the stones in GNUGoS60 are more like octagons than actual circles. This is is to be somehow expected given the resolution, and not completely bad, all things considered. There is a certain old skool charm about the crappiness of the graphics :)

Still, some people may prefer their stones round, and anti-aliasing is the term in computer graphics for doing our best to hide the visual limitations of CG renderings. Like octagonal circles, sor instance. Symbian do not provide any such functions that I can see. The Symbian Graphics Context, CWindowGc, doesn't seem to provide any way to draw anti-aliased circles (or anti-aliased anything).

All is not lost though, since it's pretty easy to draw a circle all by ourselves, one pixel at a time. As everyone surely heard at least once in school, the equation for a circle at origin is:

x² + y² = r²

or more generically, where cx, cy are the coordinates of the circle's center:

(x - cx)² + (y - cy)² = r²

Knowing this, and that each pixel has an x and y coordinate, we can define 2 concentric circles. The outer one equal to the radius we want the stones to be draw. The inner one some tunable factor smaller than that, typically somewhere in the range 0.0 .. 2.0. Given these 2 circles,we can say that, depending on x,y coordinate values, there are three types of pixel:

Pixels outside the outer circle, which are not forming any part of the stone.
Pixels inside the inner circle, which are 100% part of the stone.
Pixels in between the two, which are some measurable percentage both part of the stone and not part of the stone.

Type 1 pixels get no color when drawing the stone. Type 2 pixels get the stone color, black or white, as appropriate. Type 3 pixels again get black or white as appropriate, but also get a transparency value, where it is set transparent to the extent that it is outside the stone. This will have the effect that it will blur the edge pixels reasonably well against the background and give the impression of the stone being rounder (and blurrier :).

Anyway, after all that geometry, Below is the end result. I'm not sure which is actually better, and it may be a matter of taste (and screen resolution), so I'll keep an option to switch between the two.

176x208 resolution

240x320 resolution

352x416 resolution:

One thing making direct comparison difficult is that the anti-aliased ones don't have the black outline for the white stones. Originally I thought that this wasn't needed, but looking at the images side by side, I think that it's probably better to have it. Unfortunately though such an outline would require another funciton to draw an anti-aliased circle outline, which ought to be straightforward, but I haven't done it yet.

I wonder are there any (L)GPL libraries for 2d graphics in Symbian that support anti-aliasing. Adding an extra library is a bit much for the limited amount of drawing in GNUGoS60 though.

You Lost!

2007-11-04T10:51:00.000Z

Over the last few weeks I've been slowly adding the missing features and fixing some of the bugs in preparation for some sort of 0.2 release, hopefully before the end of the year. Finally now it can tell you whether you won or lost the game. Great functionality there :)

Must. Add. Scoring.

Anyway, it now also indicates when a move is valid. Shows a "ghost" stone along with the cursor. Indicates the last computer move. Lets you set the level (from 1 to 10). Lets you set the board size (from 5 to 19). Shows your move before going off and "thinking". I've also just begun to make it multi-threaded, so the GUI shouldn't lock-up like it does now when it is busy.

GNU Go for UIQ

2007-10-26T14:21:00.000+01:00

Somebody seems to have ported gnugo to UIQ also. You can download it from AnotherGuest's page here. I haven't tried it, since I don't have any UIQ phones, but people might find it useful.

I only found it out because Softonic reviewed it and sent me an email thinking that it is my version. Their review page links back to the gnugos60 site, though I've asked them to change it, since it's confusing. Anyway, UIQ port got 4 stars, despite the "pretty feable [sic]" graphics :)

Internet Go Protocols

2007-04-18T15:35:00.001+01:00

There seem to be 5 main protocols out there for playing go over the internet. They are:

GMP - Go Modem Protocol
GTP - Go Text Protocol
NNGS - No Name Go Server Protocol
IGS - Internet Go Server Protocol
KGS - Kiseido Go Server Protocol

GMP seems to have an open spec. The protocol is supported by some programs, but may be old by now, and my impression is that it may not be so popular anymore.

GTP seems to have replaced GMP as the default protocol that people implement in their Go game. I think it was implemented originally for Gnu Go. The GTP spec is open, as you'd expect.

NNGS is a Go server, and has it's own protocol, but seems maybe this server is not really popular anymore, and not many sites run it. The source code is open, but the spec is not documented outside of the code. Seems there are many private variations of this as a result.

IGS is a popular go server, and their protocol is open-ish. At least there is a IGS protocol spec from them floating on the net, and seems many software implement the protocol. The spec says it's for implementing a client only, so no big problem I guess.

KGS is a popular go server, and their protocol seems closed. However Marc Lehmann has kindly reverse engineered and documented it, so there is an open KGS protocol spec available.

GTP and GMP are already implemented in GNU Go (though as a server rather than client), so it's probably fairly straightforward to implement them in GNUGoS60 as a client, though I am not entirely sure how useful that would actually be.

The other 3 would probably be harder to do, not least because you probably need to have more gui support also. Presumably they would be more useful for the average person though.

Anyway, lots to implement in standalone client before that though...

Inkscape and svg2svgt

2007-02-19T13:35:00.000Z

If you want to make an icon for S60 3.0 you are supposed to make them as SVGT, and to help with that the SDK contains a utility called svg2svgt. This is written in Java, and it's wonderful installer generally fails to install (at least on the 3 PCs I have tried). There is a workaround for this though which works, and is included in the release notes (though who ever reads those). Anyway, generally what happens is that it complains that it is not compatible with the Java 1.3.x that is by default installed on most Windows. It doesn't recognize even if you have later JRE installed. Anyway, the solution is to put JAVA 1.4.x in your PATH.

cmd
c:>set PATH=C:\program files\java\jre1.4.x\bin;%PATH%

then run the installer for svg2svgt from the command line.

c:>\Symbian\9.1\S60_3rd_MR\S60Tools\svg2svgt\installer\svg2svgtconverter.exe

Hey presto, it installs.

So now you look around for a way to make a SVG, and really there is only one good free option, and that is to use Inkscape. You duly design whatever you want and save it in Inkscape, and then run the svg2svgt on it. Hey presto, it looks nothing like the icon you designed in Inkscape.

What has gone wrong? For a reason explained here by Greg_Jokiel the svg2svgt doesn't parse the style attribute used extensively by Inkscape to set the colors and other things. The end result is that your icon looks nothing like you expected. shapes are the wrong color or disappear altogether. Greg_Jokiel gives a solution in that link, though it would be a pain to do by hand even for one icon. Anyway, I created a script svg2s60 to do what he recommends and make the Inkscape files parsable correctly by svg2svgt. No guarantee that it works correctly for all (or even any) files, but it worked correctly for my icon.

Updated 01 Sept 2007: "here" link fixed

Status of GnuGoS60 on real phones

2007-02-05T13:15:00.001Z

Just thought I'd give a brief rundown of the phones that this port of gnugo has been confirmed working on, and those that have reported problems. If you don't see your phone here (or it contradicts what I have listed), and you have tested it please add a comment giving the status.

I know there are still bugs in the software, so please ignore them :)

This is just a "somehow works"/"doesn't work at all" type of check for GnuGoS60-0.1

Reported OK

6600
6670
6120
N73
N80
N90
N91
N93
N93i
E50
E61
E61i
E65
E70
6630 - broken in v0.1, but sort of works from v0.1.1 onwards
6680 - broken in v0.1, but sort of works from v0.1.1 onwards

Reported Not OK

~~6630~~ - broken in v0.1, but sort of works from v0.1.1 onwards
~~6680~~ - broken in v0.1, but sort of works from v0.1.1 onwards
E70 (2.0618.07.10) - real issue or not?

(Updated 06/02/2007 21:36 - N80 somehow works)
(Updated 13/02/2007 21:26 - E50 somehow works too)
(Updated 14/02/2007 22:32 - N91 somehow works too)
(Updated 16/02/2007 21:41 - E61 somehow works too)
(Updated 05/05/2007 18:15 - N73 somehow works too)
(Updated 22/05/2007 20:56 - E70 somehow doesn't work) - (03/07/2007 still valid?)
(Updated 22/05/2007 20:58 - E65 somehow works too)
(Updated 03/07/2007 22:47 - E70 somehow works too)
(Updated 03/07/2007 22:47 - E61i somehow works too)
(Updated 22/09/2007 22:47 - 6120 somehow works too)
(Updated 08/12/2007 22:37 - 6680, 6630 problem fixed in v0.1.1)

GNUGoS60-0.1 Released (woohoo!)

2007-02-01T13:35:00.001Z

I am pleased to announce that version 0.1 of GNU Go for S60 has been released. You can download it here.

It supports S60 3rd edition and S60 2nd editions. The support for 3rd edition is a bit better than 2nd edition which still has a kind of hack in to make it run at all, but that slows it down pretty severely. Nevertheless it plays a game of Go. Not much else, but it's a reasonable start.

Version 0.2 will seek to implement some of the more important features that are missing from the interface, though might be a while coming, so enjoy version 0.1 for now :)

Symbian Signed and .SIS file installation

2007-01-15T13:19:00.001Z

Maaaah. What a nightmare

:(

GNU Go in Fullscreen on N90

2006-12-28T15:45:00.000Z

After much analysis of flogger trace files I finally found the reason for the application crashing on target device. A stack overflow was the cause (no big surprise there). Debugging took the best part of 2 days though because I had thought that I had already resolved all those stack overflows, but actually I had only ticked a mental box "I must fix all those stack problems". So much for memory :). I created a new bug on the GnuGoS60 project page now so that I don't forget to do a code inspection sometime and eliminate the more obvious of the remaining potential problems.

You can also see that this screen shot looks a bit different to previous ones. I have implemented one new feature (finally). This is the ability to have the board in full screen without the wasteful S60 title bar taking up screen real estate. It looks nice enough on the N90, though I'll need to try on some of the newer QVGA screens also since it will look slightly different.

Well, gnugo is now finally working well on a real device. This is big progress for me. The rest of the work is more or less just feature work. Filling in the blanks to bring the S60 port up to the same level as the ascii interface. I'll make a 0.1 release before it's feature complete though. Probably as soon as I implement some way to know who won the game and when I resurrect the 3rd edition version to see far it has rotted while I was focusing on getting the 2nd edition version working.

GnuGo for S60 running on Nokia N90

2006-12-26T08:37:00.000Z

Merry Christmas!

As you can see here GnuGoS60 is now running on a real phone. I had been having trouble getting anywhere at all. I was able to make a SIS, but the application didn't run at all.

Eventually I figured out that even a HelloWorld application didn't run with ECompXL enabled. I am not entirely sure why this and spent some time doign binary diffs and checking various things to no avail. Everything seemed ok. I had been using the binary distribution of it on the ECompXL website, but just since I had run out of ideas I decided to compile from source the .app and .exe of ECompXL. Suddenly HelloWorld worked, and soon after so did GNU Go.

I am not entirely sure why I should need to have done that, but anyway it launches now, so no complaints.

What it doesn't do is run properly though. It always crashes immediately after playing my second move. This doesn't happen at all on the emulator unfortunately. I have gotten rid of all those bugs, and on the emulator everything runs smoothly, so it's a bit of a pain to have to go and do all that again on the device, but such is life. Time to investigate flogger...

Still looking good for a 0.1 release for 2nd edition devices in the new year, and third edition shortly after that. Here's hoping!

GnuGo for S60 Supports Different Board Sizes

2006-11-26T13:54:00.000Z

As you can see above and below, I have added rudimentary support for different board sizes now to GNUGoS60. This makes it much easier to do quick testing of new features because I don't need to wait for ever to have the game complete. There seem to be a few things that I need to re-initialize because I noticed that the emulator becomes unstable after a while when changing board sizes a lot. Anyway, something for a later date. For now, the changes have been checked into CVS, so you can see the development "live" so to speak.

One thing I noticed was that there is no way to end the game. So I added the "pass" menu also. Don't have time to add the functionality yet though even though it's probably just a few minutes work once I get around to investigating it. I think I'll have a think about how I want the UI to work before adding a lot of the rest of the GnuGo interface features.

GnuGo for S60 code now in Sourceforge.net

2006-11-25T14:36:00.000Z

I have updated the code that I have in the working status from the previous post to the GnuGoS60 project page on sourceforge.net now. CVS wasn't so difficult to use after all, though I already encountered some of the limitations that made me dislike when I used it previously. Anyway, it'll have to do.

In the unlikely event that someone actually wants to download the code, please be aware that you will need to install ECompXL to get anywhere with the 2nd edition SDKs. Also I haven't bothered compiling with the third edition for a long time, so it might not work at all.

GnuGo for S60 Achieves Stability

2006-11-25T13:34:00.000Z

As You can see from the above image, gnugo is is now operating pretty solidly on the S60 emulator. That's a genuine game (that i am in the process of losing :). In case you are wondering why I made the stupid moves into the corner it's because I was doing edge testing! Honestly! For some reason that I don't remember now, the GUI that I made is indexing 1 to 19, but gnugo is indexing 0 to 18. This was causing it to abort any time I played a move on the edge. It seems ok now, though I'll have to check if there is some tidy up that I can do there.

The stability is all down two things. Firstly ECompXL allowing me to leave all the global data as it was, and secondly due to the long hours I spent getting rid of all the overlarge automatic variables. They were causing a lot of stack overflows which are impossible to debug. I made a macro to malloc the memory instead of allocating on the stack. I also wrapped the affected files in C++, so that I could use automatic pointer type of class to take care of the freeing. I was having huge memory leaks before that because gnugo has lots of cpp macros that include a return statement.

I also tried to make a SIS package today. I got it to create and to install on my N90, but of course it didn't run at all or give any useful message why. No doubt I am putting some file in the wrong place or something. Symbian installation is not the nicest system in the world.

I also got some official UIDs allocated now, so I am using one of those for the application rather than one plucked out of thin air.

I also need to stop procrastinating and brush up on how to use CVS, so I can make the source code available. Need to do that before I start distributing any SIS packages anyway.

Next up to implement is the ability to play a smaller game than 19x19, so that I can test end of game conditions without waiting for hours. This should be just adding a menu basically. The board gui control and gnugo engine already support it.

ECompXL again

2006-11-18T16:25:00.001Z

Finally got some time to read about ECompXL properly. Turns out that it doesn't support libraries, so I needed to put all the code into one big .app file. This is no big deal really. I would have expected the .dlls to be loaded all the time the game is running anyway. The split was just for convenience.

Anyway, the real global data support now meant that I could roll back all my changes to move them all to Tls. It was painful to move them there in the first place, but I am glad to be rid. I used "beyond compare" to merge back with the original version of gnugo. I have a lot less changes now, so less chance of going wrong. Overall the switch to ECompXL is well worth the effort for me.

I could actually merge out more changes than I actually did. I left in the dllexports that I put in when I had the code split into libraries, but those are not necessary anymore. That's next on the todo list.

For the moment I am getting the below message on the console after playing the second move. That is a standard gnugo error message, so at least I seem to be past the hard crashing phase, though I am quite sure that the trigger for the gnugo error is either something I have done or something that I need to do because it's on Symbian.

Still it's not a kernel panic or other exception, rather an application level error. Some sort of progress maintained even after two lots of wholesale changes.

Next plan is to start putting some of this code in sourceforge CVS...

Unresolved external symbol __chkstk

2006-11-18T16:04:00.000Z

I have found that in some places I get random crashes of the application. After some investigation this seems to be caused by stack overflow. Generally I get it when gnugo is doing memset or something similar on a large array. Actually this is hard to debug in the emulator to begin with because it just kills the debugger without showing anything useful other than a "first chance exception" dialog box. The way around that is to replace the system memset with my own version that just is a for loop filling in the memory instead of whatever assember magic the system version does. This causes the debugger to terminate nicely showing the line of code where it overflows.

So why am I getting these. Well for starters because I ignored all the "Unresolved external symbol __chkstk" messages and went ahead and defined __chkstk just to get the thing running in the emulator. So much for shortcuts :)

After removing that definition, gnugo leaves 7 or 8 files which have obviously too large stacks. Unfortunately those files are each 100-200kB in size, so I spent a lot of time going through the files allocating all the arrays and large structures on the heap instead of the stack. It took a long time, but had to be done.

ECompXL: Epoc Compressed Executable Loader

2006-09-22T17:41:00.000+01:00

I found this interesting project ECompXL, yesterday. It's basically a replacement loader for your Symbian application. What's interesting from my point of view is that it also adds support for global data. From the text:

Support for global data and global C++ objects in applications

Symbian OS executables (.exes) already have full support for global modifiable data and global C++ objects, and ECompXL allows you to have them in your applications (.apps) as well. If you have built your application as described in the previous section, support for global modifiable data in your application comes for free.

This is cool if it works as advertised. I'll have to give it a try out.

Application Icons in S60 v2.0

2006-09-20T15:23:00.000+01:00

I created icons for the S60 v2.0 version now also. These are just bitmaps and masks for them. I ended up using GIMP to downscale the icons from the one on the gnugo website. MS Paint and MS Photo Editor seen to just do nearest neighbour or something similar algorithm when downscaling images. This results are pretty poor quality. GIMP at least supports some sort of interpolation which gives a reasonable quality (as much as can be expected in 44x44 bitmap).

Making a mask was a pain though. There didn't seem to be any automatic way to do it, so I ended up doing by hand using the icon as the starting point. I am presuming that there is some automated way to do it somewhere out there. Otherwise it would be a huge waste of people's time. The SVG system in S60 v3.0 is far superior.

Anyway, now it's done, at least I don't have to do again!

GnuGoS60 Sourceforge.net Project Page

2006-09-19T16:12:00.000+01:00

I have created a sourceforge.net project for hosting the gnugos60 code.

Alternatively here are the plain URLs:

I haven't uploaded anything except screenshots yet though. I need to install CVS or SVN on my PC. (I use Perforce up to now). Then I need to figure out how to use them...

GNU Go for S60 v2.0

2006-09-17T16:51:00.000+01:00

Finally got the S60 second edition to stop crashing enough to draw the board. Maaaan that was hard work! Basically I have been working on it for the whole weekend trying to get it to compile once all the global variables I could spot have been stripped out and moved to a dynamic structure stored in Tls().

Really, whoever decided that not supporting global variables was a good idea needs a right good sla^H^H^H *ahem* ... talking to. It is positively the worst OS misfeature I have ever come across. Using Tls() is not even a good solution because there is no migration path to speak of. Basically you have to:

go through the code and look for a writable variable (the compiler only accurately warns about some tiny minority of them, so keep your eyes peeled)
move the declaration to one place
mov the initialization to a different place that doesn't support the previous type of initialization
make the runtime inialization work
define a macro for the old variable name
add the macro to however many dozen files need it
workaround any issues in the code that conflict with the macro

Congratulations! You have now migrated one writable static variable to SymbianOS. Now repeat a few hundred times. And if you missed any of them be prepared for this message and some long hours with the debugger:

It's Alive! (briefly :)

2006-09-15T07:28:00.000+01:00

Exciting stuff. Got enough of the GNU Go back end linked with the GUI so that I can display the actual GNU Go board rather than an dummy one, and rather than just me toggling black and white stones on, the GNU Go AI responds to my moves, and makes it's own moves. (And then crashes :)

Anyway, the important point is that all the white stones on the board shown were not put there by me. They were put there by GNU Go. It's a big step forward.

Well, things are looking up. Can't be too far from playing a full game vs gnugo on the S60 emulator, once I get all the crashing sorted out.