7.5 release?

7.5 release?

[Charles Goodwin]

It's been 'imminent' for quite some time.  What's left to do before it 
is released?

- Charlie

Re: 7.5 release?

[Eric McDonald]

On Tue, 23 Sep 2003, Charles Goodwin wrote:

> It's been 'imminent' for quite some time.  What's left to do before it 
> is released?

I'm sure Hans has his own list. But a few of things I would like 
to take care of before the release are:
(1) Finish build system overhaul.
(2) Go over the documentation with a fine tooth comb. Possibly 
rewrite some sections.

And time permitting:
(3) Finish getting rid of the X11 BadDrawable errors for the 
dialog windows in the Tcl/Tk interface.
(4) Make sure that all unit types that a side can own (whether 
through production, capture, or type changing) show up in 
the unit type list in the Tcl/Tk (and possibly other) interfaces.
I know type changing is not even fully supported yet, but might as 
well take care of this detail while we're thinking about it.
(5) Make sure that "xconq -x" writes initialization messages to 
its invoking tty just like "xconq -g somegame" does. 

Eric

P.S. I guess I'll have to make sure the Web site says 
"approaching" (which I thought it did) rather than "imminent".

Re: 7.5 release?

[Charles Goodwin]

Eric McDonald wrote:
> P.S. I guess I'll have to make sure the Web site says 
> "approaching" (which I thought it did) rather than "imminent".

I took the 'imminent' from a mail to the list from Hans back in January 
that said 'approaching' and 'in a few months'.

- Charlie

Re: 7.5 release?

[Eric McDonald]

On Tue, 23 Sep 2003, Charles Goodwin wrote:

> I took the 'imminent' from a mail to the list from Hans back in January 
> that said 'approaching' and 'in a few months'.

I see.

I guess the only thing I have to say about this is that slipped 
release dates are fairly common in commercial software 
development. And, of course, Xconq is a 100% volunteer effort by 
people who generally have full-time jobs. So, the fact that the 
date has slipped is not surprising to me. (Hans once told me that 
he was targeting the end of summer, but that passed a couple of 
days ago, and I'm not bothered in the least.)

  Regards,
    Eric

Re: 7.5 release? - How you can help

[Hans Ronne]

>P.S. I guess I'll have to make sure the Web site says
>"approaching" (which I thought it did) rather than "imminent".

Or rather, I should abstain from optimistic forecasts on this list :-).

Other things to do before a release:

1. Fix the recently discussed font problems in the tcltk interface (almost
done).

2. Add several new game modules and update all the existing ones (ditto).

3. Fix the memory problems on Windows. This is the big  one. Several game
modules crash under Windows 98, probably due to the limit on the GDI
resource memory. In fact, after I updated the game modules, adding some
more images to imf.dir, every single game crashes under Windows 98 (this is
one reason why I haven't checked in these updates yet).

I don't think it is acceptable for a release version of Xconq to crash with
100% certainty on what is still one of the biggest installed platforms
worldwide, even if it works fine everywhere else. However, I'm not sure
what to do about it. I guess we could rewrite the imaging code so that it
uses less memory, possibly fix some leaks, but this is quite some work. And
it would probably only fix things until the next game module update adds
even more images.

I would therefore be very interested to hear if there are any known
shortcuts or hacks to deal with the GDI resource problem. It is after all a
well-known limitation in Windows 98 that many programmers must have
stumbled on before.

Any suggestions are welcome.

Hans

RE: 7.5 release? - How you can help

[Erik Jessen]

Well, just to ask, how many people on this list know anybody still
running 98?
Everybody I know runs ME, XP, 2000, Mac or Linux.
I don't know any 98 users.

That should help determine the priority.

As a general question ,what OSes aren't supported?  (DOS6.22, Win3.0,
etc.).
Maybe it's time to put Win95 and maybe Win98 on that list.

What about putting counters on the downloads for the various OSes, so
you can tell what OSes are going out of favor?  This is only of
long-term use, of course, and won't help with source-code downloads.

Regards, and keep up the good work!
Erik

-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Hans Ronne
Sent: Tuesday, September 23, 2003 9:29 AM
To: Eric McDonald
Cc: xconq7@sources.redhat.com
Subject: Re: 7.5 release? - How you can help

>P.S. I guess I'll have to make sure the Web site says
>"approaching" (which I thought it did) rather than "imminent".

