Sdl 2.0

The next version of SDL has been mentioned in passing in quite a number of
emails, and though the current version of SDL is quite capable, I believe
it is getting behind the times.

I started using SDL years ago to create a cross-platform game. It worked
well, though it was slow on linux, my development platform. It had no gui,
but that wasn’t a problem: I wrote my own. Then the trouble started.

I wrote a map/character editor for my game, and shared it with some
friends. The big complaint was that they couldn’t get windows “out” of the
editor. They used external programs (gimp, photoshop, ect) to edit the
media, and wanted to be able to see windows from both applications at once.
I soon found that this was not possible, and was NOT planned, even in the
next release. I moved ahead, cleaning my code, and extending it. I wrote
my own PNG loader since the SDL_image library did not handle alpha
correctly at the time, and then I had to change it to be aware of the
version of SDL because SDL’s idea of ALPHA changed(breaking older
programs).

I had to speed the client up for Linux, so I wrapped the SDL drawing calls
I needed (Just screen setup, image blitting, and sold rectangle blitting)
and implemented them in OpenGL.

I then started working on the server, which needed some multi-threading
support. This was originally written in C on Solaris and openVMS, and I
didn’t want to have a full SDL library working on those platforms, so I
re-wrapped the native calls.

About three months ago, I needed full-duplex audio. SDL does not support
it, and when I checked the email logs there have been patches for it. I
tried one, had some troubles, and instead used some code my friend had for
full-duplex audio on windows. I wrote my own full duplex OSS code for
linux and solaris. I was surprised to see that none of the full-duplex
audio code was even being considered for addition to SDL 1.2.

Recently, I have seen that mutli-window support might be in SDL 2.0. After
looking at the libsdl.org website, I can find nothing solid on this new
SDL.

At this point, I really need to know:

  1. If we make enhancements to the current SDL, are they going to be
    accepted (Such as full-duplex audio)?
  2. Is someone working on SDL 2.0? Is there a feature list and mock-api
    documented? When is this planned? Can we help?
  3. Should I change my code to use OpenGL exclusively and remove all SDL
    code, or wait for SDL 2.0?

I have run into problems with my own audio and OpenGL code, and have only
been able to test on a small number of platforms. I love the openness and
stability of SDL, but find it just doesn’t do the job anymore. I would
love to contribute to a new SDL… if only there was one. I would start a
fork, but I want to write a game, not a game library.

Please don’t take offense to this email. I know that SDL is not a
commercial library, and development is done as time permits, but I think
the community needs a new SDL. If you are unwilling to accept patches that
provide major features (and don’t affect compatibility, such as duplex
audio), and are unwilling to start an SDL 2.0 fork, you will be losing more
developers than just myself.

James Best

Please don’t take offense to this email. I know that SDL is not a
commercial library, and development is done as time permits, but I think
the community needs a new SDL. If you are unwilling to accept patches that
provide major features (and don’t affect compatibility, such as duplex
audio), and are unwilling to start an SDL 2.0 fork, you will be losing more
developers than just myself.

Follow up on your patches. I see many patches integrated. It seems
sometimes they just need a little cleaning up before they make it in.

I’m sure multi window support could be added. But I hear it breaks
backwards compatibility. Maybe it could be added in such a way that it
is optional. So that those who need it don’t have to wait for when sdl2
is done.

Have you checked out glSDL? I hear it is working ok now for some games.

Have fun!

Please don’t take offense to this email. I know that SDL is not a
commercial library, and development is done as time permits, but I
think the community needs a new SDL. If you are unwilling to
accept patches that provide major features (and don’t affect
compatibility, such as duplex audio), and are unwilling to start
an SDL 2.0 fork, you will be losing more developers than just
myself.

Follow up on your patches. I see many patches integrated. It
seems sometimes they just need a little cleaning up before they
make it in.

I’m sure multi window support could be added. But I hear it breaks
backwards compatibility.

Yeah - and that’s the problem with most of these patches, AFAIK. They
either unavoidably breaks compatibility (have to add function calls,
for example), and the hacks to avoid that are just too ugly.

Maybe it could be added in such a way
that it is optional. So that those who need it don’t have to wait
for when sdl2 is done.

I think one or two new function calls would be needed, so applications
compiled for the new version wouldn’t load with older SDL libs. Doing
it without messing up the whole API (ie adding explicit window
handles) is quite possible, but it’s not easilly done in a thread
safe manner (as in one thread per window), and it’s pretty hard to
avoid adding a window ID field to te event struct.

Have you checked out glSDL? I hear it is working ok now for some
games.

It is - and the backend version is getting along fine as well, though
it does trigger sleeping bugs (incorrect assumptions) in games every
now and then. Dunno when we have something ready for release, though;
I haven’t been very active myself lately. Debian style release date,
of course. :wink:

Anyway, maybe we’re approaching a critical mass of feature requests
and patches that need API extensions? (I’ve lost count of the
requests, and I haven’t kept track of which ones are backed by
working patches.) Maybe it’s worth considering another major release
before 2.0?

