public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
* SDL Interface Development
@ 2004-10-30 23:28 Eric McDonald
  2004-10-31  4:10 ` Lincoln Peters
                   ` (3 more replies)
  0 siblings, 4 replies; 21+ messages in thread
From: Eric McDonald @ 2004-10-30 23:28 UTC (permalink / raw)
  To: xconq7

Hello Xconq developers,

   Today I was thinking about everything that still needs to be done on 
the SDL interface. It would seem that much work must be done in terms of 
things such as widget implementation: a scrollable text box for 
messages, list boxes, drop-down boxes, checkboxes, radio buttons for 
setup and preferences screens, etc.... I have had these bits of work in 
mind every since I took up development of the SDL interface, and have 
not entirely been looking forward to it. (If I was developing an 
SDL-based GUI toolkit for the sake of developing one, it would be a 
different story. Indeed, it would be somewhat appealing.)

   With the help of a powerful scrying tool known as Google, I have 
apparently discovered an easy way out: ParaGUI, 
http://www.bms-austria.com/projects/paragui/
It looks to have most every GUI element that I would want and it would 
undoubtedly shave _months_ off the development of the SDL interface.
However, like most things, this comes at a price.

   The price is twofold:
(1) The ParaGUI API is in C++. This means that Xconq's SDL interface 
would have to be converted to C++ and things going to and from the 
kernel would have to be carefully declared extern "C". I am tempted to 
say this is worth the trouble. I realize that this would break Xconq's 
tendency toward C89 compliance. However, the "damage" would be limited 
to a single user interface, and the kernel should escape unscathed.
(2) ParaGUI has a number of dependencies: Freetype, zlib, libpng, and 
Expat. None of these should be a problem on most modern Linux 
distributions. On Windows, these all are available, thanks in part to 
the Gimp on Win32 project and other reasons. However, any required DLL's 
would have to be bundled with the Windows installer thereby increasing 
its size, perhaps significantly. Some of the space could probably be won 
back once we get to a point where the Tcl/Tk interface no longer needs 
to be provided. Also, I could provide a separate complete install and 
upgrade install. Of course, anyone wishing to do SDL interface 
development on the Win32 platform would have to seek out the necessary 
libraries and headers and install them. Documentation could help aid 
that quest, but the extra work could still be considered an extra 
hurdle. On non-Linux, non-Win32 platforms some compilation of the 
necessary libs would probably be required.

   A while back ago, we considered SDL_Pango for handling of 
international and exotic text. Pango (which SDL_Pango obviously 
requires) is not without dependencies either. So I think point (2) is 
something worth considering. How much should Xconq be able to stand 
alone? And how much should we cave in to rapid development at the 
expense of raising the hacker "cost of entry", so to speak?

   One last note, I am not saying that moving to ParaGUI is without 
work. Probably a widget would have to be created to contain the main map 
and minimap. But, it looks like we get things like themes (font sets, 
background images and gradients) quite easily, and this is something we 
all wanted from/expect of the interface.

Eric

P.S. ParaGUI appears to have been around for over two years now, and is 
still being maintained and developed, and so I don't fear much in the 
way of stagnation.
P.P.S. Here are some ParaGUI screenshots:
http://www.bms-austria.com/projects/paragui/index.php?module=photoshare&func=showimages&fid=1
http://www.freelords.org/screenshots.php
http://www.project-axis.net/pages/screenshots/screens-v03.shtml
http://www.project-axis.net/artbin/screens/snapshot37.png
http://www.project-axis.net/artbin/screens/snapshot36.png

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-30 23:28 SDL Interface Development Eric McDonald
@ 2004-10-31  4:10 ` Lincoln Peters
  2004-10-31  6:13   ` Eric McDonald
  2004-10-31  6:54 ` D. Cooper Stevenson
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 21+ messages in thread
From: Lincoln Peters @ 2004-10-31  4:10 UTC (permalink / raw)
  To: Eric McDonald; +Cc: Xconq list

On Sat, 2004-10-30 at 15:15, Eric McDonald wrote:
>    With the help of a powerful scrying tool known as Google, I have 
> apparently discovered an easy way out: ParaGUI, 
> http://www.bms-austria.com/projects/paragui/
> It looks to have most every GUI element that I would want and it would 
> undoubtedly shave _months_ off the development of the SDL interface.
> However, like most things, this comes at a price.

Well, it certainly looks like it would save a lot of coding, and would
be more efficient than trying to use GTK+ and SDL in the same
application!

> 
>    The price is twofold:
> (1) The ParaGUI API is in C++. This means that Xconq's SDL interface 
> would have to be converted to C++ and things going to and from the 
> kernel would have to be carefully declared extern "C". I am tempted to 
> say this is worth the trouble. I realize that this would break Xconq's 
> tendency toward C89 compliance. However, the "damage" would be limited 
> to a single user interface, and the kernel should escape unscathed.

I think that using C++ in Xconq would be beneficial in the long run for
more reasons than just ParaGUI.  I know that if I was ever going to
tackle a problem like AI programming, I would be *very* reluctant to do
so in a language that is not object-oriented.

> (2) ParaGUI has a number of dependencies: Freetype, zlib, libpng, and 
> Expat. None of these should be a problem on most modern Linux 
> distributions. On Windows, these all are available, thanks in part to 
> the Gimp on Win32 project and other reasons. However, any required DLL's 
> would have to be bundled with the Windows installer thereby increasing 
> its size, perhaps significantly. Some of the space could probably be won 
> back once we get to a point where the Tcl/Tk interface no longer needs 
> to be provided. Also, I could provide a separate complete install and 
> upgrade install. Of course, anyone wishing to do SDL interface 
> development on the Win32 platform would have to seek out the necessary 
> libraries and headers and install them. Documentation could help aid 
> that quest, but the extra work could still be considered an extra 
> hurdle. On non-Linux, non-Win32 platforms some compilation of the 
> necessary libs would probably be required.

I would imagine that having access to these packages would prove useful
beyond enabling us to use ParaGUI.  I remember that it was previously
discussed that using fonts in SDL can be awkward; I suspect that
Freetype would dramatically simplify that.  It would also be good if we
could transition the image library from GIF files to PNG files (thus
freeing Xconq of certain troublesome patent issues), and libpng should
allow us to do just that.  Although I'm not sure if zlib or Expat would
offer any immediate noticeable benefit.

> 
>    A while back ago, we considered SDL_Pango for handling of 
> international and exotic text. Pango (which SDL_Pango obviously 
> requires) is not without dependencies either. So I think point (2) is 
> something worth considering. How much should Xconq be able to stand 
> alone? And how much should we cave in to rapid development at the 
> expense of raising the hacker "cost of entry", so to speak?

It seems to me that lots of programs already use Pango for
internationalization, so I don't see any harm in using it to do the same
with Xconq, aside from the increase in size of the Windows installer.


There is probably a simple way to reduce the size of the Windows
installer, at least for those users who already have the packages that
Xconq depends on, but I'm not yet sure how that would be done.  Maybe if
someone would port apt-get to Windows...

---
Lincoln Peters
<sampln@sbcglobal.net>

The opossum is a very sophisticated animal.  It doesn't even get up
until 5 or 6 PM.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31  4:10 ` Lincoln Peters
@ 2004-10-31  6:13   ` Eric McDonald
  2004-10-31  6:34     ` Elijah Meeks
  0 siblings, 1 reply; 21+ messages in thread
