Many people thinks more that SDL is today as like a
game library
like Allegro. At the beginning SDL was made
especially for games.
So I understand the idea to create a SDL_AI lib. But
if you think
that it’s a problem with the definition, it could
also be renamed
to SAI, but I hope it would be as so easy to use.
Calling it SDL_AI would alientate, for example,
DirectX programmers, or clanlib programmers, or
_______ other library programmers, where _______ is
any sort of abstraction layer that overlaps SDL in
functionality.
But why call it SAI if it’s NOT tied in with SDL? Just call it AI.
I think it means “Simple AI” - that is, nothing to do with SDL,
really. Just a way of reducing the risk of confusion with any other
AI library projects.
That is, unless you’re actually USING the nifty features that SDL
has for libraries:
[…]
Let’s face it, there are a hell of a lot of REALLY GOOD REASONS to
use SDL as a library base.
As far as I’m concerned, SDL’s the
multimedia equivalent of stdio.h. Why reinvent the wheel? And it
would still be possible to port this library to things like clanlib
if you want.
And if it’s using SDL, I think it should be clear that it’s using
it. Nothing pisses off programmers more than finding out this nifty
new program/library requires ten billion weird dependencies that
weren’t even implied. (cough madplay cough) Calling it
SDL_AI_whatever() makes it’s use of SDL pretty clear, I believe.
I think calling libs SDL_ should be strictly reserved for
libraries that really depend on SDL for good reasons. Anything else
is just confusing, and implies that it would be futile to try and use
the lib without SDL.
For example, the Unnamed Audio Engine of Kobo Deluxe, that eventually
became Audiality, could have been called SDL_aengine or whatever.
However, it soon got support for other I/O backends (actually, OSS
audio was there before the SDL audio support!), and the next release
will probably make the SDL support optional. Having “SDL” in the name
would just be misleading.
I think an AI lib is even more likely than Audiality to eventually end
up without requiring SDL, especially since it doesn’t really seem
like an AI lib would depend on anything strictly SDL related in the
first place. (Threading, integer types, endian handling and that kind
of stuff is hardly multimedia specific, and there are plenty of other
APIs and libs for it.)
Alienation causes lack of support, lack of support
causes lack of contribution, lack of contribution for
an ambitions project such as a general purpouse AI,
even if just for games, would be fatal to the project.
I would wager that SDL is more popular and supported by many more
platforms than libraries like Clanlib and Allegro. I remember when
I released the makefiled source code for my SDL Crossfire remake -
a few days later, some guy emailed me to report my game had built
itself, installed itself, and run flawlessly under Solaris Sparc
running SunOS! Libraries don’t GET any more compatible! 
That’s a good point, and a good reason to at least support SDL, even
if your lib isn’t strictly or directly multimedia related. It is
pretty likely that your code won’t compile on some platforms if you
rely on POSIX or other Un*x related standards, or even stdint (!), so
using SDL when it’s around is an easy way of improving portability.
Obviously, it also makes a lot of sense if it’s likely that many users
of your lib will use SDL as well, which I think it the case with an
AI lib.
Also, which is easier to skip read and know the
difference of:
SDL_Something();
SDL_AI_DoSomething();
SDL_DoSomethingElse();
where the 4th character is almost allways varying, and
we have to check if it’s A…
You are assuming it would be used with SDL. Under libraries like
Clanlib and Allegro, we would want it to be clear that it’s using
SDL functions and features.
Why? The next release might support stdint and POSIX stuff as an
alternative to SDL, and then it would just be confusing to have "SDL"
in the name and/or symbols…
SDL_Something();
SAI_DoSomething();
SDL_DoSomethingElse();
where the 2nd character only varies when using
different libraries, and it’s either A or D?
It is easier to type, but very very vague. I can just imagine
myself writing code with it, then rereading my own code years
later. “SAI… …SAI? Simple Audio Interface? Streaming
Arithmetic Instruction? See Apes and Immolate?” 
Doesn’t that apply to SDL or any other TLAs as well…? 
Calling it SDL_AI imposes readibility strain, extra
typing, and alienates non SDL users.
I don’t think typing three extra keystrokes will damage my poor
left pinky very much, nor do I think it’s difficult to read - quite
the opposite, the name tells more about what it is.
There is
nothing stopping anyone from porting it to Clanlib or Allegro
either, if they want to.
Except that you’ll have to do some silly search’n’replace in both the
lib and applications for no real reason…
I used to think APIs were supposed to abstract lower levels and
internals away, but I could be wrong. 
Even if it were media, AI would deserve it’s own entire library.
I’m afraid I don’t follow you. Using SDL would make this library
MORE portable, not less; Why retread ground that’s been tread
before, code functions that’ve been coded before, fight bugs
that’ve been fixed before, and cross-compile to platforms that’ve
been ported to before? “Compatibility?”
Good point, but it has nothing to do with the AI lib’s name or symbol
naming conventions…
You don’t don’t have to call all games using SDL SDL_, do
you? Why should that apply to libs - especially when they have no
strong reason to depend specifically on SDL and only SDL?
You’d wind up making a library 10 times larger, twice as ugly, and
considerably LESS portable and stable than if you’d just used SDL.
Uhm, I think an AI lib would need like one or two pages of “#define
spaghetti” to cover what it needs that isn’t ANSI/ISO C… That’s the
case with EEL (the scripting engine of Audiality), and I think that’s
pretty similar to an AI engine in this regard. It should be
possible to do entirely in ANSI/ISO C, but then you’d have trouble
with stdarg, signal handling, file path manipulation and some other
stuff that tends to differ slightly across platforms.
“Use the control panel, Luke. Advanced microelectronics designed
for hitting teeny tiny targets. That’s what it’s THERE for.” 
…but he did just fine using the… uh, source, right? 
Which is actually a rather close to what I’m getting at, I think.
SDL is a source matter; not an interface matter, seen from the POV of
a library. You’re supposed to use SDL - not tell the world about
it, enforcing funny naming conventions upon applications that don’t
really care how you get the job done. Leave that to marketting, if
you want to flash that nice new SDL logo. 
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Saturday 14 February 2004 19.42, Tyler Montbriand wrote:
On Saturday 14 February 2004 00:26, Michael Rickert wrote: