If you update your existing SDL code from the subversion repository,
you’ll get SDL 1.3! It doesn’t build yet, so if you want SDL 1.2,
you can get it from the SDL subversion page:
http://www.libsdl.org/svn.php
Currently the video API is under heavy redesign, and proof of concept
drivers are being worked on for the dummy driver and Windows GDI. The
code currently doesn’t build on any other platform, but feel free to
check it out to see what is coming for 1.3.
You’re welcome to contribute to the SDL 1.3 development, as long as you’re
okay with your contribution being released under a commercial license, in
addition to the LGPL.
Enjoy!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment_______________________________________________
SDL-announce mailing list
SDL-announce at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl-announce
Where can we get a copy of the new commercial license terms? I checked
both the website and the trunk but haven’t found it.On 7/10/06, Sam Lantinga wrote:
You’re welcome to contribute to the SDL 1.3 development, as long as you’re
okay with your contribution being released under a commercial license, in
addition to the LGPL.
–
They’re not done yet, I’ve been working feverishly on the new video stuff. 
See ya!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment> On 7/10/06, Sam Lantinga wrote:
You’re welcome to contribute to the SDL 1.3 development, as long as you’re
okay with your contribution being released under a commercial license, in
addition to the LGPL.
Where can we get a copy of the new commercial license terms? I checked
both the website and the trunk but haven’t found it.
Sam Lantinga wrote:
Where can we get a copy of the new commercial license terms? I checked
both the website and the trunk but haven’t found it.
They’re not done yet, I’ve been working feverishly on the new video stuff.
Just to clarify, this will not cause issues on commerical games that use
unmodified SDL/SDL_mixer/etc ?
The only thing we really do, is build our own SDL/SDL_mixer with
whatever we don’t need stripped out (Mikmod and MIDI support in
SDL_mixer, for example)
Pete.
Just to clarify, this will not cause issues on commerical games that use
unmodified SDL/SDL_mixer/etc ?
Not at all, in fact the existing terms will still apply, you can use LGPL
as you do now. It will just allow you to statically link SDL with your
application.
See ya,
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Sam Lantinga wrote:
Just to clarify, this will not cause issues on commerical games that use
unmodified SDL/SDL_mixer/etc ?
Not at all, in fact the existing terms will still apply, you can use LGPL
as you do now. It will just allow you to statically link SDL with your
application.
OK, phew
Funnily enough the only platform where we have been asked to do this (or
more like berated for NOT doing this), is Linux
Pete.
Hello !
Funnily enough the only platform where we have been asked to do this (or
more like berated for NOT doing this), is Linux
No, we asked this for plattforms where dyn. linking is not
possible like Dreamcast, XBOX and so on.
CU
Torsten Giebl wrote:
Hello !
Funnily enough the only platform where we have been asked to do this (or
more like berated for NOT doing this), is Linux
No, we asked this for plattforms where dyn. linking is not
possible like Dreamcast, XBOX and so on.
I better explain this better I think. I was responsible for some of
Rune-Soft’s Linux game ports which used SDL. We decided that as pretty
much every distro has SDL and SDL_mixer in their packages, we would not
need to bundle them (We bundled SMPEG because hardly any distro’s had that)
Big mistake.
We had issues with distro’s compiling older SDL’s with GCC 4 when it
wasn’t fixed for that (Fedora Core 4), distro’s shipping SDL_mixer with
odd changes made that caused crashes (Mandriva), and numerous other
issues all of which were fixed by asking the users to update their SDL
and SDL_mixer packages, or at the worst, remove them and build their own
libs from source. In pretty much every bug report I had for one title,
the issues were resolved by removing the distro-shipped SDL and getting
the user to compile their own from source.
I have since received quite a few mails telling me that I should have
just statically linked to SDL and SDL_mixer. My reply has been that it
is not my fault that distro’s ship broken libs, and that we cannot
statically link due to the LGPL. This usually prompts the response of
"Distribute your object code!" which most of the people we license ports
from would strongly object to.
Our future policy, should we ship any further titles, will be to build
our own SDL and SDL_mixer and ship these with the game, in the same dir
as the game, and set up the link options so that the first path tried
for shared libs is the current dir. If there are issues with our shipped
libs, the user can remove them/symlink them as necessary.
Pete.
Bill Kendrick wrote:
Maybe I’m stupid, but what’s the difference between distributing a
re-linkable object and releasing a statically-linked app, when it comes
to IP protection???
It is a hell of a lot easier to reverse engineer something given the
separate object files with symbols, than it is to reverse engineer the
exe. I say that from practical experience.
Pete.
Hello !
I better explain this better I think. I was responsible for some of
Rune-Soft’s Linux game ports which used SDL.
Cool. Thanks for the info.
CU
Licensing issues aside, statically linking SDL is still a bad idea,
because it doesn’t allow replacing it with another version of SDL.On 7/10/06, Peter Mulholland wrote:
I have since received quite a few mails telling me that I should have
just statically linked to SDL and SDL_mixer. My reply has been that it
is not my fault that distro’s ship broken libs, and that we cannot
statically link due to the LGPL. This usually prompts the response of
"Distribute your object code!" which most of the people we license ports
from would strongly object to.
–
Hello !
Licensing issues aside, statically linking SDL is still a bad idea,
because it doesn’t allow replacing it with another version of SDL. –
It is, but sometimes it is the only doable way.
CU
Maybe I’m stupid, but what’s the difference between distributing a
re-linkable object and releasing a statically-linked app, when it comes
to IP protection???
What kind of ‘secret sauce’ is made available, if any? Or is it just that
the licensees are being dumb? 
Thx!On Mon, Jul 10, 2006 at 11:56:59PM +0100, Peter Mulholland wrote:
I have since received quite a few mails telling me that I should have
just statically linked to SDL and SDL_mixer. My reply has been that it
is not my fault that distro’s ship broken libs, and that we cannot
statically link due to the LGPL. This usually prompts the response of
"Distribute your object code!" which most of the people we license ports
from would strongly object to.
–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/
Ok, that seems reasonable. However, I know in the J2ME world (which I’m
admittedly still very new to), there are ‘obfuscation’ tools which go in
and muck with class names and the like, partly to shrink the size of the
application (because “a”, “b” and “c” are a lot shorter than
"someLongClassName", “someOtherClass”, and “thisCodeIsSuperSecret”),
but I guess also partly to… well… obfuscate!
Couldn’t something similar be done to shipped ‘.o’ files?
Sorry, getting off-topic. :^/On Tue, Jul 11, 2006 at 12:31:58AM +0100, Peter Mulholland wrote:
Bill Kendrick wrote:
Maybe I’m stupid, but what’s the difference between distributing a
re-linkable object and releasing a statically-linked app, when it comes
to IP protection???
It is a hell of a lot easier to reverse engineer something given the
separate object files with symbols, than it is to reverse engineer the
exe. I say that from practical experience.
–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/
Our future policy, should we ship any further titles, will be to build
our own SDL and SDL_mixer and ship these with the game, in the same dir
as the game, and set up the link options so that the first path tried
for shared libs is the current dir. If there are issues with our shipped
libs, the user can remove them/symlink them as necessary.
BTW, this is what Loki did, for the same reasons.
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Currently the video API is under heavy redesign, and proof of concept
drivers are being worked on for the dummy driver and Windows GDI. The
code currently doesn’t build on any other platform, but feel free to
check it out to see what is coming for 1.3.
Is it in a state where you can give a general, ball-park, SWAG, maybe if
Murphy’s Law stops messing with us, estimated time for completion of 1.3?
Eagerly awaiting SDL multiple windows without using hacks,
JeffOn Monday 10 July 2006 15:00 pm, Sam Lantinga wrote:
Sorry I wasn’t clear enough, what I really meant to say was
"statically linking SDL on platforms where dynamic linking is
available is still a bad idea".On 7/10/06, Torsten Giebl wrote:
Hello !
Licensing issues aside, statically linking SDL is still a bad idea,
because it doesn’t allow replacing it with another version of SDL. –
It is, but sometimes it is the only doable way.
–
I have since received quite a few mails telling me that I should have
just statically linked to SDL and SDL_mixer. My reply has been that it
is not my fault that distro’s ship broken libs, and that we cannot
statically link due to the LGPL. This usually prompts the response of
"Distribute your object code!" which most of the people we license ports
from would strongly object to.
Ship it as a shared library. Solves the object code dilemma, satisfies
the LGPL, and makes sure that SDL is available. Lets those that are
inclined to do so swap it out or use their system-installed version.
There will always be people that bitch “hey, this ships on my distro,
why did I have to download a WHOLE EXTRA 100 KILOBYTES for sdl?!”
That is what the “delete” button in your email client is for.
–ryan.
BTW, this is what Loki did, for the same reasons.
Fwiw, a lot of the Loki titles statically linked SDL, and provided a
separate dynamically linked version to satisfy the LGPL…in my
experience, this actually proved to not be necessary with SDL, since the
API has stayed stable and binary compatible. Rather than support two
binaries on things like UT2004, I just shipped the one dynamically
linked version (with a “blessed” SDL included).
In almost five years, I can count the number of serious head-scratching
bugs I’ve hit because people switched out SDL with their own version on
one hand. I expected more trouble, but this actually turned out to be
less work in the long run, I think.
I don’t know that this is generally good advice, as some free software
is terrible about API/ABI compatibility, external dependencies, and
general stability…but for SDL, it’s worked extremely well, and I
think, kept most people very happy.
The fact that SDL can be aggressive about dlopen()ing external
dependencies helps this a lot, too, since I can, say, ship something
that supports ALSA, ESD, Arts, X11, OpenGL, etc, without any of those
things necessarily existing on the end user’s system.
–ryan.