[SDL] SDL 1.3 and rendering API state management

Antonio SJ Musumeci asm3072 at njit.edu
Mon Sep 4 10:59:23 PDT 2006

 From my experience with plugin APIs... it's the abstraction which is 
hardest. Making sure you accommodate for everything and provide the 
right hooks. SDL already does this. It just isn't dynamic. "Simple" 
should be to use and maintain... not necessarily to create. Once the 
core is done... all the components are completely independent from that 
core. No creeping interdependencies. No need to worry about the whole of 
the library to modify one section. No needing to wait for bugfixes in 
some relatively minor section of the code because it's not enough to 
warrant a full release. For packagers you no longer need to have several 
versions of SDL depending on what backends it supports. If I don't want 
ARTS or ESD I don't need them. If i don't want XPM or TIFF i don't need 
to have them. If the API for a library changes you can just release a 
plugin for that updated version.

Given SDL's purpose and use... it seems odd that it wouldn't be designed 
to be as flexible, consistent, open, and easily expandable as possible.

David Olofson wrote:
> On Monday 04 September 2006 17:25, Antonio SJ Musumeci wrote:
>> I don't see why this is a bad idea. API's like GStreamer and
>> gdk-pixbuf provide flexible plugin interfaces so the core library
>> doesn't need to change when someone wants to add some random format.
>> Why must SDL be monolithic and inflexible?
> Well, unfortunately, plugin APIs are about as hard to design as they 
> are powerful. I've been somewhat involved in the design of a few 
> plugin APIs (audio), and in short, my experience is that designing 
> one that actually works is h*ll of a lot harder than you'd think 
> first time you look at some plugin SDK.
> Just for starters, you need some type of subsystem to manage plugins. 
> (Register, query, instantiate, destroy.) Though this doesn't have to 
> be rocket science, it's still a bunch of functions and data 
> structures that simply don't exist in as the "SDL style" layered 
> design.
>> I'd think it'd make package management a whole lot easier too. It
>> can always be done in a way so that they can be external modules or
>> built in to the library. I'd think it'd need that anyway.
> I'm not sure exactly what it would simplify, but I have done enough of 
> it to see what it complicates. ;-)
> That said, "need" is a relative thing. Are image loading plugins 
> important enough to warrant designing and implementing the API and 
> host side in SDL?
> As of now, we have the BMP loader in the SDL core, and then we have 
> SDL_image, and... well, that's it, I think. Basically, if you need to 
> load images, you pull in SDL_image, or you hack your own custom 
> loader. Or, if you just need a few images, SDL_LoadBMP() might be 
> sufficient.
> Of course, a plugin system with a single image loading API over it 
> does sound nice from the aesthetic POV - but frankly, does it really 
> add anything useful?
> If you *really* want a plugin based image loading subsystem for your 
> applications, you can always implement that as an add-on library, 
> that comes with a bunch of plugins that wrap SDL_LoadBMP() and 
> SDL_image. You could even implement it as a snap-in replacement for 
> SDL_image.
> Oh, BTW, unless you're linking statically, the SDL_image lib already 
> *is* a plugin of sorts! If you want to "force" some alien image 
> format upon a closed source application (which is one of very few 
> valid reasons to have a plugin system at all!) you can just throw in 
> a hacked version of SDL_image that supports this image format.
> //David Olofson - Programmer, Composer, Open Source Advocate
> .-------  http://olofson.net - Games, SDL examples  -------.
> |        http://zeespace.net - 2.5D rendering engine       |
> |       http://audiality.org - Music/audio engine          |
> |     http://eel.olofson.net - Real time scripting         |
> '--  http://www.reologica.se - Rheology instrumentation  --'
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl

More information about the SDL mailing list