Though I do see the problem with that: This would have to be put
together and maintained by someone, obviously - and I think we’re
better off if the SDL team keeps working on 2.0 instead.

However, if someone’s willing to maintain and support it, there’s
always the option of putting together a “cutting edge SDL”. Basically
a distro (source, binaries etc) with all those patches applied.

Dunno what Sam and co think about this, but it would keep the stuff
away from the official source tree, while still making it available
to developers and users.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Saturday 06 September 2003 03.54, Rene Dudfield wrote:

On which platforms does adding function calls break binary compatibility?On Sat, Sep 06, 2003 at 09:44:19AM +0200, David Olofson wrote:

Yeah - and that’s the problem with most of these patches, AFAIK. They
either unavoidably breaks compatibility (have to add function calls,
for example), and the hacks to avoid that are just too ugly.


Glenn Maynard

Right; that was probably incorrect or at least unclear wording.

What I meant was that if you add function calls and some applications
use them, those applications will get a new absolute minimum SDL
version requriment (won’t load with previous versions) - and
normally, that means the new version number should be x.(y+1).0,
rather than x.y.(z+1).

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Saturday 06 September 2003 09.59, Glenn Maynard wrote:

On Sat, Sep 06, 2003 at 09:44:19AM +0200, David Olofson wrote:

Yeah - and that’s the problem with most of these patches, AFAIK.
They either unavoidably breaks compatibility (have to add
function calls, for example), and the hacks to avoid that are
just too ugly.

On which platforms does adding function calls break binary
compatibility?

Oh, BTW, it can on Win16 and Win32 (dunno about Win64), if you use
that dreaded “find calls by index” stuff. :wink:

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Saturday 06 September 2003 09.59, Glenn Maynard wrote:

On Sat, Sep 06, 2003 at 09:44:19AM +0200, David Olofson wrote:

Yeah - and that’s the problem with most of these patches, AFAIK.
They either unavoidably breaks compatibility (have to add
function calls, for example), and the hacks to avoid that are
just too ugly.

On which platforms does adding function calls break binary
compatibility?

What I meant was that if you add function calls and some applications
use them, those applications will get a new absolute minimum SDL
version requriment (won’t load with previous versions) - and
normally, that means the new version number should be x.(y+1).0,
rather than x.y.(z+1).

1.2.6 adds “SDL_LoadObject(), SDL_LoadFunction(), and SDL_UnloadObject()”.
Apparently this isn’t being used as criteria for a new minor (y) version
number.

More generally, you get a new minimum version requirement if you require
any new feature that didn’t exist before. If it’s a new function, the
program won’t load with old DLLs, but it’s just as fatal in other cases.
For example–picking something out of the change log:

 * 1.2.5: Added a way to get the Windows OpenGL context in SDL_syswm.h

This looks like SDL_SysWMinfo::hglrc. If you use that for something
important, then you have a new absolute minimum SDL version requirement
of 1.2.5. That’s no different from adding a new function.

Aside: Actually, unless I’m missing something, it looks like this wasn’t
even a binary compatible change: it increased the size of SDL_SysWMinfo,
so a program compiled with SDL 1.2.4 running 1.2.5 might not work. (I
don’t know if padding makes this not an issue in practice, if there was
a placeholder padding variable there before, etc. Apparently nobody’s
complained. Windows projects using SDL tend to package their own SDL
DLL, too, so it’s less likely that a program will be used with a
different version than it was compiled with.)

Oh, BTW, it can on Win16 and Win32 (dunno about Win64), if you use
that dreaded “find calls by index” stuff. :wink:

Ew. :)On Sat, Sep 06, 2003 at 10:16:15AM +0200, David Olofson wrote:


Glenn Maynard

[…]

1.2.6 adds “SDL_LoadObject(), SDL_LoadFunction(), and
SDL_UnloadObject()”. Apparently this isn’t being used as criteria
for a new minor (y) version number.
[…other examples…]

Yeah, I’ve noticed that… I might be confusing things with some
comment about trying to avoid adding new calls between micro
versions. (Not an absolute requirement, that is.)

Here’s what configure.in says:

Making releases:

Edit include/SDL/SDL_version.h and change the version, then:

SDL_MICRO_VERSION += 1;

SDL_INTERFACE_AGE += 1;

SDL_BINARY_AGE += 1;

if any functions have been added, set SDL_INTERFACE_AGE to 0.

if backwards compatibility has been broken,

set SDL_BINARY_AGE and SDL_INTERFACE_AGE to 0.

SDL_INTERFACE_AGE and SDL_BINARY_AGE are used to manage
application/lib compatibility on systems that support it.

For example, on Linux, SDL 1.2.6 is named libSDL-1.2.so.0.0.6, where
the “1.2” is part of the lib name, rather than the library version.
(So it can’t be confused with any 1.1 libs, for example.) The last
three numbers are what are used by the object loader to find a lib
that’s compatible with the requested version.

