The need for a more unified SDL

I personally feel that the recent debate over some additions to the SDL
core has highlighted a problem the I myself, and it some other people,
have with SDL - the fact that adding certain features to your program will
add yet another depency to it. Now, I’m not suggesting anything like one
monolithic library, but simply that since SDL is fragmented (!= Bad Thing)
then maybe a more efficent method of obtaining all these extra libraries
should be created. Wouldn’t it be much better to be able to have a link on
your website to something like:
http://www.devolution.com/~slouken/SDL/download?sdl+sdl_image+sdl_mixer
etc… as opposed to all those seperate libraries. The best and quickest
way to get an SDL app from the programmer to the user is to make it easier
to get SDL itself. The main reason I’m using SDL now is because GGI was so
bloody cryptic and badly documented that anyone who just wanted to
downlaod a game and play it would get fed up and forget about it. (any
flames of list please)
Just my thoughts.

Long live the confused,
Akawaka.–
Bother! said a time-travelling Pooh as he killed his own mother.

I’ve pointed out the fact that I’d like to have certain libraries included
in SDL, but I’m not really sure thats as necessary as I used to think.

There will be dependancies… for example SDL_ttf -> freetype,
SDL_image -> libpng/zlib, etc. There are also the SDL supporting
libraries that sam didn’t write (SDL_Console, sge, libUTA, SDL_bmf,etc).
Who decides which components are important to include in this one big
package?

It’s not really a hassle on the end user if you write an installation
script that sets everything up right. Do like many commercial games do,
distribute your own version of the libraries, install them into the game
directory, build a script that sets LD_LIBRARY_PATH, then executes the
program, sets LD_LIBRARY_PATH back to it’s original value when it
completes.

You can do something similar for windows (put dll’s in the games
executable directory). (Anyone want to add details for other platforms?)–
Brian

I personally feel that the recent debate over some additions to the SDL
core has highlighted a problem the I myself, and it some other people,
have with SDL - the fact that adding certain features to your program will
add yet another depency to it. Now, I’m not suggesting anything like one
monolithic library, but simply that since SDL is fragmented (!= Bad Thing)
then maybe a more efficent method of obtaining all these extra libraries
should be created. Wouldn’t it be much better to be able to have a link on
your website to something like:
http://www.devolution.com/~slouken/SDL/download?sdl+sdl_image+sdl_mixer
etc… as opposed to all those seperate libraries. The best and quickest
way to get an SDL app from the programmer to the user is to make it easier
to get SDL itself. The main reason I’m using SDL now is because GGI was so
bloody cryptic and badly documented that anyone who just wanted to
downlaod a game and play it would get fed up and forget about it. (any
flames of list please)
Just my thoughts.

Long live the confused,
Akawaka.

Bother! said a time-travelling Pooh as he killed his own mother.

You can do something similar for windows (put dll’s in the games
executable directory). (Anyone want to add details for other platforms?)

On BeOS, you can create a lib subdirectory and stick libraries in there.

On MacOS, you can drop shared objects into the executable directory as well.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

There will be dependancies… for example SDL_ttf -> freetype,
SDL_image -> libpng/zlib, etc. There are also the SDL supporting
libraries that sam didn’t write (SDL_Console, sge, libUTA, SDL_bmf,etc).
Who decides which components are important to include in this one big
package?

Also, you can point the end-user to one place:
http://www.devolution.com/~slouken/SDL/libraries.html

I will try to keep all SDL-based libraries here, and if you know of
something that isn’t there, or should be updated, just send me an e-mail
at slouken at devolution.com and I’ll add it.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

I’ve pointed out the fact that I’d like to have certain libraries included
in SDL, but I’m not really sure thats as necessary as I used to think.

There will be dependancies… for example SDL_ttf -> freetype,
SDL_image -> libpng/zlib, etc. There are also the SDL supporting
libraries that sam didn’t write (SDL_Console, sge, libUTA, SDL_bmf,etc).
Who decides which components are important to include in this one big
package?
I not actually talking about one big archive, I’d just like to see an
easier way to downloading the packages. Anyone who ever used DJGPP may
remember the large amount of downloads required for it so DJ Delorie
created a nice web interface where you simply selected what you wanted and
it gave you the urls to the latest versions.

Long live the confused,
Akawaka.On Fri, 17 Mar 2000 hayward at slothmud.org wrote:

Bother! said Pooh, as the shuttle bay decompressed.

We ran into the same issue on the ImageMagick project which is especially
problematic when compiling for the Win32 platform. Our solution was to have
any generally required libraries in the CVS tree along with the core. We
created modules as you suggest that allow people to checkout everything they
need. The decision as to what is in the core is based on what most people
are actually using. For instance, everyone needs zlib, IJG jpeg, ttf, and a
few others, so copies of all of these are supplied. We have assigned various
members of the “team” to be responsible for keeping these parts of the tree
in sync with the “official” releases of these libraries.

We were worried that the library creators might get mad at us for doing
this, but so far so good. The big advantage of doing this is that you always
have a know working set of libraries and can phase in upgrades. People are
always free to go get the latest from the source as well.

One thing that has occurred to me is that there is a lot of synergy between
our two projects. We already have and allow checkout of all the same
libraries as the SDL projects uses. It might make sense to combine forces on
this. We could do something simple like add SDL on top of ImageMagick as
another one of our libraries.

Thoughts?> -----Original Message-----

From: Martin Donlon [SMTP:akawaka at csn.ul.ie]
Sent: Friday, March 17, 2000 7:16 AM
To: SDL Mailing List
Subject: [SDL] The need for a more unified SDL

I personally feel that the recent debate over some additions to the SDL
core has highlighted a problem the I myself, and it some other people,
have with SDL - the fact that adding certain features to your program will
add yet another depency to it. Now, I’m not suggesting anything like one
monolithic library, but simply that since SDL is fragmented (!= Bad Thing)
then maybe a more efficent method of obtaining all these extra libraries
should be created. Wouldn’t it be much better to be able to have a link on
your website to something like:
http://www.devolution.com/~slouken/SDL/download?sdl+sdl_image+sdl_mixer
etc… as opposed to all those seperate libraries. The best and quickest
way to get an SDL app from the programmer to the user is to make it easier
to get SDL itself. The main reason I’m using SDL now is because GGI was so
bloody cryptic and badly documented that anyone who just wanted to
downlaod a game and play it would get fed up and forget about it. (any
flames of list please)
Just my thoughts.

Long live the confused,
Akawaka.

Bother! said a time-travelling Pooh as he killed his own mother.

one option would be to create an installer so that if the are just after the
game, they just download one file, this may only need to be an adition to
./configure or a bat file under dos/win, not to the extent of a full
graphical installer for a ver 0.0.0.1 file !

Micahel> I personally feel that the recent debate over some additions to the SDL

core has highlighted a problem the I myself, and it some other people,
have with SDL - the fact that adding certain features to your program will
add yet another depency to it. Now, I’m not suggesting anything like one
monolithic library, but simply that since SDL is fragmented (!= Bad Thing)
then maybe a more efficent method of obtaining all these extra libraries
should be created. Wouldn’t it be much better to be able to have a link on
your website to something like:
http://www.devolution.com/~slouken/SDL/download?sdl+sdl_image+sdl_mixer
etc… as opposed to all those seperate libraries. The best and quickest
way to get an SDL app from the programmer to the user is to make it easier
to get SDL itself. The main reason I’m using SDL now is because GGI was so
bloody cryptic and badly documented that anyone who just wanted to
downlaod a game and play it would get fed up and forget about it. (any
flames of list please)
Just my thoughts.

Long live the confused,
Akawaka.

Bother! said a time-travelling Pooh as he killed his own mother.