[SDL] Re: update/H2

Daniel Heck dheck at gmx.de
Fri Aug 27 16:47:14 PDT 1999


> > SDL seems to aim for two different levels at the same
> > time: the base API providing system services in a
> > portable way (LFB, sound device, soon OpenGL), and
> > a GLUT-like toolkit (with all the familiar struggles
> > for control).
> >
> > Lessons I learned from OpenGL:
> >   always maintain data export/import separately
> >   never enforce data structures at API level

That's a really good point and one of SDL's current misconceptions:
Using data structures for exchanging information between an application
and the library may not be inherently bad, but I had quite a few
struggles with SDL because it wasn't clear to me, whether some data
fields had to be filled in by the application or would be calculated by
the library (Sound conversion comes to mind).  Furthermore, I still
don't know if SDL_BlitSurface() changes some entries in the source or
destination rectangle.  Sure, you can always look at the source and all
this could be amended by more detailed documentation, but I'd rather
have a few more entrypoints to the library than to hassle with obscure
data structures.

> >   use primitive types and pointers exclusively
> >   make context current without using a handle at API level

Yup, that's probably the way to go.

> > The more convenient SDL is as a toolkit for aspiring
> > game coders starting from scratch, the less suitable
> > it will be as a toolbox to retrofit an existing
> > application.
> >
> > Maybe that is what Michael and Karl were bitching about
> > recently (not that they ever volunteered specifics, ahem).
> > The probable solution is a two-part API, much like
> > GL vs. GLUT - the low level SDL providing the services,
> > the high level SDL offering the GLUT-like toolkit.

I can only second this proposal.

SDL currently consists of a solid core that provides the low level
services, and a half-heartedly implemented "high level" library,
performing such things as loading WAVs and BMPs.

I'd really prefer a rock-stable, stripped down low level SDL with a
powerful and flexible high level API built on top of the core
functionality and including things like loading sound/graphics data in
various formats, playing videos, converting between sound and video
formats etc.

It might also be a good idea to move the event queueing to the high
level library. Both Glut and SVGALIB a queue by enabling the programmer
to define event handlers that are called, say, whenever the mouse is
moved.  ll SDL could poll the mouse/keyboard/... and call the
appropriate functions whenever needed.  (This would also solve my
longstanding problems with X's lagged mouse movement events.. Uh, I
know, I'm getting on your nerves, but this one still bugs me :)

> I can use the existing SMPEG source for Civ, and you can fork the source
> into a development tree to test out ideas.

What about a public fork? I'd gladly help out with some code and ideas. 
I have some basic knowledge about X and svgalib, I'm a proficient C and
C++ coder, I'm quickly covering ground in terms of game programming AND
my semester doesn't start before October, so I have some time for
hacking on a game library :)

> I'm CC'ing the SDL mailing list because there may be other people with
> good insight. :)


More information about the SDL mailing list