The status of SDL 2.0?

SDL Development
1

Is anyone currently working on SDL 2.0? I saw CVS files and notes but it
looks far from an alpha. Any projected release date or are we still in planning
phase?
I’d also like to veto the complete removal of CD-ROM support, it’s great that
SDL can do this, and if it already does why stop it?

2

Do you have any problem with current SDL???
What new do you expect from SDL 2???
SDL follows Linux versions, not Microsoft (like DirectX 6.0, 7.0, 8.0, 9.0)----- Original Message -----
From: MysticMugs2 at cs.com
To: sdl at libsdl.org
Sent: Wednesday, July 02, 2003 10:01 PM
Subject: [SDL] The status of SDL 2.0 ?

Is anyone currently working on SDL 2.0? I saw CVS files and notes but it looks far from an alpha. Any projected release date or are we still in planning phase?
I’d also like to veto the complete removal of CD-ROM support, it’s great that SDL can do this, and if it already does why stop it?

3

Hi all,

I have a suggestion. I saw that question asked by user from the list a
few time. Every time Each I look at the answers and each time I don’t
feel that the question was well answered. I can even feel some sarcasm
some time. I’m not sure why.

Personaly, as a OpenSource developer, I understand why there’s no
version 2 (yet :wink: ). I also feel that current version of SDL have a lots
of features to satisfy every kind of project.

Anyway, here’s my suggestion. Answer clearly why SDL is like it is now
(versioning system, version 2… ) in the list so further users with the
same question will find out why by searching the archives (lets hope) or
add the info somewhere (FAQ, Wiki… I don’t care).

<- Chameleon -> wrote:> Do you have any problem with current SDL???

What new do you expect from SDL 2???
SDL follows Linux versions, not Microsoft (like DirectX 6.0, 7.0, 8.0, 9.0)

----- Original Message -----
*From:* MysticMugs2 at cs.com <mailto:MysticMugs2 at cs.com>
*To:* sdl at libsdl.org <mailto:sdl at libsdl.org>
*Sent:* Wednesday, July 02, 2003 10:01 PM
*Subject:* [SDL] The status of SDL 2.0 ?

Is anyone currently working on SDL 2.0? I saw CVS files and notes
but it looks far from an alpha. Any projected release date or are we
still in planning phase?
I'd also like to veto the complete removal of CD-ROM support, it's
great that SDL can do this, and if it already does why stop it?

–
Sacha Fournier
Applications Developer
DM Solutions Group
@Sacha_Fournier
tel: 418.696.5056
fax: 418.696.5056

www.dmsolutions.ca

/"\ ASCII Ribbon Campaign against HTML
\ / email and proprietary format
X attachments.
/ \

4

Sacha Fournier wrote:

Hi all,

I have a suggestion. I saw that question asked by user from the list a
few time. Every time Each I look at the answers and each time I don’t
feel that the question was well answered. I can even feel some sarcasm
some time. I’m not sure why.

Personaly, as a OpenSource developer, I understand why there’s no
version 2 (yet :wink: ). I also feel that current version of SDL have a
lots of features to satisfy every kind of project.

Well, that depends.

I really like SDL, the cross-platform graphics & sound abilities are
fantastic, but it’s limited by its’ gaming roots.

An example: I work in the post-production industry. I sometimes have to
write some small utility (say a log-based image (eg: cineon format, or
dpx) file viewer, or perhaps a mjpeg-sequence-with-audio-track player).
SDL is great for this - I can write it once and it runs on Windows,
OS-X, Linux, and SGI which are my 4 main platforms, in increasing
importance.

My issue is that I often want to have more than one window open. So far,
I’ve fudged it by adding “tabs” or sizing the window to big enough for
all the controls I need. This makes the code somewhat messy though :frowning: I
believe that SDL-2 will allow multiple windows, and I’ve been waiting
with baited breath since it was first announced. I’m well-baited :-))

For the time-being, I work around it. I understand that my situation is
somewhat unique, and that for the vast majority of SDL applications,
it’s just wonderful as-is. In fact my current project is to get a
cross-platform port of GTK and SDL, so that I can use the GTK widget-set
for my widget-based windows, and SDL for the main graphically-based one.
I’m hoping that if I spawn the entire GTK-side of the application into a
thread, I might be able to get two separate event loops running,
depending on which window the mouse is in :slight_smile:

