Re: SDL (was: Re: SVGALIB on Thinkpad)

[Steve Baker <sjbaker1@airmail.net>]

Gregor Mueckl wrote:

> Considering my own project I'm about to get me into the same mess. I'm
> going to depend on 7 or 8 libraries directly (i.e. I'm calling them from
> within my code). And this can be a mess for the end user. But at least
> the way UNIX shared libs are named could make things better if the
> library developer used it properly (like increasing the major version
> number of the file name if compatibiliy is broken).

But your end users still have to ask themselves:

  Do I have version A.B.C of libSDLwhatever1.so ?
  Do I have version D.E.F of libSDLwhatever2.so ?
  Do I have version G.H.I of libSDLwhatever3.so ?
 ....and then...
  I have version X+1,Y+1,Z+1 of libSDLwhatever8.so - do I
  need to get the downgrade to X.Y.Z in order to run this game ?

...taken through 7 or 8 dependant libraries (it's worse than
that because things like libSDLimage probably also depend on
libpng, libjpeg, etc, etc).

That's gonna put your end users off for sure.

What needs to happen is for all these fragmented parts of
SDL to be pulled together into one honking great package,
and released (relatively infrequently and with due care
for forward and backward compatibility) with a SINGLE
VERSION
NUMBER.

Then, your end user only has to ask "Have I upgraded SDL in
the past six months?" - and if he hasn't then it's one download
and one install.

> Loki had a foul method of preventing that (I've seen it in the Linux
> version of UT): They stuffed almost every lib they needed into the same
> directory they had the binaries in. It works that way, but it's an ugly
> waste of disk space.

Yes - not pretty.

It's something you can consider doing when you release your game on
a 600Mb CD-ROM - but for the vast majority of small games out there,
expecting users to download all of that stuff for every game they
want is going to get unpopular too.
 
> Just a question: what about sound support?

PLIB uses raw OSS - which is supported in the standard Linux
sound drivers.  Everything you need is right there.

However, I've been thinking about changing direction and
depending on OpenAL.
 
> How much does this increase binary file size?

Quite a bit - but for OpenSource code you only have to ship game
sources.

I'm not so much concerned about disk space - with drives down to
about $1 per Gigabyte, a binary size of even a couple of megabytes
isn't even worth one cent!  Looking at it another way, 3D applications
are likely to have multiple megabytes of texture maps that just
dwarf the binary bloat in the application itself.

Size in RAM is also significant. In principle (if I had chosen to
use '.so's) then multiple PLIB applications running in parallel
could share one copy of the library.  That might be important
for something like glibc - but the chances of two games being
run at the same time - both using PLIB is pretty negligable - so
this benefit doesn't seem important compared to the benefits of
stability.

> Just now I remember old
> Allegro on DJGPP. A simple Hello, World would come out as a 400kB
> executable - on good days.

Back then, that wasn't too acceptable - but I think it's less of
a problem these days.
 

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net