From: Eric McDonald @ 2004-10-31  6:13 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list

Lincoln Peters wrote:

> Well, it certainly looks like it would save a lot of coding, and would
> be more efficient than trying to use GTK+ and SDL in the same
> application!

Yes. This is true.

> I would imagine that having access to these packages would prove useful
> beyond enabling us to use ParaGUI.  I remember that it was previously
> discussed that using fonts in SDL can be awkward; I suspect that
> Freetype would dramatically simplify that.  It would also be good if we
> could transition the image library from GIF files to PNG files (thus
> freeing Xconq of certain troublesome patent issues), and libpng should
> allow us to do just that.  Although I'm not sure if zlib or Expat would
> offer any immediate noticeable benefit.

The fonts issue was simply that we needed a way to actually display the 
Pango-processed fonts on a SDL surface. SDL_Pango solves this issue, and 
Pango itself can utilize Adobe Type I, TrueType, X11 bitmap, etc... 
fonts; IIRC, some of this support comes from Pango using the Freetype 
library. So, I think that it is likely that Freetype will end up being 
among the deps for Xconq whether or not we put ParaGUI to use.

As far as libpng goes, __yes, I agree that this is a good thing. I 
believe that I mentioned some time in the not too distant past that 
utilizing libjpeg, libpng, etc... would be a good idea and would enable 
us to utilize a wider range of image formats. libpng is particularly 
useful if we want to link it into Xcscribe so that we can include unit, 
terrain, etc... images in the HTML help files.

And, if we ever did anything with the SVG library, then we could utilize 
scalable images. But, I think that putting the various libs to work is 
all a bit down the road still.

> It seems to me that lots of programs already use Pango for
> internationalization, so I don't see any harm in using it to do the same
> with Xconq, aside from the increase in size of the Windows installer.

Well, other programs certainly use it and many other external pieces of 
software. But, I have noticed that Xconq seems to tend towards 
"self-sufficiency". It does its own reading of GIF and Windows Bitmap 
files. The CVS repository on 'sources.redhat.com' has older versions of 
Tcl and Tk, and an old curses implementation which can be checked out.

I think that a reasonable compromise would be for me to take some time 
out and package stable releases of the various dependencies as both 
source and Linux ix86 binary RPM packages and in Windows installers. 
Since this has not been done at all in the case of some of the pieces of 
software, I am sure that their respective developers would probably 
appreciate this as well. But, what the Xconq project would gain from 
this is that if someone wanted to join our development efforts, he/she 
would have ready access to all the prereq packages and the packages 
would match those which Xconq was being developed against.

As far as the Windows installer goes, we will just have to see how much 
it grows. It may not be all that much, if the Win32 version of Freelords 
that I unzipped earlier today is any indicator. Most of the prereq DLL's 
that were included in its zip file were pretty small, and using LZMA 
compression (as I do with NSIS2), they would likely get the bajeebus 
squeezed out of them.

> The opossum is a very sophisticated animal.  It doesn't even get up
> until 5 or 6 PM.

The opossum's timing also corresponds to when most motor vehicles are 
generally done being moved for the day, so that it can safely slip under 
them and lick road salt from them, thereby further catalyzing the 
rusting process....

Eric

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31  6:13   ` Eric McDonald
@ 2004-10-31  6:34     ` Elijah Meeks
  2004-10-31  7:34       ` Lincoln Peters
  2004-10-31 18:23       ` Eric McDonald
  0 siblings, 2 replies; 21+ messages in thread
From: Elijah Meeks @ 2004-10-31  6:34 UTC (permalink / raw)
  To: Eric McDonald, Lincoln Peters; +Cc: Xconq list

There are only two worries I'd have with this move,
both of which are posed, I acknowledge, from a
position of relative ignorance:

1.  We'll lose all the work done in SDL, right?  It
seems that ParaGUI is less work than writing
everything from scratch, so maybe this isn't too big a
deal.

