The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I just wanted to let people know some exciting news and the current status of SDL development.

I recently left Blizzard Entertainment to relax, spend time with family, and explore some ideas to expand the Galaxy Gameworks business.

What this means, is that as of today, I am devoted 100% to the SDL 1.3 development, and am working out staffing needs and scheduling.
However, there is a huge amount of work that remains to be done, in terms of Q/A, bug fixing, and community support.

If you would like to contribute, there are a number of ways you can help:
* If you're currently struggling with SDL 1.3, please report bugs to bugzilla and ask for help on the mailing list
* If you've been holding off on touching SDL 1.3, please pretend it's done, download it, and report bugs to bugzilla
* If you've reported issues on the mailing list in the past, pretend they're lost and re-report issues to the list and create entries for them in bugzilla

All of this will result in a huge influx of bugs and issues.  Please be patient, helpful and persistent.  Community supported fixes are always appreciated.

Here are links that will be helpful:
SDL 1.3 Documentation (work in progress - contact to contribute):
  http://wiki.libsdl.org
SDL 1.3 Migration Guide (thanks Sylvain!)
  http://wiki.libsdl.org/moin.cgi/MigrationGuide
SDL 1.3 Roadmap:
  http://wiki.libsdl.org/moin.cgi/Roadmap
SDL 1.3 PRERELEASE source code:
  http://www.libsdl.org/tmp/SDL-1.3.zip
Bugzilla:
  http://bugzilla.libsdl.org/
Mailing List:
  http://www.libsdl.org/mailing-list.php

Please note that the mailing list and the forums mirror each other, but there is an additional spam prevention step required to post on the forums:
http://forums.libsdl.org/viewtopic.php?t=5973

Cheers!
--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Hello,


Wow, pretty brave of you. I wish you the best of luck. Looking forward
to the future of SDL!


Edgar

On 04/01/11 09:30, Sam Lantinga wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

A call to arms, huh?  I'm in.

Jonny D


On Tue, Jan 4, 2011 at 5:45 AM, Edgar Simo wrote:

Congrats Sam on branching out on your own!

I did exactly what you asked for (attempted to use SDL 1.3.) Right now
my code has a switch where I can jump back and forth. There's just a
couple bug fixes and missing implementations I'm waiting on, and I'll be
more than happy to test when they land.

Is it possible to every once and a while post to this mailing list a
change log? Then I can tell when what I need is fixed, and then turn
around and test it. I know I can watch the bugzilla, but that would be
a bit more convenient (for me) at least. Obviously not a biggie, and
the last thing I want to do is make more work for you, but could help
turn around time for us waiting.

Keep up the good work!

[>] Brian
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It would be convenient if there were some sort of rss on bug reports/fixes, or something like that.
I'm not familiar with bugzilla, but I couldn't find anything like that available on bugzilla.libsdl.org
Take care,
-Oz

On Tue, Jan 4, 2011 at 9:16 AM, Brian Barnes wrote:

Thanks Edgar! :)

On Tue, Jan 4, 2011 at 2:45 AM, Edgar Simo wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Great! :)

On Tue, Jan 4, 2011 at 3:56 AM, Jonathan Dearborn wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Thanks Brian!

What bug fixes and implementation are you waiting on?

I'll definitely periodically send a list of bug fixes and changes to the list.

Thanks!

On Tue, Jan 4, 2011 at 6:16 AM, Brian Barnes wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Sam,

I’m glad to hear you are going to be focusing on SDL 1.3. I had to shelve my iPhone project because SDL has been in limbo for so long, so it is good that we will be gaining some traction.

Let me know if there is anything I can do to help. In the meantime I will review the latest SDL 1.3 against my project and see what outstanding issues are still there.

Ken

Thanks Ken! :)

On Tue, Jan 4, 2011 at 10:27 AM, Ken Rogoway wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

It looks like there is:
http://www.bugzilla.org/releases/2.20/new-features.html#rss