Or rather, I should abstain from optimistic forecasts on this list :-).

Other things to do before a release:

1. Fix the recently discussed font problems in the tcltk interface
(almost
done).

2. Add several new game modules and update all the existing ones
(ditto).

3. Fix the memory problems on Windows. This is the big  one. Several
game
modules crash under Windows 98, probably due to the limit on the GDI
resource memory. In fact, after I updated the game modules, adding some
more images to imf.dir, every single game crashes under Windows 98 (this
is
one reason why I haven't checked in these updates yet).

I don't think it is acceptable for a release version of Xconq to crash
with
100% certainty on what is still one of the biggest installed platforms
worldwide, even if it works fine everywhere else. However, I'm not sure
what to do about it. I guess we could rewrite the imaging code so that
it
uses less memory, possibly fix some leaks, but this is quite some work.
And
it would probably only fix things until the next game module update adds
even more images.

I would therefore be very interested to hear if there are any known
shortcuts or hacks to deal with the GDI resource problem. It is after
all a
well-known limitation in Windows 98 that many programmers must have
stumbled on before.

Any suggestions are welcome.

Hans

RE: 7.5 release? - How you can help

[Eric McDonald]

Hi Erik,

On Wed, 24 Sep 2003, Erik Jessen wrote:

> Well, just to ask, how many people on this list know anybody still
> running 98?

I know some who still do. I think that is primarily used on 
laptops nowadays. 98 (including 98SE) enjoyed a somewhat extended 
lifetime because Me wasn't exactly Microsoft's best release (to 
put it nicely). And a lot of organizations I have dealt with run 
on a 4 to 5 year upgrade cycle, which means 98 is still out 
there, and, yes, people do install games on their organizations' 
computers.

> What about putting counters on the downloads for the various OSes, so
> you can tell what OSes are going out of favor?  This is only of
> long-term use, of course, and won't help with source-code downloads.

Well, actually browsers usually do provide not only their name, 
but also the OS they are running on. If one assumes that the 
browser OS is the same one which Xconq is going to be compiled on, 
then one can get a fairly decent picture about what platforms are 
being used for Xconq.

But since Xconq seems to be a fairly low volume download, one 
would need to have an extended sampling period to create accurate 
statistics. And the sampling period would likely have to be longer 
than the time it would take to fix issues on the platform(s) in 
question.

  Regards,
    Eric

RE: 7.5 release? - How you can help

[Erik Jessen]

I'm used to look at this from a marketing point of view:

1) how many customers will we lose if we drop support for X
	(in this case, Win95, Win98, WinME, since it is my understanding
	that all of them suffer from the memory problem).
2) how many new customers will we get if we put the same effort
	to support X, into adding new/cool features for all the other
	OSes?

My thought is that in a year or two, given HW replacement cycle times,
that few will be running the old windows OSes, and that the same work
into upgrading Xconq would get more people interested.

The key to getting more new users, is make it easy to build a simple
game.
By the time they climb that learning curve, they're going to start
learning how to write more complicated stuff.  If the intitial curve is
too high, they'll just walk away.

I have a couple of friends who want to do a railroading game, and Xconq
wuild be ideal, but the map-drawing GUI is less than clear on how to use
it.  I figured it out, but they will just give up after a while.

Regards,
Erik

-----Original Message-----
From: Eric McDonald [mailto:mcdonald@phy.cmich.edu] 
Sent: Thursday, September 25, 2003 8:07 AM
To: Erik Jessen
Cc: 'Hans Ronne'; xconq7@sources.redhat.com
Subject: RE: 7.5 release? - How you can help

Hi Erik,

On Wed, 24 Sep 2003, Erik Jessen wrote:

> Well, just to ask, how many people on this list know anybody still
> running 98?

I know some who still do. I think that is primarily used on 
laptops nowadays. 98 (including 98SE) enjoyed a somewhat extended 
lifetime because Me wasn't exactly Microsoft's best release (to 
put it nicely). And a lot of organizations I have dealt with run 
on a 4 to 5 year upgrade cycle, which means 98 is still out 
there, and, yes, people do install games on their organizations' 
computers.

> What about putting counters on the downloads for the various OSes, so
> you can tell what OSes are going out of favor?  This is only of
> long-term use, of course, and won't help with source-code downloads.

