“Sam Lantinga” wrote:
I like SDL. I want to keep using SDL. I also think it is missing
a
feature that was present in OpenPTC: the ability to specify video
[and audio] parameters in an external config file.
Unfortunately, nobody responded to my announcement, so I don’t
know if
Sam (or any other SDL developer) likes or dislikes it.
I looked it over, and it looks pretty handy, but it seems like
something
that can be implemented outside of SDL, with a thin layer.
Excellent, thank you! Please feel free to enlighten me in this
approach, in case I don’t seem to get it in this message…
e.g. SDL_Config_InitSubSystem() can be part of your application, and
it just passes the appropriate parameters to SDL. And then you call
SDL_ConfigSetVideoMode(), SDL_ConfigOpenAudio(), etc.
I didn’t see SDL_Config_InitSubSystem as being something that should
be outside the SDL library, since the SDL_InitSubSystem is pretty
peculiar to start with and any changes to it would mean I would have
to make the same change in my implementation. (ie: video has to be
initialized before audio because of directx) Also, I didn’t see
SDL_VideoInit and SDL_AudioInit in the documentation, so I didn’t
figure we were “officially” allowed to call them from our own
programs.
In any case, the SDL 1.2 API is frozen, so something like this would
have to go into SDL 1.3
That was my original intention ( 6th paragraph of
http://mail.lokigames.com/ml/sdl/14523.html ) and any suggestions on
how to do this better (aka more SDLish) would be greatly appreciated.
For example, SDL [currently] doesn’t need to know about the whole
SDL_Config_Struct, it really only needs the flags, the audio and video
driver strings. It already handles the flags, so if it had a second
and a third optional parameters like so:
int SDL_InitSubSystem ( Uint32 flags, char * videoDriver = NULL, char
…that would also work. Not sure if optional parameters (or
overloading) are supported everywhere and I think this would break
compatibility, so that’s one of the reasons I introduced a new
function…
One of my ideas is to simplify the number of steps (lines of code)
required to get an SDL program going, so that all you’d need to code
is something like this:
SDLConfig_LoadConfig ( “sdl.ini”, &config_struct );
// add any last-minute flags to config_struct
screen = SDL_InitConfig ( config_struct );
// actual program
…
SDL_QuitConfig ( config_struct );
…and you’d have a SDL program that’s ready to process audio and
video at whatever resolution, bit depth, frequency, etc… the user
desires. Granted, this only works with resolution-independent
software and I realize that in practice, not everybody bothers with
this, but I want to write hardware-independent software and something
like this would help.
So… Have I understood what everybody has been telling me? (thanks
for your input, BTW) Would the best solution be a seperate library
that duplicates the functionality of SDL_InitSubSystem, minus the
checks for disabled subsystems? Or should I go with the "hack"
version, that is a wrapper to the SDL_InitSubsystem function that
first calls “putenv”? Option number 3 is fiddling with my current
approach to minimize code changes to the base of SDL.
Thanks!–
Olivier A. Dagenais - Software Architect and Developer