From Ryan:
You can generate a query that just catches all new bugs and use that RSS, or whatnot.
(Newer bugzillas name this link at the bottom of the page "Feed" instead of "RSS")
If you want the RSS to update every time there's activity on a bug, have it search for every bug, make sure your query is sorted by "last change."

On Tue, Jan 4, 2011 at 6:29 AM, Alex Barry wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Sam wrote:


I posted all these a while ago with some suggestions (though you obviously know better than me for SDL, so whatever way you want is fine.) The list was:

1. Relative motion isn't implemented
2. Right mouse on OS X (supposedly this has been patched, I was waiting on the others, but it's on my list to check)
3. Won't compile for 10.4 (this is the NSTouch interface, will need to be def'd out for< 10.6)
4. System cursor doesn't get hidden when switching to relative mode (by docs) or by calling it directly
5. Switching out from full screen on OS X can re-arrange windows (if the full screen< desktop resolution.)

Relative mouse motion was the show stopper for me. Once I get the OS X/PC desktop version working with 1.3, I'll be able to start the path to the iPhone SDL 1.3 port of dim3.

[>] Brian



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Thank you sam for being so persevering with SDL. It's good to see to project remaining active over time.

I continue to develop Newcol (http://www.newcol.fr) even if I waited to have a more stable SDL1.3 based version to update the web site.
SDL1.3 works fine as far as I can say (with SDL_gfx and other standards libraries)

For the bug list
- There are still inconsistencies between mouse events and gesture events when using a mac trackpad (triggering both kinds of events)

For the new features/ wish list
- saveAsPNG in SDL_Image (and other kinds of file format)
- more blit functions (I implemented many of them with mirror effect, gradient of transparency, etc. but they are far from being optimized)
- RGB2HSB function alike somewhere in the lib (I have them somewhere coded in C but since SDL has its own color coding ...)
- a better doc with many examples (but it seams to get improve very fast already)
- a TUIO-> SDL gesture event bridge (TUIO is a kind a open-source multitouch network api)

thank you again

This is a risky move, Sam! If I were working for a company as successful as Blizzard and doing what I love (being making games), I don't think I could do the same.

I don't know how much I could help, though. I'm currently working on my game again and I've got work too (and I can't exactly quit the military). However I do have my hands on a Mac mini and intend to pay to join the iPhone developer network or w/e it's called, so maybe I might be able to help a bit with the OSX/iOS ports once I'm more familiar with Cocoa and UIKit.

However, I do have one major suggestion that should be considered:
Separating the PC and Mobile device API. The needs of a PC and mobile application are different, and generally the features available and limitations are; too.

And of course I have suggestions for supporting libraries to make a more proper game development environment; but those can wait.

Also, some questions and comments about the roadmap:

Video:
1) "# Ryan: Add OpenGL 3.X context support " -- isn't this already done?
2) "# Support shaped windows " -- isn't this already done?

Events:
3) "# Sam: Add a timestamp to events " -- timestamp in seconds, microseconds, or what?
4) "# Sam: Add modifier state to key and button events " -- wasn't this done in SDL1.2 already? Why didn't it carry over?
5) "# Sam: Support showing / hiding the cursor " -- isn't this already done?
6) "# Sam: Add support color cursors " and "# Sam: Add support animated cursors " -- it doesn't seem possible to do this using native functions, at least not on Windows. It may be best to leave this to the application developer (it's not hard to draw a texture at the mouse cursor position).

Threads:
7) "# Sam: Create API for thread priority" -- there's no way to really do this effectively in a consistent manner. Although both Windows and POSIX provide this functionality, IIRC POSIX does not require that it actually change anything and does not define specific values. This will greatly complicate the development process.
"# Sam: Create API for thread processor affinity " -- does POSIX even require this functionality? I can't remember. If so, this seems at least manageable.