Well, actually browsers usually do provide not only their name, 
but also the OS they are running on. If one assumes that the 
browser OS is the same one which Xconq is going to be compiled on, 
then one can get a fairly decent picture about what platforms are 
being used for Xconq.

But since Xconq seems to be a fairly low volume download, one 
would need to have an extended sampling period to create accurate 
statistics. And the sampling period would likely have to be longer 
than the time it would take to fix issues on the platform(s) in 
question.

  Regards,
    Eric

RE: 7.5 release? - How you can help

[Hans Ronne]

>Well, just to ask, how many people on this list know anybody still
>running 98?
>Everybody I know runs ME, XP, 2000, Mac or Linux.
>I don't know any 98 users.
>
>That should help determine the priority.

Maybe. Unfortunately, ME also suffers from this problem. it is only the NT
variants (2000 and beyond) that have unlimited GDI resource memory.

Hans

Re: 7.5 release? - How you can help

[Juergen Ruehle]

Hans Ronne writes:
 > 3. Fix the memory problems on Windows. This is the big  one. Several game
 > modules crash under Windows 98, probably due to the limit on the GDI
 > resource memory. In fact, after I updated the game modules, adding some
 > more images to imf.dir, every single game crashes under Windows 98 (this is
 > one reason why I haven't checked in these updates yet).
 > 
 > I don't think it is acceptable for a release version of Xconq to crash with
 > 100% certainty on what is still one of the biggest installed platforms
 > worldwide, even if it works fine everywhere else. However, I'm not sure
 > what to do about it. I guess we could rewrite the imaging code so that it
 > uses less memory, possibly fix some leaks, but this is quite some work. And
 > it would probably only fix things until the next game module update adds
 > even more images.
 > 
 > I would therefore be very interested to hear if there are any known
 > shortcuts or hacks to deal with the GDI resource problem. It is after all a
 > well-known limitation in Windows 98 that many programmers must have
 > stumbled on before.

AFAICT (from some debugging sessions on the Win95 installation I use
to play games) the situation is as follows:

 - Tk (and/or xconq win32 glue code?) grabs GDI resources on image
   creation (and the GDI heap is restricted to 64k or something in
   Win9x because of Win3.1 compatability; this restriction does not
   exist in NT)

 - when the resources are exhausted image creation fails (i.e produces
   a warning and returns null)

 - when this null image is used somewhere xconq crashes

Unfortunately I'm not familiar with neither Tk images on windows,
xconq image handling, nor the xconq image drawing code. But it seems
like fixing the resource requirements altogether would require changes
to Tk. That leaves fixing the crashes on null images as a first step
which will probably result in a seriously degraded display on Win9x,
but is a good idea anyway, because one can probably create the same
crash by some other means. In a further phase it could be evaluated
whether it is actually neccessary to have all the images instantiated
all the time and what kind of performance impact there is to
instantiating the images on demand.

But I'm completely out of my depth here, so this might be complete
****.

jr

Re: 7.5 release? - How you can help

[Hans Ronne]

>AFAICT (from some debugging sessions on the Win95 installation I use
>to play games) the situation is as follows:
>
> - Tk (and/or xconq win32 glue code?) grabs GDI resources on image
>   creation (and the GDI heap is restricted to 64k or something in
>   Win9x because of Win3.1 compatability; this restriction does not
>   exist in NT)
>
> - when the resources are exhausted image creation fails (i.e produces
>   a warning and returns null)
>
> - when this null image is used somewhere xconq crashes
>
>Unfortunately I'm not familiar with neither Tk images on windows,
>xconq image handling, nor the xconq image drawing code. But it seems
>like fixing the resource requirements altogether would require changes
>to Tk. That leaves fixing the crashes on null images as a first step
>which will probably result in a seriously degraded display on Win9x,
>but is a good idea anyway, because one can probably create the same
>crash by some other means. In a further phase it could be evaluated
>whether it is actually neccessary to have all the images instantiated
>all the time and what kind of performance impact there is to
>instantiating the images on demand.

Thanks for the feedback! We should definitely fix the null image crashes. I
thought a generic image (black box) was used if image creation failed, but
this may be specific to the Mac PPC interface. I will look into this.

As for hacking Tk, I already did that to enable various graphics features
in the Mac Tk interface, but I would rather avoid doing it again. Lots of
work.

What I have done instead is to get the Windows version through GetVersionEx
at launch time, and set a flag that disables various graphics features if
you are running 98/ME. By disabling terrain transitions and unseen fuzz,
enough GDI memory is left to run most modules under 98 or ME.

I agree that in the long run we should check what images are really needed
and when. One obvious fix would be to instantiate only those terrain images
that are used in the current resolution. That would save a lot of memory.

Hans

P.S. It was interesting to hear that xconq also runs under Win95. I have
not been able to test that myself.

7.5 release?

[Richard Hunt]

Is the xconq 7.5 release going to be soon? I am running from the current xconq cvs release, and I have been playing the standard game without crashes. The recent improvements to the tk interface make the game look nicer, and overall a 7.5 release now would probably improve most people's impression of the app. Are you planning to do a release soon?

Also, is anyone working on the standing orders code? This seems to be entirely undocumented, and I only found out it existed by reading the mailing list archives... Just the ability to have the computer automatically move pieces to a certain hex is helpful, but I can't find it in the documentation.

Thankyou for the recent improvements. (has development really picked up recently, or am I imagining it?). I am unable to do any practical programming myself. In theory I can program in C, but I don't know any tcl/tk at all, and I don't have time at the moment to learn the xconq sources, so I am grateful to the people who can.
Richard Hunt

Re: 7.5 release?

[Hans Ronne]

>Is the xconq 7.5 release going to be soon? I am running from the current
>xconq cvs release, and I have been playing the standard game without
>crashes. The recent improvements to the tk interface make the game look
>nicer, and overall a 7.5 release now would probably improve most people's
>impression of the app. Are you planning to do a release soon?

If I can spare the time. However, I will be very busy with other things in
the next few months :-/.

When I started to work on xconq again one year ago I had two objectives: to
fix the network game and the Windows app. This is because I thought these
two things are essential if xconq is going to survive. See the thread on
this list entitled "THE problem with xconq (long)" from January last year
for a discussion. I also said I thought these two problems could be fixed
within a year.

In fact, this estimate was overly pessimistic. The network code was free of
synch errors by the end of the spring (thanks to Jim Kingdon for help in
debugging it) and we also had a Windows app that could run the network game
by then (thanks to Juergen Ruehle for critical help with this). So in
effect, 7.5 could have been released six months ago. All that needed to be
done was to update the docs and game files (no small task) and then of
course prepare and release the various packages.

However, all sorts of other things popped up. This list, which had been
dormant for almost a year, came alive with frequent bug reports and
questions about game design from Lincoln Peters, Erik Jessen and others. Ed
Oskiewicz made the sources C++ compatible. MA Dunzi contributed several bug
fixes and improvements to the tcltk interface. Stanley Sutton added Doxygen
support and fixes to the Windows builds. I made the tcltk interface run on
the Mac, after which I carried on with a major overhaul of the tcltk
interface itself. I have also been tinkering with the Mac interface a lot
and done some work on a new game module. And recently, Stan came back to
xconq and carbonized the Mac interface.

All this stuff kept me quite busy. Maybe I should have focused on getting
7.5 out of the door instead of answering emails, fixing bugs, and checking
in new code. But since I am doing this for fun in what little free time I
have, boring stuff like updating the docs has not been a high priority :-).

So the situation is pretty much the same as six months ago. There has been
a large number of bug fixes and interface improvements since then, but we
still need to update all the docs and game modules before a 7.5 release.

>Also, is anyone working on the standing orders code? This seems to be
>entirely undocumented, and I only found out it existed by reading the
>mailing list archives... Just the ability to have the computer
>automatically move pieces to a certain hex is helpful, but I can't find it
>in the documentation.

No. This is a partly implemented and seldomly used feature in xconq. But I
agree that it has a strong potential.

>Thankyou for the recent improvements. (has development really picked up
>recently, or am I imagining it?). I am unable to do any practical
>programming myself. In theory I can program in C, but I don't know any
>tcl/tk at all, and I don't have time at the moment to learn the xconq
>sources, so I am grateful to the people who can.

Development has indeed resumed after being dormant for most of 2001 (both
Stan and I ceased to work on xconq in the early spring that year). If you
want to contribute to xconq development, you are welcome to do so. You
don't need to know tcltk for that. The entire kernel is written in C, so if
you want to tinker with, for example, the standing orders code, you can
easily do that. Another good way to get started with xconq hacking is to
write a new game module. This helps a lot in understanding how the kernel
works.

Hans