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.
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?