Standardizing the Windows build

Standardizing the Windows build

[Brandon J. Van Every]

From private discussion with Eric, it seems there is no standard,
canonical build environment for Xconq on Windows.  There aren't even any
regular Windows developers, apparently?  Xconq development is
Linux-centric and that does not result in reliable build procedures
under Windows.  This is an impediment to Windows developers, such as
myself, contributing anything to Xconq.

I am willing to do the work of creating MS Visual Studio project files,
if we can come to a consensus on what the standards should be.  A
non-exhaustive list of issues:

- Cygwin vs. MinGW installations.  When I tried to get Freeciv built
with the latter, I had a really lousy experience.

- TCL distributions.  Eric thinks the TCL binary currently distributed
with Cygwin is broken.  I'm not sure myself, but I'm utterly unwilling
to chase TCL's tail in the absence of a consensus on the build
environment.  Some options are: Cygwin TCL binary, build TCL from
scratch under Cygwin, use the high quality ActiveState Windows native
TCL distribution.  I personally think the latter should be used because
that's what all Windows people who do TCL use.

- Weaning Xconq of Unix-specific Cygwin code.  I realize that Cygwin is
needed because Xconq is fundamentally a Unix app.  But I'd like to see
the Unix-specific stuff isolated as much as possible.  Cygwin
compilation perhaps becomes a custom build step in an otherwise MS
Visual Studio build.

- Religion about commercial IDEs.  If most of you think MS Visual Studio
is Evil, then we aren't going to get anywhere.  Most of us Windoze
developers think that being forced to use Unix-ported tools and editors
is a PITA.  We ain't gonna do it.  If you want Windoze developers, IMO
the code needs to build in an environment that most Windoze developers
are willing to use.

- Religion about versions of MS Visual Studio.  I have VS6, VS .NET
2002, and VS .NET 2003.  I would insist on having 2003.  I might be
willing to support all 3 builds, but 2003 would be the one that gets the
regular testing.

Ok, before anyone even wastes time arguing about *those* issues, I think
I'd better give you full disclosure on my various development agendas.
That way you can make up your mind whether I'd be a welcome contributor
or a downright menace.  If we're not on the same page, or compatible
pages, then open source development becomes a waste of my time compared
to proprietary development.

First disclosure: I won't write C code.  I won't even write C++ code
unless it's to heavy duty optimize something.  I have 11 years of
experience as a 3D graphics optimization jock, and I've learned the
error of my ways.  I'm only interested in higher level languages
nowadays.  As far as what I *want* to develop in, that would be Python.
As far as what I feel I *need* to develop in to be commercially
marketable, that would be C#.  The concept of Java has always bored me
to tears and still does.  You can think of me as a Python guy who's
begrudgingly doing C# so he can get gigs in Redmond.

Second disclosure: I'm interested in DirectX and .NET stuff.  Sure it's
not portable.  But, if a platform specific set of code is kept small, I
don't care.  I'm not interested in religion about how you've gotta use
portable everywhere for everything.  Sometimes it saves work, often
times it doesn't.  I believe in largely platform independent code, not
entirely platform independent code.

Third disclosure: as a game designer, I'm not interested in
conservatively tweaking and refining Xconq.  I'm interested in building
new games with Xconq code.  I don't really have a handle on your
developer culture in this regard yet... it seems you guys create some
very different things with this GDL layer of yours.  My main drive is to
get rid of things in 4X TBS games that waste time.  For instance, I
can't stand the fact that Civ games take me 16..24 hours to play.  So
much of that time is boring crap!

So, that's who I am.  Friend or foe?


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

Re: Standardizing the Windows build

[Eric McDonald]

On Fri, 7 Nov 2003, Brandon J. Van Every wrote:

> >From private discussion with Eric, it seems there is no standard,
> canonical build environment for Xconq on Windows.  There aren't even any
> regular Windows developers, apparently?  Xconq development is
> Linux-centric 

I told you that Hans develops on the Mac.

> I am willing to do the work of creating MS Visual Studio project files,
> if we can come to a consensus on what the standards should be.  A
> non-exhaustive list of issues:
> 
> - TCL distributions.  Eric thinks the TCL binary currently distributed
> with Cygwin is broken.  I'm not sure myself, 

Actually, I'm the one who isn't sure. What I am pretty sure about 
is that the Cygwin Tcl installation on _your_ system is broken. If 
your TCL_INCLUDE_SPEC points to a nonexistent directory, then 
something isn't right. (And if this argument is going to reach 
flamewar crescendo again, let's take it back off-list.)

> - Religion about commercial IDEs.  If most of you think MS Visual Studio
> is Evil, then we aren't going to get anywhere.  Most of us Windoze

It's not a matter of being evil. I simply would not want to say 
that I would want that to be the only approved, supported way to 
build Xconq under Windows. I think it can and should be an 
alternative though. And if you make it a viable alternative, I 
can't imagine anyone complaining.

> I'd better give you full disclosure on my various development agendas.
> That way you can make up your mind whether I'd be a welcome contributor
> or a downright menace.

It's hard to be a menace to GPL'd code unless you're stealing 
copyrights or violating the rather liberal terms of the license.

> Second disclosure: I'm interested in DirectX and .NET stuff.  Sure it's