2.  Forcing the average user to load a bunch of
external programs.  It took me awhile to get
comfortable with open-source software, coming from a
Win32 background.  Loading TCL/TK, in the case of
XConq, or GTK in the case of Gimp, while pretty
standard fare for a Linux user, is very intimidating
for someone used to loading a single piece of software
to run on Windows.  So if it can all be packaged as a
single install and be relatively seemless, this isn't
a big deal, but otherwise, it'll be an added hurdle
for an audience that is notable hurdle-adverse.




		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-30 23:28 SDL Interface Development Eric McDonald
  2004-10-31  4:10 ` Lincoln Peters
@ 2004-10-31  6:54 ` D. Cooper Stevenson
  2004-10-31 18:26   ` Eric McDonald
  2004-10-31 16:28 ` Skeezics Boondoggle
  2004-11-07  8:29 ` Publicity Test Run Elijah Meeks
  3 siblings, 1 reply; 21+ messages in thread
From: D. Cooper Stevenson @ 2004-10-31  6:54 UTC (permalink / raw)
  To: xconq7

On Saturday 30 October 2004 22:15, Eric McDonald wrote:

>    Today I was thinking about everything that still needs to be done on
> the SDL interface. 

There's a lot.

>
>    With the help of a powerful scrying tool known as Google, I have
> apparently discovered an easy way out: ParaGUI,
> http://www.bms-austria.com/projects/paragui/

Okay.

>    The price is twofold:
> (1) The ParaGUI API is in C++. This means that Xconq's SDL interface
> would have to be converted to C++ and things going to and from the
> kernel would have to be carefully declared extern "C". 

> (2) ParaGUI has a number of dependencies: Freetype, zlib, libpng, and
> Expat. None of these should be a problem on most modern Linux
> distributions. On Windows, these all are available, thanks in part to
> the Gimp on Win32 project and other reasons. However, any required DLL's
> would have to be bundled with the Windows installer thereby increasing
> its size, perhaps significantly. 

I think the benefits simply outweigh the size concern. I stress that we'll 
need to be disciplined about making Xconq as lean as possible to avoid 
'cruft.'

> Some of the space could probably be won 
> back once we get to a point where the Tcl/Tk interface no longer needs
> to be provided.

Right. 

[snip]

>    A while back ago, we considered SDL_Pango for handling of
> international and exotic text. Pango (which SDL_Pango obviously
> requires) is not without dependencies either. So I think point (2) is
> something worth considering. How much should Xconq be able to stand
> alone? And how much should we cave in to rapid development at the
> expense of raising the hacker "cost of entry", so to speak?

Ideally the SDL GUI builder would compile the SDL code such that only libsdl 
were required for Xconq (save libpng, etc.) If the hacker cost of entry were 
a bit high, I think that's okay if we discipline ourselves, as you outlined, 
to provide Howto documentation to facilitate them. I am willing to commit to 
writing this documentation.

>
>    One last note, I am not saying that moving to ParaGUI is without
> work. Probably a widget would have to be created to contain the main map
> and minimap. But, it looks like we get things like themes (font sets,
> background images and gradients) quite easily, and this is something we
> all wanted from/expect of the interface.

Oh, of course. Their will certainly be bumps. I think that getting some 
interfaces up that really look sharp-even if they are in development-could 
definitely attract quality developers. This irons out bugs quicker and the 
cycle repeats itself by attracting more developers.

In short, the benefits in my view seem to far outweigh any potential negatives 
so long as we are disciplined to adhering to quality quality standards while 
developing the port.


-Coop

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31  6:34     ` Elijah Meeks
@ 2004-10-31  7:34       ` Lincoln Peters
  2004-10-31 18:39         ` Eric McDonald
  2004-10-31 18:23       ` Eric McDonald
  1 sibling, 1 reply; 21+ messages in thread
From: Lincoln Peters @ 2004-10-31  7:34 UTC (permalink / raw)
  To: Elijah Meeks; +Cc: Xconq list

On Sat, 2004-10-30 at 23:13, Elijah Meeks wrote:
> 1.  We'll lose all the work done in SDL, right?  It
> seems that ParaGUI is less work than writing
> everything from scratch, so maybe this isn't too big a
> deal.

I suspect that we'll lose some of the existing work in SDL, but not all
of it.  However, what existing work we replace will probably be so
greatly improved by ParaGUI that everyone would agree that it's a good
trade-off.

> 
> 2.  Forcing the average user to load a bunch of
> external programs.  It took me awhile to get
> comfortable with open-source software, coming from a
> Win32 background.  Loading TCL/TK, in the case of
> XConq, or GTK in the case of Gimp, while pretty
> standard fare for a Linux user, is very intimidating
> for someone used to loading a single piece of software
> to run on Windows.  So if it can all be packaged as a
> single install and be relatively seemless, this isn't
> a big deal, but otherwise, it'll be an added hurdle
> for an audience that is notable hurdle-adverse.

The more I think about this, the more I think that what Windows needs is
a port of apt-get...

---
Lincoln Peters
<sampln@sbcglobal.net>

"Little prigs and three-quarter madmen may have the conceit that the laws of 
nature are constantly broken for their sakes."
-- Friedrich Nietzsche

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-30 23:28 SDL Interface Development Eric McDonald
  2004-10-31  4:10 ` Lincoln Peters
  2004-10-31  6:54 ` D. Cooper Stevenson
@ 2004-10-31 16:28 ` Skeezics Boondoggle
  2004-10-31 19:04   ` Eric McDonald
  2004-10-31 19:04   ` Lincoln Peters
  2004-11-07  8:29 ` Publicity Test Run Elijah Meeks
  3 siblings, 2 replies; 21+ messages in thread
From: Skeezics Boondoggle @ 2004-10-31 16:28 UTC (permalink / raw)
  To: xconq7

On Sat, 30 Oct 2004, Eric McDonald wrote:

[snip]
>    A while back ago, we considered SDL_Pango for handling of 
> international and exotic text. Pango (which SDL_Pango obviously 
> requires) is not without dependencies either. So I think point (2) is 
> something worth considering. How much should Xconq be able to stand 
> alone? And how much should we cave in to rapid development at the 
> expense of raising the hacker "cost of entry", so to speak?
[snip]

Just to chime in from the Solaris camp - this all sounds great, as long as
the dependent libraries are reasonably cross-platform and the build for
non-Linux/Windows machines (is that the diplomatic way to say "real Unix"  
machines? :-) doesn't become untenable.  I'd say if it's smaller/easier to
bundle those libs with the Xconq sources and build them all in one shot,
that's fine, or we'd need to make sure that the configure script can
easily find them (or be told where to find them) already installed on the
system.

Having lived through the years when "all the world's a Vax", then the
period of "all the world's a Sun" and now "all the world's the hacked up
one-off peculiar Linux box on my desk", I'm just *reeeeeally* tired of
constantly screwing around with and patching configure scripts that assume
too much.  That's my only worry with using third party libs that come with 
a mile-long dependency list...

Also, I've been remiss in building xconq from the latest CVS snapshots for
Solaris... I think something was broken the last time I tried it... oh
geez, almost a year ago!  (November 15th, 2003)  I should grab the latest
sources and see if the existing stuff still builds on Solaris before
griping about possible future changes, eh? :-)

-- Chris

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31  6:34     ` Elijah Meeks
  2004-10-31  7:34       ` Lincoln Peters
@ 2004-10-31 18:23       ` Eric McDonald
  1 sibling, 0 replies; 21+ messages in thread
