[SDL] Feature Query System (Was: Some multithreaded improvement to the event queue...)

Antonio SJ Musumeci asm3072 at njit.edu
Fri Sep 16 16:43:55 PDT 2005

I understand that completely... however "try and see" feels really dirty 
to me. Nor does it give reasons as to why something doesnt work. I'm a 
control freak... i want to know everything thats going on. If SDL can 
take advantage of feature X... it aught to be able to tell me that 
without having to just trying to initializing that feature and failing 
or succeeding. X11 provides ways of finding out what is supported... I'd 
imagine other platforms do also.

Bob Pendleton wrote:
> On Thu, 2005-09-15 at 20:20 -0400, Steaphan Greene wrote:
>>On Thu, Sep 15, 2005 at 04:50:06PM -0400, Antonio SJ Musumeci wrote:
>>>How does offering a robust query system make it not Simple? And how does 
>>>requesting several extensions make it less portable? It's no different 
>>>than requiring other external libraries. I'd imagine it would make apps 
>>>more portable... since the programmer can accommodate accordingly to 
>>>what is available. (for compile time and run time) I would rather have 
>>>an app be able to notify me that it's unable to run or run as well 
>>>because SDL doesnt support something then run at the lowest common 
>>>denominator without warning. As I said... the OpenGL community has been 
>>>doing this for years and I dont see anyone having problems with it. I 
>>>dont think giving the developer more information is ever a bad thing. 
>>>This I think also has reverence with the conversation on sdl-config and 
>>>cross-platform building. If sdl-config was an app wrapping up much of 
>>>the queriable things which this imaginary SDL query system provides... 
>>>it would be more useful and available on systems without unix style shells.
>>Sorry, I guess I wasn't clear.  I wasn't disagreeing with you.  I was
>>actually agreeing, just cautioning against its overuse.  I just wouldn't
>>want this philosophy to create a situation where querying is REQUIRED
>>for use of certain features where a reasonable default could be
>>automatically fallen back to by SDL itself (thus making its use less
>>"Simple").  That's all.  I agree a robust, uniform query system would be
>>a Good Thing[TM] for libsdl and friends.
> I just want to make one comment. Often the amount of code needed by both
> the application and the library to do a query is just that same as
> trying to use and a feature and getting an error code if it is not
> available. In reality, that is how a lot of querying is done, try to
> initialize a feature, and if it fails, tell the programmer the feature
> isn't there. This is called "Trying and Seeing".
> The alternative to "trying and seeing" is to initialize some sort of a
> database either at run time, at compile time, or at installation time.
> The trouble with initializing the database at compile time is that the
> library most likely is not compiled on the machine it is running on so
> the information is invalid for most every other machine. The trouble
> with doing it at library installation time is that the capabilities of
> the computer change over time so the information becomes stale. This is
> also a problem for doing it at compile time. That leaves doing it at run
> time. If you check for every feature when the library is initialized you
> add a lot of start up overhead. So, you wind up doing it only when the
> programmer asks for information... which gets you back to "trying and
> seeing" which is already supported by SDL.
> The difference between SDL and OpenGL, which people are missing, is that
> OpenGL gets its info either from the hardware, or from the driver which
> is matched to the hardware. When the hardware changes, the driver
> changes, so the information is always up to date. SDL is not tied to the
> hardware or to a low level driver and so does not have access to the
> same level of information.
> SDL already supports "try and see". There is a good reason for that.
> 		Bob Pendleton
>>SDL mailing list
>>SDL at libsdl.org

More information about the SDL mailing list