Some DirectX optimization for the Windows Tcl/Tk and SDL apps 
might be desirable.

Eric

RE: Standardizing the Windows build

[Brandon J. Van Every]

From: Eric McDonald [mailto:mcdonald@phy.cmich.edu]
> On Fri, 7 Nov 2003, Brandon J. Van Every wrote:
> >
> > - TCL distributions.  Eric thinks the TCL binary currently
> > distributed with Cygwin is broken.  I'm not sure myself,
>
> Actually, I'm the one who isn't sure. What I am pretty sure about
> is that the Cygwin Tcl installation on _your_ system is broken. If
> your TCL_INCLUDE_SPEC points to a nonexistent directory, then
> something isn't right. (And if this argument is going to reach
> flamewar crescendo again, let's take it back off-list.)

Eric, with all due respect, if you believe
TCL_INCLUDE_SPEC=C:\nonexistent\include
is somehow unique to my machine, and is not a property of the current
standard Cygwin distribution, then you didn't download a clean Cygwin
distribution and check it.  You also said you built your own TCL from
sources some time ago and never used the Cygwin binary distribution.
Either sanity check it yourself, or accept that the current Cygwin TCL
binaries are what they are.

> > - Religion about commercial IDEs.  If most of you think MS
> > Visual Studio
> > is Evil, then we aren't going to get anywhere.  Most of us Windoze
>
> It's not a matter of being evil. I simply would not want to say
> that I would want that to be the only approved, supported way to
> build Xconq under Windows.

As it stands now, there is no particular approved, supported way to
build Xconq under Windows.  You've suggested to me that to do Xconq
under Windoze right now, it'll take "fiddling."  I certainly did a lot
of fiddling between Freeciv and Xconq last week, and I won't do it
anymore.  Nor will Windoze developers in general.  It was a complete
waste of time, 1 solid week down the drain.  I can't spend time like
that, for nothing.

There should be at least 1 approved, supported way.  It should be the
primary, expected way.  If you personally want to provide support for
secondary ways, feel free.  But there should be a primary, expected way,
that the vast majority of Windoze developers and developer wannabes use.

The policy should be, "We do this, we stress test it, and we know that
it works.  If you want to do something else, it may work, but we don't
stress test it.  We may not be willing to put any energy into making it
work."  That's generally what is meant by "standardized."

> I think it can and should be an
> alternative though. And if you make it a viable alternative, I
> can't imagine anyone complaining.

'Cept me.  Why should I support a Windoze build that nobody else will
stress test and develop with?  I shouldn't.  It would make more sense to
find a project that isn't Linux freeware centric.  No sense wasting time
on things that other people don't want and don't need.

> It's hard to be a menace to GPL'd code unless you're stealing
> copyrights or violating the rather liberal terms of the license.

The code cannot be menaced, but a developer team definitely can be.  Or
more likely, a potential contributor can be marginalized.  There's
nothing stopping me from taking the Xconq code and doing whatever I'd
like with it within the terms of the license.  I've certainly considered
it.  But, that doesn't give me too many advantages over just coding my
own game from scratch.  The advantage is to work with an extant team
that knows the code, provides new features, bugfixes, labor if they're
interested in some idea, etc.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

RE: Standardizing the Windows build

[Eric McDonald]

On Fri, 7 Nov 2003, Brandon J. Van Every wrote:

> From: Eric McDonald [mailto:mcdonald@phy.cmich.edu]
> > On Fri, 7 Nov 2003, Brandon J. Van Every wrote:

> > is that the Cygwin Tcl installation on _your_ system is broken. If
> > your TCL_INCLUDE_SPEC points to a nonexistent directory, then
> > something isn't right. (And if this argument is going to reach
> > flamewar crescendo again, let's take it back off-list.)
> 
> Eric, with all due respect, if you believe
> TCL_INCLUDE_SPEC=C:\nonexistent\include
> is somehow unique to my machine,

I didn't say it was unique to your machine, but I am not going to 
generalize it to everyone either. Hence the "I'm not so sure".

> standard Cygwin distribution, then you didn't download a clean Cygwin
> distribution and check it.

That's correct. I didn't, and I didn't tell you that I did either.

>  You also said you built your own TCL from
> sources some time ago and never used the Cygwin binary distribution.

Never _successfully_ used the Cygwin Tcl/Tk binaries (which were 
old anyway).

> Either sanity check it yourself, or accept that the current Cygwin TCL
> binaries are what they are.

Which is what?

> > It's not a matter of being evil. I simply would not want to say
> > that I would want that to be the only approved, supported way to
> > build Xconq under Windows.
> 
> As it stands now, there is no particular approved, supported way to
> build Xconq under Windows.

That would seem to be the case. I suppose I should sit down 
sometime and recreate the way I built Tcl/Tk on Cygwin, or else 
go entirely to ActiveTcl for everything. Then there would be at 
least one way.

>  You've suggested to me that to do Xconq
> under Windoze right now, it'll take "fiddling." 

Yes. To build it, anyway. To play it or design games with it, no; 
that "issue" has recently been addressed.

> There should be at least 1 approved, supported way.  It should be the
> primary, expected way.

Sounds good.

> secondary ways, feel free.  But there should be a primary, expected way,
> that the vast majority of Windoze developers and developer wannabes use.