From: Eric McDonald @ 2004-10-31 18:23 UTC (permalink / raw)
  To: Elijah Meeks; +Cc: Lincoln Peters, Xconq list

Elijah Meeks wrote:
> There are only two worries I'd have with this move,
> both of which are posed, I acknowledge, from a
> position of relative ignorance:
> 
> 1.  We'll lose all the work done in SDL, right?  

No, not at all.
ParaGUI works on top of SDL. I am simply proposing it to gain us some 
more leverage as far as GUI elements go. As of present, the SDL 
interface has simplistic implementations of panels and of buttons, and 
naught else. We are sorely lacking scrollable text for messages (which 
currently go to stdout), and the necessary tools to build decent setup 
and preferences screens.

This is _not_ a rewrite. It is an augmentation. Yes, there will be some 
work involved in getting the C++ interface to link with the C kernel, 
but not that much. It is essentially a matter of marking interface 
functions as having C linkage, and making sure that all of the kernel 
includes are marked that way as well.

> 2.  Forcing the average user to load a bunch of
> external programs.  It took me awhile to get
> comfortable with open-source software, coming from a
> Win32 background.  Loading TCL/TK, in the case of
> XConq, or GTK in the case of Gimp, while pretty
> standard fare for a Linux user, is very intimidating
> for someone used to loading a single piece of software
> to run on Windows.  So if it can all be packaged as a
> single install and be relatively seemless, this isn't
> a big deal, but otherwise, it'll be an added hurdle
> for an audience that is notable hurdle-adverse.

I understand the limitations of the typical Windows user. In the past, I 
have faced that group of people both as a systems administrator and as a 
software developer.

This is one of the reasons I created the Windows installer with the 
necessary DLL's bundled with it. You'll recall that, prior to the 
Windows installer, Hans only released zip archives of the Windows build 
once in a blue moon, and it was up to user to acquire and install 
Tcl/Tk. I am not anxious to return to that time.

If some deps are added as a result of using ParaGUI with the SDL 
interface, then I will include the necessary DLL's in the installer. I 
do not expect this to be a big problem. As an user of the Windows 
installer, you should not expect that life will again become more difficult.

As far as Win32 developers are concerned, I think that we can expand on 
the idea of standardized prereqs that I suggested yesterday. Not only 
can we provide the packages that are being used for Sdlconq development, 
but they can precompiled and put in a separate installers. I would 
probably target the current version of MinGW32; people using VC++ would 
still have to go about making their own .lib files if the MinGW32 ones 
proved insufficient for some reason.

Eric

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31  6:54 ` D. Cooper Stevenson
@ 2004-10-31 18:26   ` Eric McDonald
  0 siblings, 0 replies; 21+ messages in thread
From: Eric McDonald @ 2004-10-31 18:26 UTC (permalink / raw)
  To: cstevens; +Cc: xconq7

D. Cooper Stevenson wrote:

> Ideally the SDL GUI builder would compile the SDL code such that only libsdl 
> were required for Xconq (save libpng, etc.) If the hacker cost of entry were 
> a bit high, I think that's okay if we discipline ourselves, as you outlined, 
> to provide Howto documentation to facilitate them. I am willing to commit to 
> writing this documentation.

Excellent, thanks. I do not expect it to be too troublesome, since all 
the packages in question are autoconffed, IIRC. And, for MinGW32 
developers, I am willing to create installers that would drop 
precompiled libs, headers, etc... into the appropriate places in their 
existing MinGW32 hierarchy. Also, it is probably not necessary that we 
upgrade every time a new version of a prereq is released, _only for 
bugfixes which are relevant to the interface development.

> Oh, of course. Their will certainly be bumps. I think that getting some 
> interfaces up that really look sharp-even if they are in development-could 
> definitely attract quality developers. This irons out bugs quicker and the 
> cycle repeats itself by attracting more developers.

'Twould be nice if this was the spark that finally ignited the developer 
cycle.... Xconq is a fairly big project, and if you have a stack of 
papers and text files like I do, which have feature ideas and known 
bugs, it can seem like a long, weary road at times.

Eric

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31  7:34       ` Lincoln Peters
@ 2004-10-31 18:39         ` Eric McDonald
  0 siblings, 0 replies; 21+ messages in thread
From: Eric McDonald @ 2004-10-31 18:39 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Elijah Meeks, Xconq list

Lincoln Peters wrote:

