[SDL] SDL 1.3 and rendering API state management
bob at pendleton.com
Mon Sep 4 11:55:04 PDT 2006
On Mon, 2006-09-04 at 13:59 -0400, Antonio SJ Musumeci wrote:
> 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.
I do not understand the hang up over plugins. There is no need for SDL
to ever support a plugin for any purpose. For image formats all you have
to do is write the simple code to decode an image and set up an SDL
surface structure to point at it in memory. As soon as you do that the
new surface can be used by any part of SDL that understand surfaces.
And, it can be used by any other API that understands SDL's surface
You can add all sorts of rendering APIs by simply layering them on top
of the SDL surface structure and blit operations, or you can go down to
the pixel level and do what ever you want to any SDL surface.
Frankly, I think that people are so used to having to jump through hoops
or real fire to add things to monolithic applications that they can not
imagine how easy it is to layer functionality on top of the existing SDL
The same goes for adding higher level functionality to OpenGL surfaces.
You just have to layer the functionality on using OpenGL APIs instead of
using SDL APIs.
There is no need for plugins because SDL is so open that you can just
layer what ever you want on top of SDL.
In the case where you want to support a new low level device, well SDL
has a way to do that to. It is called a driver. Write one for what ever
you want and all SDL functionality become available for that device.
> 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
> SDL mailing list
> SDL at libsdl.org
+ Bob Pendleton: writer and programmer +
+ email: Bob at Pendleton.com +
+ web: www.GameProgrammer.com +
+ www.Wise2Food.com +
+ nutrient info on 7,000+ common foods +
More information about the SDL