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

[Gregor Mueckl <GregorMueckl@gmx.de>]

Steve Baker wrote:

> Gregor Mueckl wrote:
> 
>>Steve Baker wrote:
>> >
>>
>>>There are some significant problems with SDL
>>>
>>Just a little, but serious question: what are your problems with using
>>SDL? I can't see any myself, so I'd like to hear your oppinion on it.
>>And before I forget: I haven't had a thorough look at PLIB yet as I
>>expect you mentioning that library in your answer.
>>
> 
> I havn't used the library as an application developer - so I can't
> comment on the API - my biggest complaint is that it's that as an
> end-user, the release strategy is utterly hopeless.
> 
> SDL comes in a gazillion little parts - all with different
> version numbers - all needing to be installed separately - many
> parts having poor forwards and backwards compatibility between
> versions.
> 


I've not been so much an end user as a developer using SDL. So this 
point here actually is quite interesting. As far as those "little parts" 
are concerned: SDL itself actually contains a fair amount of 
functionality (with that I mean the *real* SDL library libSDL.so). The 
rest are helpers and wrappers like SDL_mixer (a mixer for audio in 
different formats) or SDL_image (a set of image loaders for common 
formats). SDL is pretty complete without them (i.e. they are not vital), 
but it's convenient to use them. And for the purpose of porting existing
games these functions were probably considered pretty useless as they 
were probably already implemented in the Windows version of the games 
(if you recall, SDL can be seen as a Loki product).

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


> Hence, *every* time I download a game that needs SDL, I'm
> forever having to track down and download more fiddly little
> SDL components - then finding that they depend on more recent
> versions of other components.  I upgrade those - and then other
> games break.
> 


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.


> It's very frustrating.
> 


Indeed.


> By contrast, my own PLIB package comes all in one installable
> bundle - it's all updated at the same time and changes version
> number relatively rarely.  It has no external dependancies beyond
> X and OpenGL and it *always* installs to the same place.
> 


Just a question: what about sound support?


> Since applications link statically to PLIB '.a' files, you
> cannot possibly destroy a working binary by installing a
> new PLIB.
> 


How much does this increase binary file size? Just now I remember old
Allegro on DJGPP. A simple Hello, World would come out as a 400kB
executable - on good days.


> For the end-user of games, that's a much simpler proposition.
> 


Yes, it is.


> In surveys on several end-user gaming sites (such as HappyPenguin),
> the number one problem with gaming under Linux is the hassle
> of getting a program (and all it's dependent libraries) to install.
> Hence, the number one goal of games designers should be to make
> that entire process as simple as possible.  SDL comes *FAR* from
> that goal.
> 


Many Linux programs suck when it comes to compiling/installing them. 

But I can't even blame that on the developers of the programs. There's

something badly wrong with binary compatibility in Linux (which I don't
care about very much personally). I blame it on the library developers
who manage to produce incompatible, yet for the system indistinguisable
libary versions and effectivly thrash the versioning mechanism thought
to prevent that.


Bye,
Gregor

-- 
*****************************************************
* Gregor Mueckl                 GregorMueckl@gmx.de *
*                                                   *
* The ChallengeOS project:                          *
* http://challengeos.sourceforge.net                *
*****************************************************
* Math problems?                                    *
* Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].       *
*****************************************************