> I suspect that we'll lose some of the existing work in SDL, but not all
> of it.  However, what existing work we replace will probably be so
> greatly improved by ParaGUI that everyone would agree that it's a good
> trade-off.

I'll likely reimplement buttons using a subclass of PG_Button for the 
sake of using themes, graphical effects, and better event handling.

Eric

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31 16:28 ` Skeezics Boondoggle
@ 2004-10-31 19:04   ` Eric McDonald
  2004-10-31 19:04   ` Lincoln Peters
  1 sibling, 0 replies; 21+ messages in thread
From: Eric McDonald @ 2004-10-31 19:04 UTC (permalink / raw)
  To: Skeezics Boondoggle; +Cc: xconq7

Hi Skeezics, glad to see you're still hanging around,

Skeezics Boondoggle wrote:

> Just to chime in from the Solaris camp - this all sounds great, as long as
> the dependent libraries are reasonably cross-platform and the build for
> non-Linux/Windows machines (is that the diplomatic way to say "real Unix"  
> machines? :-) doesn't become untenable.  

Yeah, I remember that you had this concern when we first started 
seriously discussing moving to the SDL interface. I did do some research 
and found an old SDL package (I think it was a Sun package, but it was 
an RPM; that was some time ago) for Slowaris 7. If you find some time, 
you might want to just see if the newer SDL sources compile on one of 
your more modern boxen.

>I'd say if it's smaller/easier to
> bundle those libs with the Xconq sources and build them all in one shot,
> that's fine, or we'd need to make sure that the configure script can
> easily find them (or be told where to find them) already installed on the
> system.

Sure, there will definitely be some 'configure.in' and 'aclocal' hacking 
to be done. No big deal. Fortunately, all (IIRC) of the packages in 
question are autoconffed, and so they can be slaved to the Xconq 
configure script if we chose to make a great, grand source tarball 
containing all of the goods....

> Having lived through the years when "all the world's a Vax", 

Reminds me of fortune adapted from Shakespeare that I once read:

All the world's a VAX,
And all the coders merely butchers;
They have their exits and their entrails;
And one int in his time plays many widths,
His sizeof being N_ bytes. At first the infant
Mewling and puking in the Regent's arms.
And then the whining schoolboy, with his Sun,
And shining morning face, creeping like slug
Unwillingly to school.
-- A Very Annoyed PDP-11

>then the
> period of "all the world's a Sun" and now "all the world's the hacked up
> one-off peculiar Linux box on my desk", I'm just *reeeeeally* tired of
> constantly screwing around with and patching configure scripts that assume
> too much.  

You should see what I had to do to Xconq's aclocal in order to find and 
use Tcl/Tk on all the various odd Debian and Cygwin configurations....

>That's my only worry with using third party libs that come with 
> a mile-long dependency list...

I worry about the same, but as long as I get feedback, I think we will 
do okay. Also, the dep list is not so long as for Gimp or Abiword. This 
one is fairly manageable, I think.

> Also, I've been remiss in building xconq from the latest CVS snapshots for
> Solaris... I think something was broken the last time I tried it... oh
> geez, almost a year ago!  (November 15th, 2003)  I should grab the latest
> sources and see if the existing stuff still builds on Solaris before
> griping about possible future changes, eh? :-)

Let me know if something is wrong.

   Regards,
     Eric

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31 16:28 ` Skeezics Boondoggle
  2004-10-31 19:04   ` Eric McDonald
@ 2004-10-31 19:04   ` Lincoln Peters
  2004-10-31 19:50     ` Skeezics Boondoggle
  1 sibling, 1 reply; 21+ messages in thread
From: Lincoln Peters @ 2004-10-31 19:04 UTC (permalink / raw)
  To: Skeezics Boondoggle; +Cc: Xconq list

On Sun, 2004-10-31 at 01:52, Skeezics Boondoggle wrote:
> Having lived through the years when "all the world's a Vax", then the
> period of "all the world's a Sun" and now "all the world's the hacked up
> one-off peculiar Linux box on my desk", I'm just *reeeeeally* tired of
> constantly screwing around with and patching configure scripts that assume
> too much.  That's my only worry with using third party libs that come with 
> a mile-long dependency list...

You should be able to run apt-get on Solaris, and use that to resolve
the dependencies.  I found a post on the Debian archives that indicates
that apt-get will compile and run on Solaris, but I don't have Solaris
so I can't vouch for it:

http://lists.debian.org/deity/1999/12/msg00080.html


Unfortunately, no amount of Googl'ing has turned up a port of apt-get
for Windows.

---
Lincoln Peters
<sampln@sbcglobal.net>

Arbitrary systems, pl.n.:
	Systems about which nothing general can be said, save "nothing
	general can be said."

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31 19:04   ` Lincoln Peters
@ 2004-10-31 19:50     ` Skeezics Boondoggle
  0 siblings, 0 replies; 21+ messages in thread
From: Skeezics Boondoggle @ 2004-10-31 19:50 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list

On Sun, 31 Oct 2004, Lincoln Peters wrote:

> You should be able to run apt-get on Solaris, and use that to resolve
> the dependencies.  I found a post on the Debian archives that indicates
> that apt-get will compile and run on Solaris, but I don't have Solaris
> so I can't vouch for it:

Well, for Solaris 2.6 and 7 I built extensive libraries of RPMs for
Solaris; I'm planning a complete Solaris 8 environment at home (since I
have a lot of older sun4d hardware that's EOL'ed after Sol8), and I've
played with 9 a bit at work, and now with 10 coming... I'm not sure if I
have the physical stamina needed to build full-blown RPM support for all
those platforms.  25 years of banging on keyboards is finally taking its
toll, and my hands ache just thinking about it.

I've used apt-get (with "Fink") on my son's Mac OS X box, and it seems
fine.  But I'm not sure I want to bother with another packaging scheme for
Solaris.  So,

	Solaris native packages are slow and horrible;
	RedHat started making RPM far too Linux-specific and annoying;
	OpenPKG seemed like a good direction, but they made a bunch of 
		stupid/annoying decisions too;
	The old "make install" route went out of vogue with SunOS4;
	I really don't need to learn Yet Another Packaging System now,
		because I'm too old/lazy/tired.

So, basically, I'm screwed. :-)  Unless I want to rely on one of the Sun
freeware sites, and they never quite do things the way I like.  Sigh.

For now, I'll just stick with RPM.  When I get a free moment I'll try a
Solaris 7 build, and report back on how that goes.

-- Chris

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Publicity Test Run
  2004-10-30 23:28 SDL Interface Development Eric McDonald
                   ` (2 preceding siblings ...)
  2004-10-31 16:28 ` Skeezics Boondoggle
@ 2004-11-07  8:29 ` Elijah Meeks
  2004-11-13 23:23   ` New Source Tarball and Windows Installer (was Re: Publicity Test Run) Eric McDonald
  2004-11-13 23:55   ` Publicity Test Run Lincoln Peters
  3 siblings, 2 replies; 21+ messages in thread
