Re: How to fix the xconq network code

[Hans Ronne <hronne at pp dot sbbs dot se>]

>What if we use a display protocol that is more portable and efficient than
>X11?
>
>I have had very good experience with a free (GPL) remote display system
>called Virtual Network Computing (http://www.uk.research.att.com/vnc/).
>The display protocol is well documented and efficient.  Clients
>("viewers") are available for practically every architecture; you can even
>connect using a Java-capable web browser.  All VNC information is kept on
>the server, so if you lose your network connection you just reconnect with
>a new viewer and continue where you left off.

VNC is an interesting option. It is of course already possible to run
xtconq on non-unix platforms, since free X Servers are available for both
Windows and MacOS. I have tested running xconq remotely under MicroImages'
MI/X Server on my G3 Mac. This was actually MI/X running on top of MacOS
Classic on top of Mac-on-Linux on top of LinuxPPC (where the xconq app was
running), using the ethertap device for communication between the MacOS and
Linux interfaces. It may sound complicated, but everything worked fine.

I'm less enthusiastic about tcl. There were some good reasons why Stan
abandoned tcltk and instead went for SDL. First, the tcltk interface is
rather slow and also has other limitations. Second, it is more difficult to
debug tcl code. Third, it is not easy to port to other platforms, even if
tcltk is available. I tried (hard) to get the tcltk version of xconq to run
under MacOS, but failed. This is in contrast to sdlconq, which I had up and
running under MacOS after no time at all.

The really good news, however, is that we may not have to rewrite the code.
After some ferocious debugging, I believe I have fixed all the problems
with the existing network code. I now have the network game running for any
number of turns without synch errors or lockups. This is with AIs on both
sides and in non-sequential mode, i.e. the toughest possible conditions.
There is still some testing and code cleanup to do, but if no serious new
problems emerge I will check in the code soon, perhaps already next weekend.

Hans





Hans Ronne

hronne@pp.sbbs.se