This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: SDL Interface Development
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