From: Elijah Meeks @ 2004-11-07  8:29 UTC (permalink / raw)
  To: xconq7

After Eric's next release, I'm going to see how much
attention I can get for XConq from a gaming
perspective.  Nothing big, no slashdotting or anything
(I agree with Coop that this should wait until 7.5),
but just a few messages on a few boards about XConq
and the various games one can play.  To that end, I
think we should tidy up the In Progress/Release list
of games that show up when you start a new game, so
that it puts the engine's best foot forward.  My
initial votes go for the Standard Game, the various
Advanced Games, my own AWLS, Opal and Star Fleet
Battles, the Civ port and Galaxy 2.  I'm not too
familiar with the rest, but I think it'd be good to
stabilize Bellum Aeternum and Wreckreation, because
these are current projects, and I would be happy to
lend a hand, if there's anything I can do.

I'd also like to set the Standard Game to default on
the Trident graphics, at least just for this release,
because it'll be a first impression kind-of-thing.  If
this is acceptable, then we'll also need to put up a
new splash screen so that new players know.

Elijah



		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

^ permalink raw reply	[flat|nested] 21+ messages in thread

* New Source Tarball and Windows Installer (was Re: Publicity Test Run)
  2004-11-07  8:29 ` Publicity Test Run Elijah Meeks
@ 2004-11-13 23:23   ` Eric McDonald
  2004-11-13 23:55   ` Publicity Test Run Lincoln Peters
  1 sibling, 0 replies; 21+ messages in thread
From: Eric McDonald @ 2004-11-13 23:23 UTC (permalink / raw)
  To: Elijah Meeks; +Cc: xconq7

Hello Xconquerors,

(Release announcement at end of this message.)

Elijah Meeks wrote:
> After Eric's next release, I'm going to see how much
> attention I can get for XConq from a gaming
> perspective.  Nothing big, no slashdotting or anything
> (I agree with Coop that this should wait until 7.5),
> but just a few messages on a few boards about XConq
> and the various games one can play. 

Go for it.

> To that end, I
> think we should tidy up the In Progress/Release list
> of games that show up when you start a new game, so
> that it puts the engine's best foot forward.  My
> initial votes go for the Standard Game, the various
> Advanced Games, my own AWLS, Opal and Star Fleet
> Battles, the Civ port and Galaxy 2.  

Sounds reasonable. Did you ever get a chance to finish the graphics 
update you were doing for the Wizards game?

>I'm not too
> familiar with the rest, but I think it'd be good to
> stabilize Bellum Aeternum 

I have meaning to take BA off the "finished" list for months now. In the 
  new prerelease that I am about to announce, that has finally been 
done. Maybe some day (some day far, far away from now), I will be able 
to sit down with BA II and release that instead. The original BA was 
simply my GDL teething experience; it was never intended to be release 
quality; the version string only indicated it was alpha or beta.

>and Wreckreation, because

Wreckreation was only a testbed. I was working on another version for a 
while that would have been a real game. I don't believe that 
Wreckreation even shows up in the "finished" games list in the Tcl/Tk 
interface.

Anyway,
Release Announcement:

A new source tarball and Windows installer is available at the usual 
location:
   http://xconq_hacker.home.comcast.net

A feature request and a bug report by "ryuuguu" have been addressed 
since the 11/10 release of the Windows installer.
Also, a new image file that I may have forgotten to include in the 
previous prerelease is now in this one. The new images are by 
"gPETERsz", a talented artist who hangs out in the Xconq.org fora.

Enjoy,
   Eric

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Publicity Test Run
  2004-11-07  8:29 ` Publicity Test Run Elijah Meeks
  2004-11-13 23:23   ` New Source Tarball and Windows Installer (was Re: Publicity Test Run) Eric McDonald
@ 2004-11-13 23:55   ` Lincoln Peters
  2004-11-14  0:54     ` Eric McDonald
  1 sibling, 1 reply; 21+ messages in thread
From: Lincoln Peters @ 2004-11-13 23:55 UTC (permalink / raw)
  To: Elijah Meeks; +Cc: Xconq list

On Fri, 2004-11-05 at 13:37, Elijah Meeks wrote:
> To that end, I
> think we should tidy up the In Progress/Release list
> of games that show up when you start a new game, so
> that it puts the engine's best foot forward.  My
> initial votes go for the Standard Game, the various
> Advanced Games, my own AWLS, Opal and Star Fleet
> Battles, the Civ port and Galaxy 2.  I'm not too
> familiar with the rest, but I think it'd be good to
> stabilize Bellum Aeternum and Wreckreation, because
> these are current projects, and I would be happy to
> lend a hand, if there's anything I can do.

Perhaps a better system for categorizing games, both by genre and
development stage, would go a long way here.  Something like this
updated version of my proposed GTK+-based "Welcome" screen (which could
be mimicked to the same effect with TclTk or ParaGUI):

http://homepage.mac.com/lmpeters/welcome2.png

---
Lincoln Peters
<sampln@sbcglobal.net>

"... an experienced, industrious, ambitious, and often quite often
picturesque liar."
		-- Mark Twain

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Publicity Test Run
  2004-11-13 23:55   ` Publicity Test Run Lincoln Peters