Sounds good.

> The policy should be, "We do this, we stress test it, and we know that
> it works.

If you wish to volunteer to be the person who upholds that policy, 
then please be my guest.

> stress test it.  We may not be willing to put any energy into making it
> work."  

Or at least not put any energy into it at this moment.

> > can't imagine anyone complaining.
> 
> 'Cept me.  Why should I support a Windoze build that nobody else will
> stress test and develop with?  

I ask myself the same question. 

>I shouldn't.  

Then why should I? You seem to be complaining that we didn't do 
this for you, when you yourself wouldn't do it for others.

> nothing stopping me from taking the Xconq code and doing whatever I'd
> like with it within the terms of the license.

That's correct. One of the very nice features of such a 
license....

> own game from scratch.  The advantage is to work with an extant team
> that knows the code, provides new features, bugfixes, labor if they're
> interested in some idea, etc.

Yes.

Eric

Re: Standardizing the Windows build

[Hans Ronne]

>From private discussion with Eric, it seems there is no standard,
>canonical build environment for Xconq on Windows.  There aren't even any
>regular Windows developers, apparently?  Xconq development is
>Linux-centric and that does not result in reliable build procedures
>under Windows.  This is an impediment to Windows developers, such as
>myself, contributing anything to Xconq.

As somebody who uses Mac OS 90% of the time, I wouldn't quite agree that
Xconq-development is Linux-centric :-). In fact, the Tcl interface was
largely modelled on the Mac interface, which was the first "modern" Xconq
(not counting the old X11 interface). But I get your point. The Windows
version started with Cygwin, for various reasons. Stan worked at Cygnus
when he wrote most of Xconq.

>- Weaning Xconq of Unix-specific Cygwin code.  I realize that Cygwin is
>needed because Xconq is fundamentally a Unix app.  But I'd like to see
>the Unix-specific stuff isolated as much as possible.  Cygwin
>compilation perhaps becomes a custom build step in an otherwise MS
>Visual Studio build.

Cygwin is in not needed for Xconq any more than the Mac interface is. The
kernel is completely platform and interface independent. The only reason
for supporting Cygwin is that some Xconq developers like it a lot. I
suggested that we should drop Cygwin support two years ago, when we first
got it to build natively under Windows. That was not a popular idea on this
list, however.

The Xconq philosophy is to keep support for diverse platforms and build
tools as long as it does not get in the way of things. People who have a
specific interest usually add and maintain support. Example: the MinGW
support was added by Juergen Ruehle. Eric has worked a lot with the Cygwin
support recently.

When something is not used and gets in the way, we are not sentimental
about keeping it. The Mac interface used to build with Apple's MPW, Think C
and CodeWarrior. We threw out MPW and Think C last year since few use them
anymore.

>Ok, before anyone even wastes time arguing about *those* issues, I think
>I'd better give you full disclosure on my various development agendas.

>First disclosure: I won't write C code [...] You can think of me as a
>Python guy who's
>begrudgingly doing C# so he can get gigs in Redmond.

>Second disclosure: I'm interested in DirectX and .NET stuff.  Sure it's
>not portable.  But, if a platform specific set of code is kept small, I
>don't care.  I'm not interested in religion about how you've gotta use
>portable everywhere for everything.

>Third disclosure: as a game designer, I'm not interested in
>conservatively tweaking and refining Xconq.  I'm interested in building
>new games with Xconq code.  I don't really have a handle on your
>developer culture in this regard yet... it seems you guys create some
>very different things with this GDL layer of yours.

>So, that's who I am.  Friend or foe?

Anybody who wants to contribute to Xconq is a friend. I don't see any major
problems with your agenda unless you wish to impose platform and/or
interface-dependent solutions that would create problems for the other
platforms and interfaces. But I think that can be avoided, because of the
platform and interface-independent nature of the Xconq kernel. What this
means is that if you want to add specific improvements to the Windows
interface, such as DirectX support, or even write a completely new Windows
interface, this is possible without messing up the Mac or Unix interfaces.

OTOH, if you want to hack the kernel, you do have to worry about
maintaining support for the other interfaces. Since you said you "won't
write C code" your contributions to the kernel would, however, be rather
limited, at least as things stand right now.

Actually, there are three very different aspects of Xconq development:
writing new games, improving the interfaces and hacking the kernel.

Most contributors to Xconq have started in either of two ways, by writing
new games or by improving their favourite interface. I gather you are
interested in both. You want to add DirectX support to the Windows
interface(s). But you also say you are interested in building new games.
Fine. What you should realize, however, is that if you are serious about
building new games (and not just modding existing ones) this will very
quickly bring you into the kernel. Every game I have written eventually led
me into the kernel, either to add new ideas or improve GDL support for
existing ones.

And the kernel is of course written in C. If you want to write entirely new
games you would therefore in the end have to get your hands dirty with C.
Either that or rewrite the kernel in your favourite language (Python?). If
you want to give it a try, you are welcome to do so, but be warned: others
have tried before. The most serious attempt so far was made by Ed
Oskiewicz. He made sure Xconq would build under C++ (and still maintain
compatibility with plain C). However, it is a big leap from there to
actually transform the kernel into object oriented code. And it is a leap
that cannot be taken in small steps.

