[SDL] IMGUI tutorial

Jari Komppa jari.komppa at gmail.com
Mon Sep 25 23:13:51 PDT 2006

Bob Pendleton wrote:
> 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
> structure. 
> 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. 
No, as soon as you want to hardware accelerate the new functionality, 
you have to have a least some hook to the internals.
Say, for example the hardware exposes a rotation function that goes 
unused by the current SDL code. If you don't want rotation support in 
SDL itself, but in an external library, you have to do it in software. 
That's because SDL doesn't expose the hardware's rotation function.

On the other hand, if you have access to internal hooks through some 
plugin interface, you're now able to provide hardware acceleration for 
the new functionality. And really, you don't want things like 
rotation/scaling without acceleration, because they'd be pretty useless 


More information about the SDL mailing list