Simon.

5

My issue is that I often want to have more than one window open. So far,
I’ve fudged it by adding “tabs” or sizing the window to big enough for
all the controls I need. This makes the code somewhat messy though :frowning: I
believe that SDL-2 will allow multiple windows, and I’ve been waiting
with baited breath since it was first announced. I’m well-baited :-))

How is this coming? What sort of interface/design issues need to
get resolved to get multiple windows in SDL 2.0?

Ron Steinke> From: Simon Gornall

6

Simon Gornall wrote:

For the time-being, I work around it. I understand that my situation is
somewhat unique, and that for the vast majority of SDL applications,
it’s just wonderful as-is. In fact my current project is to get a
cross-platform port of GTK and SDL, so that I can use the GTK widget-set
for my widget-based windows, and SDL for the main graphically-based one.
I’m hoping that if I spawn the entire GTK-side of the application into a
thread, I might be able to get two separate event loops running,
depending on which window the mouse is in :slight_smile:

Why not just use wxWindows?

I’ve read some people on wxWindows list asking about integration with
SDL, perhaps there are enough people interested to make it happen?–
Milan Babuskov
http://fbexport.sourceforge.net
http://njam.sourceforge.net

7

i think a rewrite of some sdl backends would be nice (opengl for 2d (->glSDL), dx9 instead of dx3 (which is used now in windows afaik), …)----- Original Message -----
From: <- Chameleon ->
To: sdl at libsdl.org
Sent: Thursday, July 03, 2003 2:00 PM
Subject: Re: [SDL] The status of SDL 2.0 ?

Do you have any problem with current SDL???
What new do you expect from SDL 2???
SDL follows Linux versions, not Microsoft (like DirectX 6.0, 7.0, 8.0, 9.0)
----- Original Message -----
From: MysticMugs2 at cs.com
To: sdl at libsdl.org
Sent: Wednesday, July 02, 2003 10:01 PM
Subject: [SDL] The status of SDL 2.0 ?

Is anyone currently working on SDL 2.0? I saw CVS files and notes but it looks far from an alpha. Any projected release date or are we still in planning phase?
I'd also like to veto the complete removal of CD-ROM support, it's great that SDL can do this, and if it already does why stop it?
8

My issue is that I often want to have more than one window open. So far,
I’ve fudged it by adding “tabs” or sizing the window to big enough for
all the controls I need. This makes the code somewhat messy though :frowning: I
believe that SDL-2 will allow multiple windows, and I’ve been waiting
with baited breath since it was first announced. I’m well-baited :-))

How is this coming?

I can’t help with that, I don’t know.

What sort of interface/design issues need to
get resolved to get multiple windows in SDL 2.0?

One of the main areas is the event system. Currently since all events
are associated with a single window there is no window ID in the events.
So, a lot of changes have to be made to the event system. It may be
possible to add that piece of data at the end of the event structure so
that the visible API would stay compatible with current code.

All of the window management function would have to change because
currently they don’t have a parameter to specify which window to manage.

You might get by without having to change most of the rest of the API.
Though SDL_SetVideoMode() must change. Perhaps just adding a new flag to
tell it that you want a new window… You might be able to add multiple
window support without having to call it SDL 2.0, But, I suspect that
the internal changes would be large even if the external changes can be
make compatible with SDL 1.2

	Bob PendletonOn Thu, 2003-07-03 at 11:54, rsteinke at w-link.net wrote:

From: Simon Gornall

Ron Steinke

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±----------------------------------+

9

Milan Babuskov wrote:

Simon Gornall wrote:

For the time-being, I work around it. I understand that my situation
is somewhat unique, and that for the vast majority of SDL
applications, it’s just wonderful as-is. In fact my current project
is to get a cross-platform port of GTK and SDL, so that I can use the
GTK widget-set for my widget-based windows, and SDL for the main
graphically-based one. I’m hoping that if I spawn the entire GTK-side
of the application into a thread, I might be able to get two separate
event loops running, depending on which window the mouse is in :slight_smile:

Why not just use wxWindows?

I’ve read some people on wxWindows list asking about integration with
SDL, perhaps there are enough people interested to make it happen?