So my guess is that you would find it easier to work on the Windows
interface, given your stated interests and preferences. A Windows-native
(non-Tcl) interface would be a very welcome contribution to Xconq. Tcl has
severe limitations, which you can easily see if you compare the Mac TCL and
Mac PPC native interfaces of Xconq.

One thing that I strongly believe in when it comes to interface
improvements is SDL. Stan started to work on an SDL interface three years
ago, and it builds on all three platforms. It is much faster than TCL and
also much easier to code (it took me just one day to get the Mac version of
Xconq for SDL up and running). This, and the extensive cross-platform
support makes it an attractive alternative as a future Xconq interface. But
SDL is of course written in plain C ...

Hans

Re: Standardizing the Windows build

[Eric McDonald]

On Sat, 8 Nov 2003, Hans Ronne wrote:

> So my guess is that you would find it easier to work on the Windows
> interface, given your stated interests and preferences. A Windows-native
> (non-Tcl) interface would be a very welcome contribution to Xconq.

Yes. If we swing to SDL as our primary interface during the next 
release cycle, one might want to consider native Win32 support 
for the UI elements such as menus and windows. Or using a 
cross-platform library of UI elements (such as wxWindows, though 
it is C++ code)....

  Regards,
    Eric

Re: Standardizing the Windows build

[Hans Ronne]

>On Sat, 8 Nov 2003, Hans Ronne wrote:
>
>> So my guess is that you would find it easier to work on the Windows
>> interface, given your stated interests and preferences. A Windows-native
>> (non-Tcl) interface would be a very welcome contribution to Xconq.
>
>Yes. If we swing to SDL as our primary interface during the next
>release cycle, one might want to consider native Win32 support
>for the UI elements such as menus and windows. Or using a
>cross-platform library of UI elements (such as wxWindows, though
>it is C++ code)....

In fact, the SDL Win32 libraries are now based on DirectX. So we already
have that in the SDL interface.

Hans

RE: Standardizing the Windows build

[Brandon J. Van Every]

From: Eric McDonald [mailto:mcdonald@phy.cmich.edu]
>
> > The policy should be, "We do this, we stress test it, and
> > we know that it works.
>
> If you wish to volunteer to be the person who upholds that policy,
> then please be my guest.

Let's find out if everyone / anyone else wants me to be "the guest."
While we're at it, let's find out if there are any Windoze developers
here?

> > 'Cept me.  Why should I support a Windoze build that nobody
> > else will stress test and develop with?
>
> I ask myself the same question.
>
> >I shouldn't.
>
> Then why should I? You seem to be complaining that we didn't do
> this for you, when you yourself wouldn't do it for others.

It's like this.  I'll build the standard environment if everyone agrees
to the standard, follows the standard, and the Windoze developers stress
test the standard.  (Are there any??)  I'm not going to do it if one
person says "I want it this way," another says "no, I want it that way!"
and nothing I build actually gets stress tested.  And finally, if I am
to take ownership of it, VS .NET 2003 has to be the primary build
environment.  Life is too short to screw around with all the other kinds
of pain.  There will have to be a Cygwin or MinGW custom build step, but
VS .NET 2003 is The Right Way Going Forwards to do mainstream Windoze
development.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

Windows native UIs

[Brandon J. Van Every]

From: Eric McDonald [mailto:mcdonald@phy.cmich.edu]
> On Sat, 8 Nov 2003, Hans Ronne wrote:
>
> > So my guess is that you would find it easier to work on the Windows
> > interface, given your stated interests and preferences. A
> Windows-native
> > (non-Tcl) interface would be a very welcome contribution to Xconq.
>
> Yes. If we swing to SDL as our primary interface during the next
> release cycle, one might want to consider native Win32 support
> for the UI elements such as menus and windows. Or using a
> cross-platform library of UI elements (such as wxWindows, though
> it is C++ code)....

