[SDL] Feature Query System (Was: Some multithreaded improvement to the event queue...)
olof.bjarnason at gmail.com
Sat Sep 17 00:37:22 PDT 2005
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"
bool SDLDetector_Init(char* databasefile); // true if successful
bool SDLDetector_Detect(); // updates database, true if something
changed since last poll, may be prohibitively slow
char* SDLDetector_Query(char* query); // fast
> 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
More information about the SDL