[SDL] Re: Some multithreaded improvement to the event queue...

Antonio SJ Musumeci asm3072 at njit.edu
Thu Sep 15 09:05:34 PDT 2005

While I agree that compatibility is important... it shouldnt keep from 
improving the library as a whole. My biggest problem with SDL is it's 
general lack of a feature query system. It would seem to me the most 
compatible and maintainable way of dealing with many platforms would be 
like OpenGL does. Certain features are globally available... but 
everything else needs to be checked at runtime. I find it safer and 
easier to work with. If SDL supports not including certain subsystems... 
why must we wait till link time to find that out? Have dummy functions 
and a way to see if it exists. Why must things like video and audio 
drivers not be settable but by environmental variables? Why cant we find 
out what are available? If the Windows blitter doesnt use assembly 
optimized code... or support hardware surfaces... I'd like to know this 
at runtime. Or clock resolution. Anything not consistent platform to 
platform. It seems many of the questions this mailing list gets could be 
answered if there was was a feature querying system. Maybe not the why 
feature X isnt supported but at least the fact that it isnt is not 
hidden. I really hope that when and if SDL2 happens... we can include 
such a system.

Bob Pendleton wrote:
> On Wed, 2005-09-14 at 23:54 +0100, Brian Barrett wrote:
>>        "If you had read any of the stuff I pointed you at you would
>>        know that I
>>        already made all those points 3 years ago. In a discussion
>>        with Sam less 
>>        than 6 months ago he was still uneasy about putting this into
>>        SDL."
>>maybe i might be sounding a little democratic here, i apologise for
>>that, but can't the users (SDL Developers ) have some kind of vote or
>>something as to whether it is or isn't a Bug or whether it should be
>>not taking away from Sam Lantiniga and the library...
> Here I have to go along with Sam 100%. Software development is not a
> democratic process. There have to be people who are concerned about the
> overall architecture and design of the library. Those people, Sam, and
> the other long time developers, know why things are done the way they
> are and they know what has to be done to maintain compatibility. They
> have the big view. Even I, with my huge ego and vast knowledge :-) have
> to admit that I do not know the complete story and must accept the
> decisions of those who do. 
> OTOH, if a lot of people jump in and say they want the feature, then it
> will get more weight than if it is just you and I. The fact is that very
> few people seem to need it, and those that do need seem to be happy to
> use my library. But, if it breaks SDL on a widely used platform, there
> is good reason not to add it in.
> I am hoping we can get this into SDL 2.0 even if we can't get it into a
> current version of SDL.
> I hope you understand that I have no authority one way or the other over
> SDL.
> 		Bob Pendleton
>>SDL mailing list
>>SDL at libsdl.org

More information about the SDL mailing list