GnuGo for S60 Supports Different Board Sizes

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

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

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

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

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.