A bit off-topic for the list, but mainly because the last time I
checked, wxWindows was pretty hard to get to work on OS-X.

I’ll have another look, see if it’s got any better :slight_smile:

ATB,
Simon

10

What sort of interface/design issues need to
get resolved to get multiple windows in SDL 2.0?

One of the main areas is the event system. Currently since all events
are associated with a single window there is no window ID in the events.
So, a lot of changes have to be made to the event system. It may be
possible to add that piece of data at the end of the event structure so
that the visible API would stay compatible with current code.

It only needs to go at the end if you want to maintain ABI compatibility.
Also, it would be much nicer to have the window id in the same place
in every event structure (right after the type?), since then
you could devise a BaseEvent struct which you could cast any
other struct to. That would let you extract the window id
for dispatch purposes without determining the event type.

All of the window management function would have to change because
currently they don’t have a parameter to specify which window to manage.

And you’d also have to worry about whether or not it’s possible to have
multiple fullscreen windows.

You might get by without having to change most of the rest of the API.
Though SDL_SetVideoMode() must change. Perhaps just adding a new flag to
tell it that you want a new window… You might be able to add multiple
window support without having to call it SDL 2.0, But, I suspect that
the internal changes would be large even if the external changes can be
make compatible with SDL 1.2

In addition, if you didn’t want a new window, you’d
also have to specify which window you were replacing.
It might be easier to create a totally new API for window
creation, and make the new API flexible enough that
SDL_SetVideoMode() could be a compatibility wrapper
around some of the new functions.

Ron Steinke> From: Bob Pendleton

On Thu, 2003-07-03 at 11:54, @rsteinke_at_w-link.n wrote:

11

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

One of the main areas is the event system. Currently since all events
are associated with a single window there is no window ID in the
events. So, a lot of changes have to be made to the event system. It
may be possible to add that piece of data at the end of the event
structure so that the visible API would stay compatible with current
code.

It only needs to go at the end if you want to maintain ABI compatibility.
Also, it would be much nicer to have the window id in the same place
in every event structure (right after the type?), since then
you could devise a BaseEvent struct which you could cast any
other struct to. That would let you extract the window id
for dispatch purposes without determining the event type.

I agree with you, but that breaks the ABI and is therefore something for SDL
2.0 (always change the major version when breaking the ABI). The previous
post was about extending the current ABI in a way that doesn’t break it.

Don’t get your hopes up, though. Since the user of SDL allocates SDL_Event
structures and not SDL itself, the size of an SDL_Event must not change.
This makes it impossible to append a new field to SDL_Event.

You might get by without having to change most of the rest of the API.
Though SDL_SetVideoMode() must change. Perhaps just adding a new flag
to tell it that you want a new window… You might be able to add
multiple window support without having to call it SDL 2.0, But, I
suspect that the internal changes would be large even if the external
changes can be make compatible with SDL 1.2

In addition, if you didn’t want a new window, you’d
also have to specify which window you were replacing.
It might be easier to create a totally new API for window
creation, and make the new API flexible enough that
SDL_SetVideoMode() could be a compatibility wrapper
around some of the new functions.

I agree. SDL_SetVideoMode() should be deprecated, but kept around for source
code compatibility (if source code compatibility is even possible).

cu,
Nicolai

Ron Steinke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/BJHpsxPozBga0lwRAl+OAJ0QesTqYLwgG4spodjcIXYUQiKi7gCeMU/T
g0pqXW74JlREMxiM7IGBI6M=
=k52P
-----END PGP SIGNATURE-----On Thursday 03 July 2003 21:48, rsteinke at w-link.net wrote:

From: Bob Pendleton

12

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

Hi!Am Donnerstag, 3. Juli 2003 22:28 schrieb Nicolai Haehnle:

I agree. SDL_SetVideoMode() should be deprecated, but kept around for
source code compatibility (if source code compatibility is even possible).

Just one stupid question: Why source-code compatibility at all? Isn’t the main
purpose of major version-changes to create something new, not being stopped
by compatibility issues? Don’t you usually do major-version changes because
it’s a new design that’s not compatible to the old one?

just wondering
Matthias

