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

Olof Bjarnason olof.bjarnason at gmail.com
Sat Sep 17 00:39:53 PDT 2005


On 9/17/05, Olof Bjarnason <olof.bjarnason at gmail.com> wrote:
> On 9/16/05, Bob Pendleton <bob at pendleton.com> 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.
> 
> OK, I can see the implementation difficulties here. Compile time and
> install time is out of the question (at least for high-ends) as you
> argue - that leaves run time. And pushing the "try and see" code from
> the application into the library really doesn's solve the problem.
> 
> Doing all the checks at library initialization is slow and I wouldn't like it.
> 
> Here's one point: the hardware of a PC/other high-end is volatile and
> really needs to be checked at runtime - but then again the OSes (X,
> Win32 at least) do provide such query APIs, right? The hardware of a
> low-end (PDA) doesn't really change and could therefore lend more to
> the compile / install way of things.
> 
> I think what's tough is: we're trying to get to know the hardware, and
> OSes are trying to hide it from us ;)
> 
> Maybe you are right, maybe is should be a third-party library. It
> could be built up around hash-table "system configuration database"
> with a main "detection routine" run at an appropriate time, for
> example by the install wizard or by the game's "hardware detection"
> menu command:
> 
> bool SDLDetector_Init(char* databasefile); // true if successful
> void SDLDetector_Quit();
> bool SDLDetector_Detect(); // updates database, true if something
> changed since last poll, may be prohibitively slow
> char* SDLDetector_Query(char* query); // fast

#define bool int

Err.. sorry for the C++-ish API style :) 

 
> /Olof
> 
> >                Bob Pendleton
> >
> > >
> > > _______________________________________________
> > > SDL mailing list
> > > SDL at libsdl.org
> > > http://www.libsdl.org/mailman/listinfo/sdl
> > --
> > +--------------------------------------+
> > + Bob Pendleton: writer and programmer +
> > + email: Bob at Pendleton.com             +
> > + web: www.GameProgrammer.com          +
> > + www.Wise2Food.com                    +
> > + nutrient info on 7,000+ common foods +
> > +--------------------------------------+
> >
> >
> > _______________________________________________
> > SDL mailing list
> > SDL at libsdl.org
> > http://www.libsdl.org/mailman/listinfo/sdl
> >
>




More information about the SDL mailing list