[LispM-Hackers] YA graphics library, but this might be the one...

James A. Crippen james@UnLambda.COM
Wed, 4 Apr 2001 17:47:36 -0800 (AKDT)


http://www.libsdl.org

I'm just looking at this right now, haven't really read up on it yet.  
But I can say that it certainly works well with Linux, since I have a
couple of games that use it (SimCity 3K, Civ CTP).  And it's at least
portable to Windows, Linux, FreeBSD, MacOS, Solaris, IRIX, and BeOS.  
Don't know about any other ports though.  But those are pretty much our
target platforms other than bare metal on (at least) ix86.  I suppose we
could port this lib to other OS/arch combinations if necessary.

I know it doesn't require anything annoying (like DRI, OpenGL/Mesa, AGP,
etc) to work under Linux since I have a box that supports none of the
above that both games mentioned earlier run perfectly well (although
slow) on.  And it's not a pig because my little P133 seems to run with SDL
happily.

It sounds like what we really want, which is a library that provides clean
and OS/arch independent access to graphics (and sound!).  Corporations
(like Loki Software, who ports Windows games to Linux) seem to be
supporting it as well.  From looking at their applications list it seems
like all the major game platform emulators use it for their graphics and
sound abstractions.

It's LGPL'd as well, so the licensing is noninfectious.  LGPL IIRC allows
for use as a library (though not incorporating code directly, I
believe) without causing code utilizing the library to become subject to
the license.  But modifications of the library itself requires licensing
the modifications under the LGPL (or optionally under the GPL).

Hmm, license is here -- http://www.gnu.org/copyleft/lesser.html

That's for the 'Lesser' GPL and not the 'Library' GPL which is superseded
by the 'Lesser' apparently.  Not sure which the SDL uses, but I'd bet the
'Lesser'.

I'm still going to at least start work on hacking a raw Xlib (or Xtk or
Xaw, or Qt depending on pain encountered) implementation of the console
display, particularly since that would reduce the amount of overhead
involved in drawing to the screen and handling events, but I think that
for something like full-screen mode or for major portability this sounds
like a really good idea.  Maybe we can make it some sort of compile-time
option, or make a very thin and flimsy (like one funcall deep) glue
layer above it to allow switching between raw <graphics system> display
support and SDL display support.

'james

-- 
James A. Crippen <james@unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.