Matthias Bach | GPG/PGP-Key-ID: 0xACA73EC9
www.marix-world.de | On Keyserver: www.keyserver.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/BJtAlnJmS6ynPskRAuAVAJ9aa/DUl3k1d62vPXdNJz+pK/Y+tQCgjwwv
dynzRKJRhRcNoGBiFCSMQ3c=
=+Rux
-----END PGP SIGNATURE-----

13

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

I agree. SDL_SetVideoMode() should be deprecated, but kept around for
source code compatibility (if source code compatibility is even
possible).

Just one stupid question: Why source-code compatibility at all? Isn’t the
main purpose of major version-changes to create something new, not being
stopped by compatibility issues? Don’t you usually do major-version
changes because it’s a new design that’s not compatible to the old one?

It makes it easier for programmers to start using the new version when they
don’t need any of the new features of the new version. Granted, SDL 2.0 is
probably a case where this is impossible, simply because SDL 1.x is quite
limited compared to what some would like to see in SDL 2.0. But why break
stuff just because you can?

cu,
Nicolai

just wondering
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/BKgWsxPozBga0lwRAobUAKCFB4wjM5CI7t91jsTPupmMVr1JCwCfSP/Y
04NAczEhHzwNbLNBpe648b4=
=0J6u
-----END PGP SIGNATURE-----On Thursday 03 July 2003 23:08, Matthias Bach wrote:

Am Donnerstag, 3. Juli 2003 22:28 schrieb Nicolai Haehnle:

14

I get mouse coordinates directly from “event.motion.x"
and “event.motion.y”. The x and y values go wrong if
any key on keyboard is pressing. The y value is always
"167” and the x value is always around “335XXX”,
depends on which key is pressing. I stuck my coding
because of this… Did anyone has this problem
before?Reply and help is greatly appreciate…thanks…________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

15

fre 2003-07-04 klockan 15.41 skrev Sofmz:

I get mouse coordinates directly from “event.motion.x"
and “event.motion.y”. The x and y values go wrong if
any key on keyboard is pressing. The y value is always
"167” and the x value is always around “335XXX”,
depends on which key is pressing. I stuck my coding
because of this… Did anyone has this problem
before?Reply and help is greatly appreciate…thanks…

Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Sounds like you are reading event.key when you are processing a
SDL_KEYDOWN event (easy when nesting switch to deep… I always do
similar mistakes). Try using SDL_GetMouseState and check if the problem
is elsewhere though.

16

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

Hi!

I agree. SDL_SetVideoMode() should be deprecated, but kept around for
source code compatibility (if source code compatibility is even possible).

Just one stupid question: Why source-code compatibility at all? Isn’t the main
purpose of major version-changes to create something new, not being stopped
by compatibility issues? Don’t you usually do major-version changes because
it’s a new design that’s not compatible to the old one?

just wondering
Matthias

Yes, it is.

But, considering how much effort people have put into learning SDL and
the astounding reliability and stability of the existing code. It looks
like there is a lot of value in making only the changes that need to be
made, rather than changing things just to change them. And, if it is
possible to implement all the current SDL APIs as wrappers over SDL 2.0
APIs it would save a lot of time for existing projects. They could more
up to 2.0 without having to rewrite all at once.

I am happy to see people thinking about how to do a major revision
change while causing the minimum harm to current users. Of course, my
opinion will have little effect on what actually is done, if anything is
done at all.

	Bob PendletonOn Thu, 2003-07-03 at 16:08, Matthias Bach wrote:

Am Donnerstag, 3. Juli 2003 22:28 schrieb Nicolai Haehnle:

Matthias Bach | GPG/PGP-Key-ID: 0xACA73EC9
www.marix-world.de | On Keyserver: www.keyserver.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/BJtAlnJmS6ynPskRAuAVAJ9aa/DUl3k1d62vPXdNJz+pK/Y+tQCgjwwv
dynzRKJRhRcNoGBiFCSMQ3c=
=+Rux
-----END PGP SIGNATURE-----

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±----------------------------------+

17

Hi, I have something to tell to everybody in the list.
It’s about this long-discussed topic (SDL 2.0)

First, I hate all that have to do with mind-closed and extremist people
SDL is, as most of us know, the coolest & fastest crossplatform media
library, and really, it is fully functional at the moment, so I agree
that there is no need to make a major release of the library, but this
is not a excuse to be agressive with people asking for it.

