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

[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]

>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

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

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