On 1/5/11 4:13 PM, Nathaniel J Fries wrote: Yes - but needs work for the basics (binarizer could to be improved and new modes added), on Win32 (shape not pixel correct in the current implementation) and on OSX (shape not applied for unknown reasons). The test program could also be improved and doc's added. Additional platforms could be added. The current shape processing pipeline is also designed to set a binary shape, while some platforms (DirectX) can set a full 8bit alpha channel for the window, so that could be added as well as a new "mode".

I am still too busy trying to finish my own studies and coping with an ever increasing family size to really pitch in. But I could suggest improvements, code-review, buddy-build or test, so if someone wants to continue working on this feature, let me know.

--Andreas

Hi,

This is wonderful (for the SDL community, you and your family
anyway... not so much for blizzard).

Installing 1.3 alongside 1.2 would be a big help for me and the pygame
project. Once they can both be installed at the same time, it will be
easier for everyone to get on with things.


cheers,



On Tue, Jan 4, 2011 at 8:30 AM, Sam Lantinga wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Installing SDL 1.3 alongside a 1.2 install in any *nix system isn't difficult.  While doing ./configure before compiling, specify a different prefix ( --prefix=/usr/local instead of /usr, for instance).  The reason there is no official word on how to install them side-by-side is that Sam isn't sure if the install will be a naming convention (instead of libSDL.so, maybe libSDL-1.3.so) or if it will be a directory issue (/usr/include/SDL to /usr/include/SDL-1.3).

Personally, I like the idea of custom directories, and it's simple to modify a pkg-config file to point to a custom directory, so you won't even have to worry about it.

I don't think there will be an official way to install 1.2 and 1.3 side by side until we're at the point of an official release, though.

Hopefully that helps you out a bit,
-Oz

On Thu, Jan 6, 2011 at 8:35 AM, René Dudfield wrote:

Can we agree on a de facto convention?  That would at least get us somewhere for now.  René, what's your preference?

Jonny D


On Thu, Jan 6, 2011 at 9:59 AM, Alex Barry wrote:

Hi,

I think I'm happy with anything really... If nothing is done, then
every distro will do it differently. Maybe it's best to consult the
various distribution packagers for SDL to see what they think.


Just for your information:

Python does it by having a separate directory for each version. eg,
/usr/lib/python2.6/
/usr/lib/python3.1/

/usr/include/python2.6/
/usr/include/python3.1/


I definitely think the distro packagers should be consulted - as they
probably know a lot about these things.

cheers,

On Thu, Jan 6, 2011 at 3:51 PM, Jonathan Dearborn wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

We also need one that will work on Windows.

I do have a suggestion on this.
SDL1.2 already expects SDL headers to be in <includedir>/SDL, right?
So why not put SDL1.3 headers in <includedir>/SDL/1.3.0/
Then we just specify the required version to sdl-config and it knows what library to link and which headers to include. Alternatively, the developer can just specify manually (it's not hard).

Kudos to Sam, it's really great news for the SDL community!
Hope all the best comes from this!
Vittorio

On Tue, Jan 4, 2011 at 9:30 AM, Sam Lantinga wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I'm going through the issues for Windows and it seems many of them are fixed but still open.

On 6 January 2011 09:59, Alex Barry wrote:
I posted a perl script to the mailing list some time ago that handled
this quite nicely. I'll see if I can find it.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 6 January 2011 20:36, Kenneth Bull wrote:
Found it.

Here's my original post:
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2009-August/071664.html

And the script itself is attached.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yeah, I'm still mulling this over. The problem is not just SDL, it's
also all the libraries that depend on SDL. For example, SDL_image at
the same version number can be built for both SDL 1.2 and SDL 1.3, and
I can see people wanting to install both simultaneously.

I sent e-mail to the distribution maintainers a year ago and never
heard anything back from them. Which unfortunately means I just have
to pick a method and watch people complain.

I'm definitely open to suggestions!

On Thu, Jan 6, 2011 at 8:06 AM, René Dudfield wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

Yeah, definitely for those too. As soon as a popular SDL 1.3 game is
released on linux people will want to package

A separate config binary might be very useful. eg, sdl-config13




On Fri, Jan 7, 2011 at 3:28 PM, Sam Lantinga wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I think there's only two options:

1) If the system supports dynamic library loading, use SDL's functions for that. Then require the version to be specified in IMG_Init(), and let the library try to load the appropriate functions from that. If the dll/so/dylib can't be found, throw an error. If the system does not support dynamic libraries (ie iPhone, Minix3 [at present]), then use the old method since they'll need to statically link everything anyway.
This increases the code size and complexity considerably, but the built size should not be much greater.
2) Require an SDL_VER definition when building the library, and simply provide two binary releases of the library: one for SDL 1.2 and another for SDL 1.3 (and repeat the process for each successive new API). (alternatively: require the use of sdl-config to build)