Either way, it’s not for us to decide what goes in, nor what it does
to the version numbers. :wink:

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Saturday 06 September 2003 11.02, Glenn Maynard wrote:

For example, on Linux, SDL 1.2.6 is named libSDL-1.2.so.0.0.6, where
the “1.2” is part of the lib name, rather than the library version.

Right, so if backwards compatibility is broken (this library won’t work
with binaries compiled for older versions), it becomes a different
library name–but none of what we’ve mentioned breaks backwards
compatibility at all, only forwards compatibility.

(Libtool’s versioning is insanely hideous, by the way. It should be
sufficient to name the library “libSDL.so.1.2.6”, with a soname of
"libSDL.so.1.2". I don’t know why libtool does it that way. If anyone
has any hints, I’d be interested in hearing them off-list.)

Either way, it’s not for us to decide what goes in, nor what it does
to the version numbers. :wink:

It’s vital that we know what Sam’s policy is, however, since it directly
affects which patches we’ll bother submitting.On Sat, Sep 06, 2003 at 11:51:34AM +0200, David Olofson wrote:


Glenn Maynard

Right, so if backwards compatibility is broken (this library won’t work
with binaries compiled for older versions), it becomes a different
library name–but none of what we’ve mentioned breaks backwards
compatibility at all, only forwards compatibility.

So, I think that backward compatibility is not necessary.
It’s evolution… for the best of library, less bugs less workarounds…
SDL 2.0 should be another SDL

Just, my opinion, but…

Bira–
“Mr O’Brien, beam me up!”

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At this point, I really need to know:

  1. If we make enhancements to the current SDL,
    are they going to be accepted (Such as
    full-duplex audio)?
  2. Is someone working on SDL 2.0? Is there a
    feature list and mock-api documented? When is
    this planned? Can we help? 3. Should I change
    my code to use OpenGL exclusively and remove
    all SDL code, or wait for SDL 2.0?

HTTP://www.libsdl.org/cgi/cvsweb.cgi/SDL20

Does that help any?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/WSDx3POUPzNqisoRAmSdAJsGPuVIpBJuPTObMNoRmOntevchaQCaAvDP
tR7/d0pokZ0K474IwprE7bA=
=rOZD
-----END PGP SIGNATURE-----

Okay, I’ve been swept up in the miasma around SDL 2.0 to know a bit
about it and feel at least semi qualified to speak on the to a small
extent (Sam or the inner circle feel free to step in if I say anything
blaringly wrong).

SDL 2.0 will most likely not be compatible, both through source and
binary with SDL 1.X. This is necessary since SDL 2.0 will be
addressing limitations of the SDL 1.X design.

SDL 2.0 is/was being designed to interact with OpenGL texture-wise a
little better.

SDL 1.X will still be supported after SDL 2.0’s release. Think of it
like linux kernals, there is always a stable branch and a development
branch. Even though the differences between SDL 1 and 2 are’nt of
that nature.

Don’t put off using SDL to wait for SDL 2.0. SDL 2.0 will require
some major preplanning and work to come about. The best thing if you
really plan to use SDL 2.0 for your project is to create a abstraction
between your program and the graphics layer with SDL/OpenGL as a
backend to that, that way when SDL 2.0 comes out it should be easier
to transition to it (if the API allows it, hopefully everything that
can be done in SDL can be done in SDL 2.0).

Wesley Poole
AKA Phoenix Kokido
kokido.sf.net
@Wes_Poole

BESTJ at Nationwide.com wrote:

I wrote a map/character editor for my game, and shared it with some
friends. The big complaint was that they couldn’t get windows "out"
of the editor. They used external programs (gimp, photoshop, ect) to
edit the media, and wanted to be able to see windows from both
applications at once. I soon found that this was not possible, and
was NOT planned, even in the next release. I moved ahead, cleaning
my code, and extending it.

Actually there never was any problem with seeing SDL windows and the windows
of external programs at the same time - just ommit the SDL_FULLSCREEN flag.
Nor was there any problem (AFAIK) with multiple SDL windows generated from
multiple SDL programs. The problem was always generating multiple windows
from the same SDL program. (Or maybe I’ve completely misunderstood what
you’re saying here?)

At this point, I really need to know:

  1. If we make enhancements to the current SDL, are they going to be
    accepted (Such as full-duplex audio)?
  2. Is someone working on SDL 2.0? Is there a feature list and
    mock-api documented? When is this planned? Can we help?
  3. Should I change my code to use OpenGL exclusively and remove all
    SDL code, or wait for SDL 2.0?

Unfortunately SDL seems to be stuck between versions. The 1.2 branch is
still in development and is still getting new features, but it’s not getting
the attention it deserves because all of the truly interesting features are
being saved for version 2.0. 2.0, on the other hand, is supposed to be a
complete rewrite of SDL, which means that there’s a good chance it’ll never
get finished. (See
http://www.joelonsoftware.com/articles/fog0000000069.html)

SDL in its current state is still good enough for me, but I am worried about
its future. Does anybody else here feel that a branch may be the Right
Thing To Do?–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com