@ 2004-11-14  0:54     ` Eric McDonald
  2004-11-14 22:31       ` Lincoln Peters
  0 siblings, 1 reply; 21+ messages in thread
From: Eric McDonald @ 2004-11-14  0:54 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Elijah Meeks, Xconq list

Lincoln Peters wrote:

> Perhaps a better system for categorizing games, both by genre and
> development stage, would go a long way here.  Something like this
> updated version of my proposed GTK+-based "Welcome" screen (which could
> be mimicked to the same effect with TclTk or ParaGUI):
> 
> http://homepage.mac.com/lmpeters/welcome2.png

Yes. I had some very, very similar thoughts a couple of weeks ago. I had 
intended to quietly introduce such a system when I was creating the 
SDL/ParaGUI setup screens.

For the most part I agree with your storyboard. I would suggest that 
"SciFi/Fantasy" be broken up into two separate genres: "Fantasy" and 
"SciFi", and that another genre, "Miscellaneous", be added. The Insects 
game would likely fall into that category.

Also, I think that with the "Development" checkboxes, the "Show 
unfinished games" checkbox is no longer necessary. Indeed, finding a way 
to get rid of that checkbox or something similar is what led me to think 
of the classification system which you have also arrived at. I am not 
very comfortable with the word "unfinished" in the context of Xconq, 
since it does not necessarily mean incomplete development.

The historical genres might benefit from being renamed to things like 
"Stone and Bronze Age Warfare", "Iron Age Warfare", "Gunpowder Age 
Warfare", "Industrial Age Warfare", and "Modern Age Warfare". Another 
genre might be needed to cover Advances or Civ2 like games where a 
progression through multiple ages is possible.

   Just my two cents,
     Eric

P.S. The way I had previously been considering prior to this 
classification system was to break the Xconq library up into a number of 
sublibraries, and then setup navigation to the different games 
libraries. However, this creates a problem for games that may belong to 
more than one genre.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Publicity Test Run
  2004-11-14  0:54     ` Eric McDonald
@ 2004-11-14 22:31       ` Lincoln Peters
  0 siblings, 0 replies; 21+ messages in thread
From: Lincoln Peters @ 2004-11-14 22:31 UTC (permalink / raw)
  To: Eric McDonald; +Cc: Xconq list

On Sat, 2004-11-13 at 15:55, Eric McDonald wrote:
> Yes. I had some very, very similar thoughts a couple of weeks ago. I had 
> intended to quietly introduce such a system when I was creating the 
> SDL/ParaGUI setup screens.
> 
> For the most part I agree with your storyboard. I would suggest that 
> "SciFi/Fantasy" be broken up into two separate genres: "Fantasy" and 
> "SciFi", and that another genre, "Miscellaneous", be added. The Insects 
> game would likely fall into that category.

Good points.

> 
> Also, I think that with the "Development" checkboxes, the "Show 
> unfinished games" checkbox is no longer necessary. 

Agreed; after posting it I realized that the checkbox was still there
and had become redundant.

> Indeed, finding a way 
> to get rid of that checkbox or something similar is what led me to think 
> of the classification system which you have also arrived at. I am not 
> very comfortable with the word "unfinished" in the context of Xconq, 
> since it does not necessarily mean incomplete development.

For now, we could change it to something like "beta" or
"in-development".

> 
> The historical genres might benefit from being renamed to things like 
> "Stone and Bronze Age Warfare", "Iron Age Warfare", "Gunpowder Age 
> Warfare", "Industrial Age Warfare", and "Modern Age Warfare". Another 
> genre might be needed to cover Advances or Civ2 like games where a 
> progression through multiple ages is possible.

That makes more sense.

> P.S. The way I had previously been considering prior to this 
> classification system was to break the Xconq library up into a number of 
> sublibraries, and then setup navigation to the different games 
> libraries. However, this creates a problem for games that may belong to 
> more than one genre.

I can see how games that fall into multiple genres may not fit easily
into a sub-library architecture.  I could imagine that, in the system I
describe (with the changes you suggest), a game like Advances would pop
up whenever the Genre checkboxes "Stone and Bronze Age warfare" or "Iron
Age warfare" are selected.  Civ2, on the other hand, would show up if
any genre other than "SciFi", "Fantasy", or "Miscellaneous" is selected,
as long as under Development, the "Beta" checkbox is selected.

---
Lincoln Peters
<sampln@sbcglobal.net>

Why my thoughts are my own, when they are in, but when they are out they
are another's.
		 -- Susanna Martin, executed for witchcraft, 1681

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31 17:45 Re: SDL Interface Development ejessen
  2004-10-31 18:08 ` D. Cooper Stevenson
@ 2004-10-31 19:09 ` Eric McDonald
  1 sibling, 0 replies; 21+ messages in thread
From: Eric McDonald @ 2004-10-31 19:09 UTC (permalink / raw)
  To: ejessen; +Cc: Skeezics Boondoggle, xconq7

Hi Erik, it's been a while since you've been heard from,

> 1. it should be OS-independent

All of it is.

> 2. it should be included inside the Xconq build.  Otherwise, you can spend forever just trying to get
> everything to compile clean, before you can start any
> work. 

