Wed, 13 Dec 2000 Mattias Engdeg?rd wrote:
And I’ve finally added API calls to list the available audio and
video drivers, along with a test program ‘listdrivers’ that will
show you the drivers available to SDL. Note that these functions
return the drivers that will actually be used in initialization,
not just the ones that are compiled in.
Please don’t cast that API in stone. There are reasons to prefer a
more flexible interface. The form (FirstVideoDriver, NextVideoDriver)
isn’t very nice since it maintains a hidden state.
Not if NextVideoDriver() does what many OSes have done before; takes a pointer
to your current object as an argument. Optionally, one could entirely eliminate
the FirstVideoDriver() call by using NextVideoDriver(NULL) instead.
Better solutions
would be to provide a callback enumeration on the form
EnumerateVideoDriver(void (*f)(something *, void *), void *)
I think callbacks are hacks in most cases… They are indeed nice where they’re
needed, but this doesn’t look like such a case.
or even simpler, just return a vector of the drivers to the user.
This is kinda’ nice though. However, it may appear less nice when considering
that an array cannot be dynamically resized. (OTOH, would that ever be needed?)
Another problem is that elements in a vector must be of fixed size, which means
that SDL cannot strap private things onto these device structs without breaking
the API on the binary level.
An array of pointers would be nice, though, but
if it’s a copy/“special thing” that’s generated by the SDL call, someone has to
delete the array as well.
Also, you need to know the size of the array…
Still, I think I’ve seen a few APIs use these kind of methods. It’s nice when
there are many objects, and applications may benefit from other traversing
orders than node by node, start->end. It’s also nice if speed is very
important. Other than that, it’s just messy, IMHO.
Orthogonally it would be nice to get driver capabilities, not just a
string (which is only good for user choices). A game would pick a driver
with the capabilities it needs, or offer hints to the user for driver
choice.
Yes, definitely! Preferably, most games should be able to figure out a
reasonable default choice at run time, rather than always asking the user.
Example:
SDL_DriverInfo **SDL_GetVideoDriverList(int kind)
returning a vector of pointers to structs
struct SDL_VideoDriverInfo {
char *name, *description;
int version;
SDL_VideoInfo *vinfo;
};
perhaps augmented with more information. Care should be taken to arrange
the structs in a way so that we can add capabilites without breaking
binary compatibility
Yep, and that’s where the usual node = GetFirst(); node = GetNext(node);
construct comes in handy. It would probably be nice to throw in a version code
in the struct as well, so that newer applications could potentially work with
older SDL libs, adapting at run time… (Not sure if that’s really useful here,
but it’s usually a good ide.)
//David
…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’