Second, Don’t say that SDL already has ALL the functionallity & features
it can or should have, I think that it is missing mmx/sse code to speed
up things a bit, mainly in computers that don’t have accelerated video
it should help a lot, but I think that this is not a excuse to say let’s
release SDL 2.0, it can perfectly be added in a minor release.

Third, Looking SDL & related stable & well known integrated libraries
such as SDL_image, SDL_net, SDL_ttf, SDL_mixer, etc as a User point of
view (I’m a developer, but as I mentioned in First point, I’m not
mind-closed) I think they should all be part of SDL core, so the user
has not to step by all that installations/dependencies, they are
libraries that most of us use (Am I wrong?), for those that think I’m
crazy take a look at clanlib, all subpackages/subsystems are part of the
main package, I’m not saying clanlib is better than SDL, I’m simply
asking if we could make users life simpler :wink:

Pirata

18

Pirata: “I’m not mind-closed) I think they should all be part of SDL core”

If you are not mind-closed then why not considder other users that do not need all the add-on libs and would given them a lot of unneeded overhead.
I do not want my OpenGL engine eating up memory just so you don’t have to add a few includes and init’s.
If it where up to me there would be a #define switch to remove the 2D renderer all together so i can remove that overhead aswell.--------------------------------
| Dinand Vanvelzen, |
| Programmer, |

Software Engineering student
19

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Sunday 06 July 2003 10:12, Dinand Vanvelzen wrote:

Pirata: “I’m not mind-closed) I think they should all be part of SDL
core”

If you are not mind-closed then why not considder other users that do not
need all the add-on libs and would given them a lot of unneeded overhead.
I do not want my OpenGL engine eating up memory just so you don’t have to
add a few includes and init’s. If it where up to me there would be a
#define switch to remove the 2D renderer all together so i can remove
that overhead aswell.

Note that “providing everything in one package” is not the same thing as
"putting everything into one library". I agree that the actual core library
should remain as lightweight as reasonably possible.

However, you should try to look at it from the perspective of someone with a
background in, say, DirectX. With DirectX, you get a lot of things in one
package, which is extremely convenient. Still, you can choose to use only
a small part of the whole package if you don’t need all of it.
Let’s fact it, if this person looks at SDL, he sees a library that “can’t do
much”. She will hear about different add-on libraries, but how should she
a) find them all and b) choose which one to use without trying them all
(takes a lot of time) or asking (with a high risk of getting useless
answers, STFW and so on).

Think about it.

cu,
Nicolai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/CDd6sxPozBga0lwRAoThAJ0YaEMvt6yxt0ZKsXviB8tMYByeRQCfYUWb
dS7WRsDy8qoevVqw1SKV0NU=
=w+pK
-----END PGP SIGNATURE-----

20

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

Hi!
Maybe I did phrase my comment the best way possible.

Just one stupid question: Why source-code compatibility at all? Isn’t the
main purpose of major version-changes to create something new, not being
stopped by compatibility issues? Don’t you usually do major-version
changes because it’s a new design that’s not compatible to the old one?

just wondering
Matthias

Yes, it is.

I am happy to see people thinking about how to do a major revision
change while causing the minimum harm to current users.

This is were some might have got me wrong. I just wanted to tell, that when
doing a new version you first shouldn’t think about making it compatible to
the old stuff, as that is gonna limit the possibilitys of the new versions
architecture. The better way would be to do a new version, and thand do
something like an SDL1forSDL2 compatibility-Layer. That might e.g. be in an
SDL1.3.0.so (or DLL) for compatibilty reasons. This would get maximum
features and performance out of the new version, and would still keep old
programms happy. It would also have the advantage of any new programm being
able to make use ONLY of the new lib, and not carying the old calls with it.
But as you said

Of course, my
opinion will have little effect on what actually is done, if anything is
done at all.

that’s true for me too.

Matthias

Matthias Bach | GPG/PGP-Key-ID: 0xACA73EC9
www.marix-world.de | On Keyserver: www.keyserver.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/CGHBlnJmS6ynPskRAgcsAJ9rUKMqore386GO56ShHVF3Mnp08QCfd+bP
BcO28IcH3wssPZM/6P8NiUQ=
=h53N
-----END PGP SIGNATURE-----Am Samstag, 5. Juli 2003 18:47 schrieb Bob Pendleton: