[SDL] SDL 1.3 status ?

Mason Wheeler masonwheeler at yahoo.com
Thu Jul 28 06:22:58 PDT 2011

Please, no.  The last thing I want is to make the SDL DLL Hell even worse!  I like my deployments to be as clean as possible, and to be frank, SDL is the major thing standing in the way of that goal.  Right now my installer consists of the EXE, a few data files, and the support DLLs:

5 DLLs required to support the database

2 DLLs required to support SDL_Image (Would be more, except I made a design decision to only support PNG images)

5 DLLs required to support SDL_Mixer (there are a lot more libraries involved, but those a the ones I couldn't get to statically link into SDL_Mixer for various reasons.)
2 different C runtimes to support all the other dependencies

Ideally, I'd like to be able to deploy one single "SDL.dll" that handles all multimedia needs.  That would clear up *so* many headaches for me.  But in the absence of that, can we please at least not make it any worse?

From: Tim Angus <tim at ngus.net>
Subject: Re: [SDL] SDL 1.3 status ?

On 28/07/2011 12:09, Torsten Giebl wrote:
> since the SDL 1.2 days, Alpha Blending, Rotation, Zooming, and Flipping
> X/Y ( all if possible HW accelerated ! )
> Features that every old 16 bit console like Genesis, SNES, ... had.

If there is really that much demand for this sort of thing I think it may make sense to separate the renderer part of SDL off into its own tertiary library in the same way that e.g. SDL_image is done. This could have its own developers which care about this use case who would be free to extend it without impingeing on the basic functionality. Sticking this kind of stuff into the core of SDL feels like feature creep to me.
SDL mailing list
SDL at lists.libsdl.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110728/e32b57e6/attachment-0008.htm>

More information about the SDL mailing list