Possibly. I think that between providing installers for precompiled 
binaries for MinGW32 and providing source RPM's for Linux and other 
platforms, there may not be a need to bundle everything together. But, 
if you, Skeezics, and others would prefer a giant source tarball with 
all the dep config scripts slaved to Xconq's one configure Script to 
rule them all, I will consider it. I would still prefer to provide the 
packages separately. Among other things, it will help to foster good 
will with the developers of the various prereq software components.

> You've raised the barrier to entry so high, that
> nobody but the most fanatical will attempt to maintain
> the code.  Which means the program will die out when
> the fanatics move on.

As I mentioned in earlier postings, it is not necessary to always keep 
up with the latest and greatest. It is enough to set a standard as far 
as the prereqs go, and then adhere to that standard. Upgrades to the 
prereq packages only need to be done occasionally.

Eric

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31 18:08 ` D. Cooper Stevenson
@ 2004-10-31 18:57   ` Lincoln Peters
  0 siblings, 0 replies; 21+ messages in thread
From: Lincoln Peters @ 2004-10-31 18:57 UTC (permalink / raw)
  To: D. Cooper Stevenson; +Cc: Xconq list

On Sun, 2004-10-31 at 09:48, D. Cooper Stevenson wrote:
> On Sunday 31 October 2004 16:28, ejessen@adelphia.net wrote:
> > [not including the libraries in the build raises] the barrier to entry so 
> high, that 
> > nobody but the most fanatical will attempt to maintain
> > the code.  Which means the program will die out when
> > the fanatics move on.
> 
> Insightful. 
> 
> On Sunday 31 October 2004 08:52, Skeezics Boondoggle wrote:
> > Just to chime in from the Solaris camp - this all sounds great, as long as
> > the dependent libraries are reasonably cross-platform and the build for
> > non-Linux/Windows machines (is that the diplomatic way to say "real Unix"
> > machines? :-) doesn't become untenable.
> 
> Absolutely. 
> 
> Here's a quick 'fact check' listing the library dependancies and weather or 
> not they currently support Linux, Sun, and Windows platforms:
> 
> Libary           Linux         Mac 9        Mac OSX        Sun        Windows
> ------           -----         ------      ---------      -----      ---------
> 
> libsdl             X              X            X            X           X
> paragui            X              X            X            ?           X
> FreeType           X              X            X            X           X
> Zlib               X              ?            ?            ?           X
> libpng             X              X            X            X           X
> SDL_Image          X              X            X            X           X
> Expat              X              X            X            X           X
> OpenGL             X              X            X            X           X

zlib is available on MacOS X, although one might need to download it via
Fink (the MacOS X port of apt-get).

---
Lincoln Peters
<sampln@sbcglobal.net>

You will gain money by an immoral action.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: SDL Interface Development
  2004-10-31 17:45 Re: SDL Interface Development ejessen
@ 2004-10-31 18:08 ` D. Cooper Stevenson
  2004-10-31 18:57   ` Lincoln Peters
  2004-10-31 19:09 ` Eric McDonald
  1 sibling, 1 reply; 21+ messages in thread
From: D. Cooper Stevenson @ 2004-10-31 18:08 UTC (permalink / raw)
  To: xconq7

On Sunday 31 October 2004 16:28, ejessen@adelphia.net wrote:
> [not including the libraries in the build raises] the barrier to entry so 
high, that 
> nobody but the most fanatical will attempt to maintain
> the code.  Which means the program will die out when
> the fanatics move on.

Insightful. 

On Sunday 31 October 2004 08:52, Skeezics Boondoggle wrote:
> Just to chime in from the Solaris camp - this all sounds great, as long as
> the dependent libraries are reasonably cross-platform and the build for
> non-Linux/Windows machines (is that the diplomatic way to say "real Unix"
> machines? :-) doesn't become untenable.

Absolutely. 

Here's a quick 'fact check' listing the library dependancies and weather or 
not they currently support Linux, Sun, and Windows platforms:

Libary           Linux         Mac 9        Mac OSX        Sun        Windows
------           -----         ------      ---------      -----      ---------

libsdl             X              X            X            X           X
paragui            X              X            X            ?           X
FreeType           X              X            X            X           X
Zlib               X              ?            ?            ?           X
libpng             X              X            X            X           X
SDL_Image          X              X            X            X           X
Expat              X              X            X            X           X
OpenGL             X              X            X            X           X

I was conservative. I'm pretty confident that Zlib is supported by Sun :). 
Overall my impression is that ParaGUI is careful about cross-platform 
compatibility.

Please modify as necessary.

-Coop


^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2004-11-14  0:54 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-30 23:28 SDL Interface Development Eric McDonald
2004-10-31  4:10 ` Lincoln Peters
2004-10-31  6:13   ` Eric McDonald
2004-10-31  6:34     ` Elijah Meeks
2004-10-31  7:34       ` Lincoln Peters
2004-10-31 18:39         ` Eric McDonald
2004-10-31 18:23       ` Eric McDonald
2004-10-31  6:54 ` D. Cooper Stevenson
2004-10-31 18:26   ` Eric McDonald
2004-10-31 16:28 ` Skeezics Boondoggle
2004-10-31 19:04   ` Eric McDonald
2004-10-31 19:04   ` Lincoln Peters
2004-10-31 19:50     ` Skeezics Boondoggle
2004-11-07  8:29 ` Publicity Test Run Elijah Meeks
2004-11-13 23:23   ` New Source Tarball and Windows Installer (was Re: Publicity Test Run) Eric McDonald
2004-11-13 23:55   ` Publicity Test Run Lincoln Peters
2004-11-14  0:54     ` Eric McDonald
2004-11-14 22:31       ` Lincoln Peters
2004-10-31 17:45 Re: SDL Interface Development ejessen
2004-10-31 18:08 ` D. Cooper Stevenson
2004-10-31 18:57   ` Lincoln Peters
2004-10-31 19:09 ` Eric McDonald

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).