I don't really think either of them are ideal; the second one has the advantage of being idiot-safe (not quite idiot-proof, though), while the second has the advantage of keeping the code small and simple. But the first has the disadvantage of requiring dynamic linking, and the second has the disadvantage of requiring a different build between SDL API versions.

Sam, it's great to hear there's a renewed interest on SDL development.
This days I had success in my zillionth attempt to link to SDL1.3 in MacOS, and upgrading to 1.3 was vital because I need multiple windows for my project.
So I'd like to contribute while I learn 1.3, is there any style guide to write on the wiki?
I'd like to add descriptions like telling briefly what a function does, and adding code samples.

On 1/7/11, Nathaniel J Fries wrote:


Hmmm, I guess I might be a distribution maintainer that should say
something about this. So for Mac, we have quite a whirlwind of strange
options. All of them may involve developers to kind of know what's
going on though. Since we use .frameworks on Mac, there is a built-in
versioning mechanism that kind-of-sort-of handles this case. Building
versioned frameworks is kind of a pain in the arse since there almost
no Xcode support for it. But once you have it, it actually might work.

If you look at the framework structure, there is a directory called
Versions inside which contains a subdirectory (usually named A) and a
symlink called Current. The idea is that you put multiple versions of
the actual library there. We might introduce a subdirectory called 1.3
which has all the 1.3 stuff. Leave A as 1.2 for backwards
compatibility.

Then there is a bunch of different layers of abstraction that kick in
if you built a Mac app correctly. For already built executables that
dynamically link, they know to use the full qualified/non-symlink path
to the library that was pointed to by Current when the executable was
built. So if you update the framework and the symlink changes, the
executable still safely links and invokes the legacy version avoiding
breakage.

But newly linked apps always pick the version linked to Current. So
generally they are required to use the new stuff.

It gets harder if developers want to build and link to the old version
of the framework. They must go into their frameworks and change the
symlinks themselves. And they must remember to change back the
symlinks themselves.


This technique also has the downside in code size. We would
effectively double the size of the framework we ship. End users are
free to purge the stuff they want themselves, but I expect most people
won't feel comfortable enough to do so.


But I should also point out on the Mac that bundling the framework
inside your app (or library) is really the proper thing to do and
maybe we shouldn't worry about this case at all. On Mac, developers
are expected to do this grunt work so end-users never have to deal
with DLL hell. So we could continue to name the framework "SDL" in
both cases, and force the developer to know which is which and how
their own SDL satellite libraries were compiled.

Also for SDL 1.3, I'm assuming we can drop 10.4 support which means we
can start using @rpath instead of @executable_path which makes it
easier to support embedding inside other libraries instead of just
applications. I have an example of this with the SDL_sound.framework I
built where I embedded an Ogg and Vorbis framework inside.


-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Style guide? I'd just use entries that already exist as a base. Sam should probably elaborate more, though.

Absolutely, please contact Sheena, our awesome tech writer, at

Thanks!

On Fri, Jan 7, 2011 at 4:28 PM, petruza wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org