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

Bob Pendleton bob at pendleton.com
Fri Sep 30 08:32:34 PDT 2005


On Thu, 2005-09-29 at 14:24 -0400, Antonio SJ Musumeci wrote:
> Most languages do not have preprocessors so I fail to see how just using 
>   #ifdef's is feasible. Plus, all those #def's could more easily and 
> consistently be taken care of at compile time of SDL instead of the app 
> which would use SDL. It seems to me if you wish to make the user of SDL 
> more cross platform you'd try to hide as much platform specific things 
> as reasonably possible. SDL has the infrastructure already to figure out 
> what features and what OS it's being built on... why not take advantage 
> of it. Instead of #ifdefs, one could simply have a SDL function saying 
> whether X is functional/supported and worry about specific 
> implementation later or simply ignore that functionality. Some things 
> are just a nicety... like togglefullscreen... and if i cant do it i dont 
> necessarily need to recreate it... just not offer it. and having 
> specific #ifdefs does not scale well. If all of a sudden I go and add 
> support for platform X to SDL and my SDL app doesnt get recompiled with 
> new #ifdefs... i cant use it. However something like:
> 
> SDL_bool
> SDL_WM_ToggleFullscreenSupported(void)
> {
>    #if defined X11 || BEOS || whatever
> 	return SDL_TRUE;
>    #else
> 	return SDL_FALSE;
>    #endif
> }
> 
> this works and puts the responsibility on SDL.
> 
> In an extreme case, the fact you can remove whole subsystems of SDL from 
> the library is not accommodated for. I noticed that the WinCE code has 1 
> or 2 dummy subsystems. It'd be nice to include dummy subsystems for 
> everything within reason and allow runtime checking for functional 
> systems. Then you dont need specific platforms to have dummy code like 
> that. I dont see how all these things which are already known at compile 
> time causes a query system to be large and complex. Just place a few 
> #ifdefs in the drivers for things which arent consistent. Many things in 
> SDL have queryable options. I'd just like to see it used more.
> 
> I'd like to be able to find out which driver's are compiled in instead 
> of including a list i grabbed off the wiki. I'd like to have a less 
> bootleg way of requesting a driver to be used. I'd like to see access 
> methods to parts of SDL that are currently hidden. If you put a few 
> functions in to allow getting a list of blitters available... a list of 
> function pointers and so you could benchmark them all and possibly add 
> your own at runtime. Or access to the function pointers which make up 
> the subsystem drivers so drivers could be designed and tested without 
> recompiling SDL. Loaded from a loadable module even. I'd have to look 
> more around the library since I don't use it all to come up with more... 
> but those are pretty simple to add as far as I can tell... and add tons 
> of power and possibilities to SDL.
> 
> as for the SDL_Query idea. I dont know if a completely global query 
> system or subsystem specific would be better. global would be nice 
> however it could require some major changes to the build system to 
> create the database of queryable options. Adding functions per queryable 
> item which could be generated at compile time with 
> #ifdefs/configure/hard coded per platform/driver/target would be easier 
> i'd imagine. Or it could be broken up into a hybrid system where a 
> global SDL_Query interface actually makes calls to driver specific query 
> interfaces.
> 
> Also something which I'd imagine useful.. all supported SDL platforms 
> are given an enum type which is never changing after introduction of 
> functionality. So at run time and without having to worry about this 
> stuff at compile time, one could find out the platform they are on. Also 
> include #defines to allow in languages with preprocessors to know what 
> platform they are on without having to look up each platforms potential 
> #defines. The runtime part is probably less useful but I can imagine 
> where scripting languages would possibly find it useful.
> 
> I think much of this is harmless to the API and fairly simple to 
> implement. I'd be happy to develop some of this but I dont want to go 
> and do this to then have it thrown away.

You know, the first word in SDL is "Simple". You have proposed a lot of
complication that you want added to the Simple Direct media Library. The
only thing you seem to want to be able to query is whether or not toggle
full screen works and what blitters are available. Which is all
documented and available on the wiki. That adds up to two, or maybe
three, functions that I suspect you could code pretty quickly. So, why
don't you just code that up? You can use it in your own code and maybe
even submit it as a library or as a patch.

As to your desire to add you own blitters to SDL. Feel free. You have
the code and can add anything you want. You don't need permission and
you don't need to bother us about it. Just do it. OTOH, if you actually
come up with better blitters than what are already in SDL then submit
them. I'll bet that they will be put into SDL very quickly.

I, personally, see no value in your proposals. On the other hand I see
that if they are implemented it may well cause me problems. So, of
course, I am opposed to your proposal.

	Bob Pendleton


> 
> Bob Pendleton wrote:
> > Funny thing is that SDL_WM_ToggleFullScreen is the prime example used to
> > justify the need of a query system in SDL. The thing is, it is
> > documented that it only works on one kind of system, so a simple #ifdef
> > (or the equivalent) is all that your code needs to determine if you have
> > the feature or not. Having said that, I also want to say that
> > SDL_WM_ToggleFullScreen is one of a very few features that are only
> > supported on a single platform. I, personally, would have objected to
> > adding a feature that can only be supported on a single platform. I,
> > personally, would rather see SDL_WM_ToggleFullScreen removed from SDL
> > than see a large complex query system added to SDL.
> > 
> > 
> >>I fail to see how making this personal and placing it in the realm of a 
> >>flame war is constructive.
> > 
> > 
> > It isn't constructive. But, it happens that some peoples personalities
> > go against the philosophy upon which some software is based. That is
> > just the way the universe is.
> > 
> > Rather than continue a discussion that is devolving into a flame pit why
> > don't we try something more constructive. How about someone proposing
> > what the API would look like and what kind of queries they would like to
> > make? Then we can at least talk about something meaningful and
> > measurable.
> > 
> > So, I expect that all SDL queries could be handled by something such as
> > (and excuse my lack of precision on data types, this is just an
> > example...):
> > 
> > int SDL_Query(enum SDL_FeatureName, void *extra)
> > 
> > The enum type would list all the queryable features of SDL. The function
> > would return true or false to tell you if the feature was available or
> > not. If the "extra" pointer is non-NULL then it is assumed to point to a
> > structure of the correct type to hold any extra information that you
> > would expect to get back from the query. Feel free to tell me how messed
> > up this is, but only if you offer and alternative.
> > 
> > So what features do you want to query, and how would you implement the
> > query on every platform that SDL supports?
> > 
> 
> 
> _______________________________________________
> 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 +
+--------------------------------------+





More information about the SDL mailing list