This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re:Xconq for Windows


> > 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.

That's interesting. The first Win32 binaries that I built with CodeWarrior
always crashed while allocating memory for pixmaps, no matter what game I
tested. It was only after I defined _MSL_PRO4_MALLOC in ansi_prefix.Win32.h
and rebuilt the Metrowerks Standard Libraries that I could make an Xconq
that did not crash. _MSL_PRO4_MALLOC enables an older malloc version that
is slower but more robust. Perhaps the malloc of Visual C++ is having the
same problem as the default MSL malloc?

Anyway, I can run every base module except ww2-bn.g with my Win32 binaries.
And this is under Win98 with as little as 128M, but with no other apps
running. So you are probably right in your suspicion that people who have
memory problems have a other apps open which consume GDI memory.

>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.

Xconq can already run with missing images. But of course this does not help
if it crashes when the pixmap creation fails. Any specific ideas for how to
improve this code?

> > 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:

Thanks a lot for this!

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

and also kernel32 and wsock32 (at least with CodeWarrior).

>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:

I will check it in.

> - 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).

tkimf.h has:

#if ( defined (WIN32) && !defined (__CYGWIN32__) )
extern int gettimeofday(struct timeval *tv, void *tz);
#endif

and gettimeofday is not declared static in util.c. So CodeWarrior can
certainly see it in the tk files, and so should Visual C++ (but not Cygwin).

>   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:

I'll look into this.

>With these fixes xconq should compile, link, and run.
>
>Known problems:
>
> - menu highlighting doesn't work right since the latest color changes

Right. That's because I turned it off. I thought the active background
feature was a little flashy on unix. But we could of course add it back
again, by setting abcolor to something else than LemonChiffon.

> - 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).

They are used by the unix code, but not on Mac or Windows.

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

Yes, the colonizers. I will fix it. I just fixed another Windows-specific
crash in monster.g that involved a null pointer. Funny how Windows is even
more finicky than unix is about things like this.

Thanks again for your help,

Hans



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]