My opinion here: SDL is not a native Windows interface.  It is simply a
non-TCL interface.  SDL is C and that's crufty, but at least it has
bindings for various other languages.  For instance it has a C#
binding... which probably doesn't work, as that project looks really
shaky and starved for attention.  The best SDL-based technology I'm
aware of is Kyra, which is a C++ layer on top of SDL.
http://www.grinninglizard.com/kyra/  Aside from giving a proper OO
approach (at least I think so, haven't used it yet), they have excellent
2D alpha blended sprites in SW that SDL does not have.  The demo of Kyra
is a rather slick benchmark, they are serious about performance in SW.

Typically, these non-Windows interfaces are portable, but at the expense
of performance, added cruft, and lack of a feather in your cap.  Nobody
gets paid big bucks for knowing SDL.  The proper way to write a Windows
UI nowadays is with .NET and C#.  Not Win32.  If I write any Windows
interfaces, very likely it will be in .NET and C#.  I'd only do TCL or
SDL if the value of what's already written outweighs the cruft.  I would
never, for instance, use wxWindows to write UIs from scratch.

The question is whether UIs are important and elaborate parts of Xconq
development.  Enough to be worth the trouble of trying to stay uniform
across platforms.  My primary interest is writing new games and getting
rid of interfaces that slow down gameplay, whether due to the game
design, the UI design, or the performance.  Ergo, I don't care about
maintaining existing UIs.  I do care about being able to rapidly create
new ones, and/or minimizing the need for UI stuff in the first place.  I
like games to be as close to a clean, cinematic rectangle as possible.
I do not like games that play like MS Word.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

The gory Xconq kernel

[Brandon J. Van Every]

From: Hans Ronne [mailto:hronne@comhem.se]
>
> And the kernel is of course written in C. If you want to
> write entirely new
> games you would therefore in the end have to get your hands
> dirty with C.
> Either that or rewrite the kernel in your favourite language
> (Python?). If
> you want to give it a try, you are welcome to do so,

I have no interest in rewriting the entire Xconq kernel.  That kind of
project is what I call a Complete Waste Of Time.  If you can't
incrementally modify it, better to write a new game from scratch!

> but be warned: others
> have tried before. The most serious attempt so far was made by Ed
> Oskiewicz. He made sure Xconq would build under C++ (and
> still maintain
> compatibility with plain C). However, it is a big leap from there to
> actually transform the kernel into object oriented code. And
> it is a leap that cannot be taken in small steps.

That last sentence is rather disturbing.  Are you saying that no matter
what one's skill level, the Xconq kernel is such spaghetti that modules
of it simply cannot be untangled?  I can see myself doing Python in
kernel, for bits and pieces here and there, as I think of a feature I
want / need.  Particularly for AI stuff.  Are you saying this ain't
likely to be feasible in practice?

Caveat: I have yet to attempt to understand the Xconq source code or
read any docs about it.  Getting it to even build on Windoze was the 1st
priority, and I still don't have a working build.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

RE: Standardizing the Windows build

[Brandon J. Van Every]

Hans Ronne wrote:
>
> In fact, the SDL Win32 libraries are now based on DirectX. So
> we already have that in the SDL interface.

Do you mean DirectDraw, which ceased development with DirectX 7, and
doesn't do HW accelerated alpha blending?  Whoopie doo.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

Re: The gory Xconq kernel

[Hans Ronne]

>I have no interest in rewriting the entire Xconq kernel.  That kind of
>project is what I call a Complete Waste Of Time.  If you can't
>incrementally modify it, better to write a new game from scratch!

Sure you can incrementally modify it. That's what we do all the time. But
it's written in C, like it or not. Did I take your statement about never
touching C too literally?

>That last sentence is rather disturbing.  Are you saying that no matter
>what one's skill level, the Xconq kernel is such spaghetti that modules
>of it simply cannot be untangled?  I can see myself doing Python in
>kernel, for bits and pieces here and there, as I think of a feature I
>want / need.  Particularly for AI stuff.  Are you saying this ain't
>likely to be feasible in practice?

Not at all. All I'm saying it's hard work. You won't do it in a weekend,
irrespective of your skill level.

That being said, I think the Xconq kernel could benefit from a rewrite in
an object oriented language and I encourage any such attempts. But so far
they have remained attempts :-/.

>Caveat: I have yet to attempt to understand the Xconq source code or
>read any docs about it.  Getting it to even build on Windoze was the 1st
>priority, and I still don't have a working build.

I don't understand this problem.  As Juergen Ruehle said, it's pretty
straightforward to build it under MSVC (or CodeWarrior). Didn't take me
many minutes to get a working Windows build, though I am not a Windows
developer. All you need in addition to the runtime C stuff are five
libraries: tcl84.lib, tk84.lib, kernel32.lib, user32.lib and wsock32.lib.
Replace tcl84.lib and tk84.lib with SDL.lib and SDLMain.x86.lib to build
the SDL interface.

Hans

Re: Windows native UIs

[Hans Ronne]

>My opinion here: SDL is not a native Windows interface.  It is simply a
>non-TCL interface.  SDL is C and that's crufty, but at least it has
>bindings for various other languages.

Including Python:

http://pygame.seul.org/

>The question is whether UIs are important and elaborate parts of Xconq
>development.  Enough to be worth the trouble of trying to stay uniform
>across platforms.  My primary interest is writing new games and getting
>rid of interfaces that slow down gameplay, whether due to the game
>design, the UI design, or the performance.  Ergo, I don't care about
>maintaining existing UIs.  I do care about being able to rapidly create
>new ones, and/or minimizing the need for UI stuff in the first place.  I
>like games to be as close to a clean, cinematic rectangle as possible.

A clean cinematic rectangle is precisly what the SDL interface is all
about. If you haven't checked it out yet, I suggest you do. It's not
finisned yet, but you can run it under AI control and get a good idea for
how it works.

Whether or not UIs are an important part of Xconq development or not
depends on what you want to achieve in the end. Cross-platform support is
important to the Xconq community. That's the whole point of keeping the
kernel and interface code distinct. And with several platforms, things like
TCL or SDL will save you a lot of work. You only have to write the
interface once, not three times.

That being said, a Windows-native interface that works with the current
kernel would be a welcome addition. As would any improvements to the kernel
that maintains support for the interfaces. But if you want to write
something that runs only one specific game on only on one platform (which
seems to be the gist of your agenda) I don't think you would be able to
contribute much in the end to this project, which is a multi-game
multi-platform one.

Hans

RE: Standardizing the Windows build

[Hans Ronne]

>Hans Ronne wrote:
>>
>> In fact, the SDL Win32 libraries are now based on DirectX. So
>> we already have that in the SDL interface.
>
>Do you mean DirectDraw, which ceased development with DirectX 7, and
>doesn't do HW accelerated alpha blending?  Whoopie doo.

If you want Direct3D, it's not built-in, but I understand there are ways to
use it together with SDL. There have been some posts on the SDL developers
list about how to integrate SDL with Direct3DRM from DX9. Haven't paid much
attention to this stuff, though, so I don't know how far it will take you.

The key question here is: what would we use 3D support for, and how is it
best implemented? Xconq is a 2D program. It could be transformed into a 3D
program, and I think it's an exciting possibility. However, that if
anything would require a major rewrite of the kernel. It's not enough to
have 3D support in the interfaces, the games must also be able to do
something useful with it!

The there is the question of what kind of 3D support. I don't think we
should start a D3D-OpenGL flame thread, but the latter does have advantages
if you are dealing with a cross-platform project like Xconq. And it is
supported (also the most recent version) in SDL.

Hans

SDL and 3D

[Brandon J. Van Every]

Hans Ronne
> >Hans Ronne wrote:
> >>
> >> In fact, the SDL Win32 libraries are now based on DirectX. So
> >> we already have that in the SDL interface.
> >
> >Do you mean DirectDraw, which ceased development with DirectX 7, and
> >doesn't do HW accelerated alpha blending?  Whoopie doo.
>
> If you want Direct3D, it's not built-in, but I understand
> there are ways to use it together with SDL.

Which would be pretty silly, since SDL is an OpenGL-centric developer
community.

> There have been some posts on the SDL developers
> list about how to integrate SDL with Direct3DRM from DX9.
> Haven't paid much
> attention to this stuff, though, so I don't know how far it
> will take you.

Wow, clearly!  By your language, you must not have looked at Direct3D
since before DirectX 5.0.  People haven't referred to "Retained Mode"
for a looooong time.  This is like when I automatically say "Merced"
about Intel's 64-bit CPUs.  :-)

> The key question here is: what would we use 3D support for,
> and how is it
> best implemented? Xconq is a 2D program. It could be
> transformed into a 3D
> program, and I think it's an exciting possibility. However, that if
> anything would require a major rewrite of the kernel. It's
> not enough to
> have 3D support in the interfaces, the games must also be able to do
> something useful with it!

No, Xconq does not have to be a 3D game design to have a 3D interface.
3D can be just a form of eye candy for an essentially 2D game.  For
instance, instead of tediously implementing a 2D isometric display
engine, you could just make a 3D one.  Instead of creating bitmaps of
units in different orientations, you could render the units directly
from 3D models.

I want to emphasize that I have no interest whatsoever in implementing
3D versions of Xconq.  I'm interested in game design, UI efficiency, and
AI.  If anyone *else* wants to implement 3D stuff and take on the major
burden of such efforts, I can lend a helping hand though.  3D is after
all my core skillset.  It's also IMO a big waste of time, which is why
I'm currently interested in the other things, not 3D.

If someone were to implement a 3D version of Xconq, I would strongly
suggest using The Nebula Device.
http://nebuladevice.sourceforge.net/cgi-bin/twiki/view/Nebula/WebHome
You'd want to use Version 1, as Version 2 is under construction, not
portable, DX9 centric, and missing lotsa stuff like Python bindings etc.
Nebula 1 has been used in several commercial titles, most notably
Project Nomads, a very good looking game.
http://www.project-nomads.de/

The Nebula license is MIT/BSD style, do what you want with it.  Fair
warning: I will refuse to help people who try to GPL any modifications
they make to Nebula, or otherwise de-contribute / restrict Nebula.  I'm
on the BSD side of the Open Source debate, mostly.  I think GPL is valid
for game projects, as otherwise someone would just turn around and sell
the game project commercially.  But I think languages, engines, and
libraries should be completely free for anybody's use, whether open
source or proprietary.  If you're going to give something away, give it
away completely.  If you're worried about something falling into "the
wrong hands," then don't give it away, keep it proprietary.  I do not
generally believe in the GPL "everything must be open" business model.
I believe "sane" SW development should be a mixture of open source and
proprietary source, and the open source components should not get in the
way of the proprietary needs.

> The there is the question of what kind of 3D support. I don't think we
> should start a D3D-OpenGL flame thread, but the latter does
> have advantages
> if you are dealing with a cross-platform project like Xconq. And it is
> supported (also the most recent version) in SDL.

You should not bicker about 3D APIs.  You should not implement 3D
engines from scratch.  You should avail yourselves of the complete open
source 3D engines readily available.  Nebula is merely the best of the
bunch, there are several others out there.  Personally I think Nebula is
better by a wide margin.  I don't see that any of the other ones have
shipped 10 commercial titles, or even 1 commercial title.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

Ease of MSVC build

[Brandon J. Van Every]

From: Hans Ronne [mailto:hronne@comhem.se]
>
> >Caveat: I have yet to attempt to understand the Xconq source code or
> >read any docs about it.  Getting it to even build on Windoze
> was the 1st
> >priority, and I still don't have a working build.
>
> I don't understand this problem.  As Juergen Ruehle said, it's pretty
> straightforward to build it under MSVC (or CodeWarrior).
> Didn't take me
> many minutes to get a working Windows build, though I am not a Windows
> developer.

If it is so easy, why is there no MSVC build?  Why hasn't whoever made
this thing checked in their build files?

On the premise that it is so easy, I will try to do it.  If it doesn't
work, then I'm going to be annoyed, and we'll be back to the Windows
standardization discussion.  I will find it most ironic if the easy way
to build it existed all along, but due to lack of communication and lack
of a standard, people like myself were misled to do it the hard, painful
Cygwin way!


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

Re: SDL and 3D

[Eric McDonald]

On Sat, 8 Nov 2003, Brandon J. Van Every wrote:

> > best implemented? Xconq is a 2D program. It could be
> > transformed into a 3D
> > program, and I think it's an exciting possibility. However, that if
> > anything would require a major rewrite of the kernel. It's
> > not enough to
> > have 3D support in the interfaces, the games must also be able to do
> > something useful with it!
> 
> No, Xconq does not have to be a 3D game design to have a 3D interface.
> 3D can be just a form of eye candy for an essentially 2D game.  

I agree.

> Instead of creating bitmaps of
> units in different orientations, you could render the units directly
> from 3D models.

Yes. This is essentially what I envision when I think of 3D Xconq, 
and this is also the approach I have considered.

Eric

Re: Ease of MSVC build

[Eric McDonald]

On Sat, 8 Nov 2003, Brandon J. Van Every wrote:

I probably shouldn't even respond to this, but:

> On the premise that it is so easy, I will try to do it.  If it doesn't
> work, then I'm going to be annoyed, 

O spare us your wrath, "your royal highness"!

>and we'll be back to the Windows
> standardization discussion. 

Whatever.

> I will find it most ironic if the easy way
> to build it existed all along, but due to lack of communication and lack
> of a standard, people like myself were misled to do it the hard, painful
> Cygwin way!

I find it rather ironic that someone who has claimed to be a Linux 
guru (via private email) and who has claimed to have "gigs with 
Microsoft" can spend a "solid week" not being able to build an 
app and throws a chest-thumping, egotistical temper tantrum 
whenever anything doesn't immediately go his way. If you have the 
credentials you say you have, then why the hell don't you just 
shut up, buckle down, do a little work, and take care of your 
problems? (Instead of belching your Mordorsoft Nazgul-breath all 
over happy little Xconqshire? And instead of trying to bully and 
prod others to think and work for you?)

RE: Ease of MSVC build

[Brandon J. Van Every]

Eric wrote:
>
> I find it rather ironic that someone who has claimed to be a Linux
> guru (via private email)

Sure... in 1993!  I haven't done Linux since 1996.

> and who has claimed to have "gigs with
> Microsoft" can spend a "solid week" not being able to build an
> app and throws a chest-thumping, egotistical temper tantrum
> whenever anything doesn't immediately go his way.

You know Eric, the Xconq Windoze build procedure is currently pretty
lame.  If it actually does work and doesn't need Cygwin, I'll be a
little more impressed.  But as it appears now... it had INSTALL-win in
CVS, but not in a way that anyone would see upon downloading CVS.  Why?
Because nobody's actually doing the Windoze build regularly to know.
The current Cygwin TCL binaries don't work, but you don't know that,
because you built from TCL sources a long time ago.  Again, nobody doing
the Windoze build regularly.  Others claim MSVC build is easy, but this
MSVC build isn't even in CVS.  Again, why?  Because nobody's actually
doing the Windoze build regularly.  It takes many days of going over
these things in e-mail to find some of these details out.  Like, that
supposedly Xconq doesn't even *need* Cygwin for anything, that it's not
the "fundamentally Unix app" you say it is.  Again, why?

Why would any Windoze developer take this situation seriously, without a
pound bag of rock salt?

Are you familiar with what a Complete Waste Of Time is?  The reason
people standardize on these sorts of things and check them into CVS is
so that future generations of programmers don't have to suffer all these
futz factors.  Even communicating about *one* bug wastes developer time.

> If you have the
> credentials you say you have, then why the hell don't you just
> shut up, buckle down, do a little work, and take care of your
> problems?

Because I'm not interested in some goddamn wild goose chase that wastes
*another* week of my time, that's why.  Once burned, one becomes rather
cautious about gathering information first and trying things second.

For instance, one thing I know now that I didn't know before: people
aren't going to make vampire cross fingers at me because of my
development agenda.  If it had been otherwise, if people had said "No!
No! Go away!" then there would have been no point in putting any more
effort into Xconq.  First things first.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

RE: Ease of MSVC build

[Brandon J. Van Every]

Brandon J. Van Every wrote:
> But as it appears now... it had INSTALL-win in
> CVS, but not in a way that anyone would see upon downloading
> CVS.  Why?
> Because nobody's actually doing the Windoze build regularly to know.

Oh yeah, and I'll add that the MSVC instructions in INSTALL-win are
empty.  One would usually surmise from that sort of thing that MSVC is
not a working build procedure.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Re: SDL and 3D

[Hans Ronne]

>I want to emphasize that I have no interest whatsoever in implementing
>3D versions of Xconq.  I'm interested in game design, UI efficiency, and
>AI.

As in all open source development, what you choose to do is up to you, and
the proof is in the pudding. If you contribute something useful to Xconq,
whether it's a game module, a better AI or a new Windows interface, people
will appreciate it. Provided that it works, of course.

So far, all we have heard from you is that you are unable to build a simple
Windows app, despite trying hard for a week. Which raises questions about
your ability to contribute in a meaningful way to Xconq development.

To prove yourself, you would have to "shut up, buckle down, and do a little
work" as Eric so aptly put it.

Hans

whose Windoze build it is anyways

[Brandon J. Van Every]

From: Hans Ronne [mailto:hronne@comhem.se]
>
> So far, all we have heard from you is that you are unable to
> build a simple
> Windows app, despite trying hard for a week. Which raises
> questions about
> your ability to contribute in a meaningful way to Xconq development.

Well equally, what you guys have proven is you don't competently
maintain and communicate a proper Windoze build enviornment.  Not can't,
but don't.  I'm sure you guys do fantastic Linux build maintenance.
Your treatment of Windoze leaves a lot to be desired.  Honestly, if you
pulled any of this stuff with your Linux build, people would laugh at
you.  They'd say you were bad Linux developers.  Since you're good Linux
and Mac developers, I don't exactly expect you to be good Windoze
developers.  But I do expect you to not make excuses for your worst
practices.

> To prove yourself, you would have to "shut up, buckle down,
> and do a little work" as Eric so aptly put it.

Tell you what.  You guys admit what you have put inadequate effort into
(where "inadequate" means by general standards of Windoze development,
not your personal needs), and I'll give you proper MSVC project files.
I'm not interested in hearing any more crap from you guys about how your
lousy Windoze build practices are somehow my fault.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

easy build trees for non-Xconq gurus

[Brandon J. Van Every]

From: Hans Ronne [mailto:hronne@comhem.se]
>
> Didn't take me many minutes to get a working Windows
> build, though I am not a Windows developer.

And now that I've started creating MSVC project files, I can safely say
you're out of your tree.  It might take *you* not many minutes, being
intimately familiar with every aspect of the Xconq sources.  Someone new
to the sources, it will take hours to do it right.  And that's best
case, assuming it actually works as billed.  "What's your problem?  Why
don't you just spend hours understanding all this cruft?  We assure you
it works, even when we don't test it!"  Now really.

I'm going to be really, really interested to find out whether you guys
are completely full of s***.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Re: whose Windoze build it is anyways

[Stan Shebs]

Brandon J. Van Every wrote:

>From: Hans Ronne [mailto:hronne@comhem.se]
>
>>So far, all we have heard from you is that you are unable to
>>build a simple
>>Windows app, despite trying hard for a week. Which raises
>>questions about
>>your ability to contribute in a meaningful way to Xconq development.
>>
>
>Well equally, what you guys have proven is you don't competently
>maintain and communicate a proper Windoze build enviornment.  Not can't,
>but don't.  I'm sure you guys do fantastic Linux build maintenance.
>Your treatment of Windoze leaves a lot to be desired.  Honestly, if you
>pulled any of this stuff with your Linux build, people would laugh at
>you.  They'd say you were bad Linux developers.  Since you're good Linux
>and Mac developers, I don't exactly expect you to be good Windoze
>developers.  But I do expect you to not make excuses for your worst
>practices.
>
OK all, let's cool it with the attitudes, settle down, and Uncle Stan
can tell you the whole story.

Once upon a time, around 1991-2 I think, there was somebody who tried
to adapt the code into a Windows program, using some Novell(?) app
framework, with some help from me.  It partly worked, I might even have
a binary archived somewhere, but I think the person lost interest, and
I wasn't working on Xconq at the time (this was long before 7.0).

Later, when I was working at Cygnus, we had a version of GDB (WinGDB)
that was built using MSVC, had a fancy Windows GUI etc. It was horrible
to maintain though; I managed GDB at the time, and assigning someone
to work on WinGDB bugs was a handy punishment. 1/2 :-) When cygwin got
good enough, we switched over, used tcl/tk for GUI, and didn't look
back. So that colored my experience, and I decided I didn't want to
build Windows GUI for Xconq from scratch. (The part where using
Windows was like jabbing hot needles in my eyes also played a part;
I know my way around the system, but it's never been comfortable.)

But tcl/tk had a Windows port, and so I figured that was a way to get
something onto the platform with minimal effort; maybe a Windows fan
would try the tcl/tk port, and think "this should have a true Windows
port instead" and sign up to do the work. Well, the results were kind
of disappointing; the reaction was "this looks weird, I'll try it when
it's perfected" - as if Windows programs were some kind of paradigm of
superior interface! So after all the work to get it running at all,
my interest kind of evaporated. Open source development is an n-way
street; I've given away untold hours of my time over the past 17 years,
I don't think it's unreasonable to expect someone who wants to take
advantage of it to contribute a few weeks or months of effort of their
own.

So I'm all for a pure Windows GUI, that's one of the reasons I spent
months cutting the code into interface and kernel; cygwin is handy
but MSVC projects are OK if that's how you want to build things; and a
friendly attitude always works better for cooperation than hostility.
The Xconq goal has always been to accomodate any platform that developers
are interested in supporting.

Stan