Re:Xconq for Windows

[Juergen Ruehle <j dot ruehle at bmiag dot de>]

Hans Ronne writes:
 > I don't know if you follow the xconq7 list any longer, but there were
 > several requests for Windows binaries, so I finally put some binaries that
 > I built with CodeWarrior (the TCL version) on my homepage:
 > 
 > http://w1.694.telia.com/~u69400018/

I'm still alive, lurking on the list and ashamed, that I didn't put as
much effort into it as you. But I pulled my act together for the last
weekend and actually have some answers to your questions.

 > Now I have two questions to you. First, the Win32 binaries that I built
 > have a memory problem with some (but not all) game modules. I have been
 > trying to figure out what triggers it but without success. This problem was
 > just discussed on the list. Did you see the same thing with the binaries
 > that you built?

Yes, the binaries built with cygwin resp. Visual C++ 6 (introductory
edition) have the same problem. And it's not main memory it's
complaining about, but GDI resource memory (that's still limited -
because of better compatability for applications using the obsolete
segmented addressing modes - in Win9X and ME but unlimited in NT,
2000, and up). The standard game uses about 80% of the maximum, while
flattop only uses 20%. So if you have other applications running the
probability of xconq crashing on the standard game is fairly high.

Since these resources are limited we have no choice, but to limit the
usage somehow. First xconq should be made more robust and handle
pixmap creation failure somewhat more gracefully and possibly run even
with missing images. Then we have to document this in the README-win
and ask the users to stop all other running applications.

 > My second question is about Visual C++. Several people have asked how to
 > build xconq using it for obvious reasons. Since I'm using CodeWarrior
 > myself, I'm not sure. Did you ever build xconq using Visual C++? If you
 > did, could you perhaps post some build instructions to the xconq list? I
 > think many people would appreciate that.

I promised to produce an INSTALL-win which details that some months
ago. It's nearly finished:-)
Basically it is as follows:

 - Get Tcl/Tk (e.g. from ActiveState) and extract it to somewhere

 - Create a new project containing the .[ch] files (except the
   unix/mac specific ones and the helper applications) of kernel and
   tcltk and add win/Xconc.RC. Don't use win/wconq.c its obsoleted by
   tcltk/tkwin32.c and should be removed from CVS.

 - Change settings appropriately: include the top level, the kernel
   directory and the Tcl/Tk include directory; libraries are the
   Tcl/Tk libraries and user32

 - Fix the remaining problems (see below)

 - Run it with appropriately configured TCL_LIBRARY, TCLLIBPATH, and
   game module directory.

There are two compilation problems with VC6 Introductory Edition that
I know of:

 - no long long support (used in the random number generator). Since
   it's important for the network game that the generated numbers are
   identical on all platforms there probably should be now #ifdef in
   the code. I used the following patch:

--- kernel/util.c	31 Jul 2002 20:40:08 -0000	1.21
+++ kernel/util.c	20 Oct 2002 10:26:12 -0000
@@ -147,17 +147,18 @@
      //int m;
 {
     int rslt;
-    long long bignum;
 
     randstate = (8121 * randstate + 28411) % 134456;
-    /* Random numbers in too large of a range will overflow 32-bit
-       arithmetic, but Xconq rarely needs the large ranges, so only do
-       the 64-bit arithmetic if necessary. */
-    if (m <= 10000) {
+    /* Ranges larger than 15971 ((2^31-1) / 134455) may overflow signed 32-bit
+       arithmetic, but Xconq rarely needs the large ranges, so only do the
+       extended arithmetic if necessary. */
+    if (m <= 15000) {
 	rslt = (m * randstate) / 134456;
     } else {
-	bignum = m * ((long long) randstate);
-	rslt = bignum / 134456;
+      /* Extend range by 13 bits. Note that this clips the range to 67108863
+       * (2^26 - 1) */
+      long hi = (((m >> 13) & 0x1fff) * randstate);
+      rslt = ((hi / 134456) << 13) + ((((m & 0x1fff) * randstate) + ((hi % 134456) << 13)) / 134456);
     }
     return rslt;
 }

   Note that in a couple of AI vs. AI games the extended case was
   never hit, so we can probably just document that range must not
   exceed 15971.

 - No gettimeofday(). There is already a clock() based workaround in
   util.c that has to be copied to the tcltk code (I always wondered
   why CodeWarrior doesn't need this, because util.c shouldn't be
   visible there). Actually I think this problem should be solved on
   the general level, that is remove gettimeofday() from the platform
   independent code and replace it by something like this:

--- kernel/system.h	31 Jul 2002 20:40:08 -0000	1.10
+++ kernel/system.h	20 Oct 2002 10:26:09 -0000
@@ -32,6 +32,12 @@
 extern int n_ms_elapsed(int n);
 extern void record_ms(void);
 
+/*
+ * Query some system specific time source. The unit is milliseconds. Actual
+ * resolution should be better than 25 ms.
+ */
+extern unsigned int system_ticks_ms(void);
+
 extern int open_remote_connection(char *methodname, int willhost);
 extern void low_send(int rid, char *buf);
 extern int low_receive(int *rid, char *buf, int maxchars, int timeout);

   This has to be implemented in mac.c, unix.c, and win.c and used
   instead of gettimeofday() to measure time intervals (which is the
   only use for gettimeofday() in xconq).

With these fixes xconq should compile, link, and run.

Known problems:

 - resource usage on Win9x (no sulution known)

 - menu highlighting doesn't work right since the latest color changes

 - dummy implementations of XSetTile(), XFlush(), and XSynchronize().
   These should probably removed from the code altogether, #ifdefed
   (if they are actually required for X), or implemented for windows
   (if they are actually needed everywhere, but it doesn't seem so).

 - (not win specific) lord-rings.g doesn't work due to a division by
   zero in explorer_worth (because cp is 0 for something)

So basically iit runs fine.

I hope that helps someone...

  jr