I'd like some opinions on a few things I'm thinking about for the future
and want yours. =) I've been looking over the SDL headers and have been
thinking that they might help simplify our codebase even further if we
start to actually use the API as intended more. SDL supports a lot of
stuff we're not using right now, and most of it we have our own version
of. Our versions aren't always better.
My network connection is screwed, so who knows when you'll read this in
relation to me writing it. I may know a little more about some of these
things I currently don't by then. If that happens, I'll say so then.
Otherwise, grab a copy of the SDL source and feel free to chime in yea or
nay on anything that follows.
SDL_active.h
Includes a function called SDL_GetAppState. Don't know what it
does (no manpage) but it might tell us if the app is iconized or
something. Could be useful?
SDL_audio.h
We already know that SDL audio will make things more portable, but
what those of you following who are not Linux people do not know
is that SDL defaults to using things like esound on Linux if they
are running. This is a problem since esound is not direct to
hardware - it's over network connection (usually to localhost..)
This is fine for playing mp3s and system sounds, but it sucks for
3D games.
SDL_AudioInit is one of those intended-for-internal-use functions
which happens to let you specify the driver to init. You should
only do this of course if you know what driver you need. If we
can find a way to figure out what's available, we can specifically
try them in the order we want. It's the best we can do for now.
SDL_endian.h
All of this stuff looks like it can replace our LittleLong, etc
type functions. It's no more efficient certainly, it just happens
to be done by SDL for us and will save us the codespace in
common.c ..
SDL_image.h
Not part of SDL, this is SDL_image. I'm not convinced we should
use this. If we do, it'll give us support for BMP, pnm, xpm, xcf,
pcx, gif, jpg, tif, tga, and png graphics. Probably not all of
them, on all systems though. Chances are good that we can't hope
for more than gif, jpg, pcx, and png to actually work on all the
major platforms. It's also read-only support. Now maybe it's
worth using anyway, I'm not convinced. Its tga loader is better
than ours, that's for certain.
SDL_main.h
This should remove our need for a seperate sys_${OS} on the basis
of main/WinMain/WhateverAMacCallsMain functions. We really should
investigate this as it'll be one more piece of code we don't have
to try and maintain for several different OSes. I am personally
aiming to have exactly one set of files that everyone uses when
compiling, no exceptions. That means no winquake.h for win32
even.
SDL_mixer.h
This is crap. The SDL guys all know it's crap, and it's not part
of SDL proper. MAYBE it's worthwhile to try and grab the code for
impulse tracker files out of it for dynamic music. I'm not really
convinced it's even good for that, I've been told that the .it
code has a few limitations. I haven't actually looked at it to
see if it's salvagable.
SDL_net.h
Anyone want to investigate this? It's another lib that's not part
of SDL. It provides TCP/UDP in a somewhat portable fashion. It
seems simple enough, but I guess this factor alone scares people
away from the API.
SDL_rwops.h
!! typedef struct SDL_RWops ... Um, damn, no zip support. We
could fix that though, and same for pak support. This is more or
less what I was doing before in QuakeForge for the basis of a vfs.
They didn't want it then. With this, it would probably be much
easier to rewrite (I didn't keep any of my QF stuff, sorry) if we
decide to go that direction.
SDL_timer.h
Only milisecond accuracy, I think it is possible for us to get
much tighter tollerances than that on most OSes, but I don't
recall that we actually USE more than that. If we don't, then we
should consider using SDL's, one less item in sys_${OS}.c..
SDL_types.h
We should probably be using these in most places, especially those
that mess with files.
I don't know that any of this should be called release critical for our
first release, but if we go these directions, it probably should be for
our second release.
--
Joseph Carter <[EMAIL PROTECTED]> Free software developer
Steal this tagline. I did.
PGP signature
