[SDL] Documentation

Albert Cahalan albert at users.sf.net
Mon Jan 24 10:04:12 PST 2005


On Mon, 2005-01-24 at 09:49 -0600, Bob Pendleton wrote:

> I have seen a lot of postings recently where people new to the list seem
> to be demanding that SDL be changed one way or another, but I haven't
> seen much in the way of contributions from those same people. OTOH,
> there are new people who contribute every day. They also complain, but
> nobody minds that because their complaints are constructive and often
> end in patches.

Here's a deal for you:

You tolerate my SDL complaints, and I'll tolerate your complaints
about Tux Paint and procps. To each their own project, OK?
We don't advance too fast if we all hack on all projects. It is
better to specialize.

The next time a complainer bothers you, please remember that he
may be working on several projects that you and your family will
greatly enjoy and/or need.

> There also seems to be a number of people who expect SDL to be
> completely up to date with the absolutely newest hardware and software
> with out making any consideration of the cost in both time and hardware
> needed to update SDL. To develop and test for 64 bit CPUs requires
> owning one.

I don't know about the sound cards and video cards, but most
CPU-related stuff is easy.

I do not have a 64-bit CPU or even a little-endian one. In spite of
this, I do a pretty good job of supporting all Linux architectures
with the procps project. The only portability error in recent memory
was (ssize_t*) vs. (int*) in a function prototype, and that's only
because I didn't bother to compile on a 64-bit box at SourceForge.
If I had done so, gcc would have provided a warning. I also use a
regression test collection to ensure that things are working well.

Hardware surfaces excluded, the same should be true for SDL.






More information about the SDL mailing list