[SDL] SDL 1.3 and rendering API state management

[David Olofson]

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  --'