Any news about...?

Hi all,

I have a few questions on my mind and I would like to know some answers :slight_smile:

-First one, what about the integration of glSDL on SDL? When we can download
SDL with glSDL included?
As some of you know, I have coded a glSDL benchmark some weeks ago. It
works very well, fast, stable and
with alpha per pixel accelerated by your videocard! (thanks to Stephane
Marchesin and David Olofson!)

-Second one, what about SDL 1.3? where I can download some white papers,
docs, source code or anything related to it?

-Last one, what about SDL 2.0? a long time ago… I haven’t listened
anything about it…

Well, I hope to read some answers to sleep in calm :wink:

Thanks you very much!!

Hi all,

I have a few questions on my mind and I would like to know some answers :slight_smile:

-First one, what about the integration of glSDL on SDL? When we can
download SDL with glSDL included?
It’s supposedly in SDL1.3 CVS, though I haven’t been able to locate that
particular code in it.

-Second one, what about SDL 1.3? where I can download some white papers,
docs, source code or anything related to it?
There are no particular docs or whitepapers about it because it’s still under
development. It’s basically a holding tank for new major and/or experimental
features. If/when I finish that audio input API I doubt it’ll go in SDL12.
If I understand my version numbers right, when the SDL13 features are
considered stable enough for widespread use, I believe they’ll merge it with
the improvements in the SDL12 line to produce SDL14.

You can download the latest SDL13 source from CVS via this:

cvs -d :pserver:guest at libsdl.org:/home/sdlweb/libsdl.org/cvs co -r
branch_1_3_x SDL12

-Last one, what about SDL 2.0? a long time ago… I haven’t listened
anything about it…
I glance at it in the web CVS every once in a while hoping for progress, but
don’t see anything but the basic plans put there two years ago. Either it’s
being developed in seclusion or been abandoned in favor of just enhancing
SDL12/SDL13.On August 30, 2005 06:02 pm, Roberto Prieto wrote:

-First one, what about the integration of glSDL on SDL? When we can download
SDL with glSDL included?

SDL 1.3

-Second one, what about SDL 1.3? where I can download some white papers,
docs, source code or anything related to it?

SDL 1.3 is mostly in experimental phase with support for new things like glSDL,
audio input, etc.

-Last one, what about SDL 2.0? a long time ago… I haven’t listened
anything about it…

grin Been busy with a job and a baby, but Bob Pendleton has put some
effort into working on the multiple-window concept, which was the core
feature for SDL 2.0. I’m not sure what the status is at this point.

-Sam Lantinga, Software Engineer, Blizzard Entertainment

It’s supposedly in SDL1.3 CVS, though I haven’t been able to locate that
particular code in it.

No, it’s not in yet. I wanted to re-evaluate the pbuffer support and possibly
pull it before integrating glSDL.

I glance at it in the web CVS every once in a while hoping for progress, but
don’t see anything but the basic plans put there two years ago. Either it’s
being developed in seclusion or been abandoned in favor of just enhancing
SDL12/SDL13.

Yep, SDL12 and SDL13 are the active development branches at this point.

-Sam Lantinga, Software Engineer, Blizzard Entertainment

Anyone knows the expected timeframe for SDL 1.3? I don’t need an exact
day… I only need an estimated one…

Thanks you very much!> ----- Original Message -----

From: slouken@twomix.devolution.com (Sam Lantinga)
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Sunday, September 11, 2005 6:11 AM
Subject: Re: [SDL] Any news about…?

-First one, what about the integration of glSDL on SDL? When we can
download
SDL with glSDL included?

SDL 1.3

-Second one, what about SDL 1.3? where I can download some white papers,
docs, source code or anything related to it?

SDL 1.3 is mostly in experimental phase with support for new things like
glSDL,
audio input, etc.

-Last one, what about SDL 2.0? a long time ago… I haven’t listened
anything about it…

grin Been busy with a job and a baby, but Bob Pendleton has put some
effort into working on the multiple-window concept, which was the core
feature for SDL 2.0. I’m not sure what the status is at this point.

-Sam Lantinga, Software Engineer, Blizzard Entertainment


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

Anyone knows the expected timeframe for SDL 1.3? I don’t need an exact
day… I only need an estimated one…

Thanks you very much!

-Last one, what about SDL 2.0? a long time ago… I haven’t listened
anything about it…

grin Been busy with a job and a baby, but Bob Pendleton has put some
effort into working on the multiple-window concept, which was the core
feature for SDL 2.0. I’m not sure what the status is at this point.

-Sam Lantinga, Software Engineer, Blizzard Entertainment

Ups, and I always thought that 1.3 will be the first SDL with multiple
windows :-/

So, I second the question about possible release of 1.3 in hope, that
maybe I will also get expected release date for 2.0. Cause you know (no
surprise, heh! :wink: multiple windows are very important to me (and many
other people too, they tell me :slight_smile: so I would like to know how should I
shedule my projects.

Koshmaar

Sam Lantinga wrote:

It’s supposedly in SDL1.3 CVS, though I haven’t been able to locate that
particular code in it.
No, it’s not in yet. I wanted to re-evaluate the pbuffer support and possibly
pull it before integrating glSDL.

I’ve recently submitted patches to 1.3 to extend pbuffer support to
floating point colors, because currently the OpenGL color buffer float
extensions can only be done on a pbuffer. I wonder what happened to it. :slight_smile:

If pbuffer support will be pulled out, it might make it impossible to
support floating-point color buffers at all. I can probably think of a
hack to fake the creation of a window with floating-point colors, but
actually uses a pbuffer internally. It will be messy, though.

A possible alternative would be just to redesign the SDL pbuffer API so
that it’s out of the way of glSDL. I don’t yet understand why it would
be in glSDL’s way, though. :slight_smile: Does glSDL uses its own pbuffers to
handle SDL surfaces?–
Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/

-First one, what about the integration of glSDL on SDL? When we can download
SDL with glSDL included?

SDL 1.3

-Second one, what about SDL 1.3? where I can download some white papers,
docs, source code or anything related to it?

SDL 1.3 is mostly in experimental phase with support for new things like glSDL,
audio input, etc.

-Last one, what about SDL 2.0? a long time ago… I haven’t listened
anything about it…

grin Been busy with a job and a baby, but Bob Pendleton has put some
effort into working on the multiple-window concept, which was the core
feature for SDL 2.0. I’m not sure what the status is at this point.

I’m not working on it right now. I started back on it in the summer and
then decided to wait until 1.2.9 stabilized. On X I have support for
multiple windows, each can have its own OpenGL context. I do not yet
have support for subwindows. There are some assumptions built in to my
current version that need to be changed. The feed back I got in August
lets me back off of those assumptions.

There are major changes in the set up code to get away from some of the
most FAQ on the list. For example, SetVideoMode is now implemented in
terms of other APIs. It will continue to work as it currently does. But,
it is hoped that people will switch to using a create window API that
will fail if you ask for a video mode not supported in hardware.

Here is my latest API document:

SDL Multiple Window API
Data Type
struct SDL_PrivateWindow;
typedef struct SDL_PrivateWindow *SDL_Window;

SDL_Window SDL_OpenWindow(int width, int height, int bitsperpixel,
Uint32 flags)

Create a new top level window. The flags may be any flags that are legal
for a call to SDL_SetVideoMode() and are subject to the same
restrictions. Unlike SDL_SetVideoMode() this function fails if the
requested window is not supported by the hardware. The available video
modes for a new window may be restricted by the video mode set for the
first window. Returns NULL on failure. If a hardware or software surface
is requested it must be retrieved by a call to SDL_GetWindowSurface().

SDL_Surface *SDL_GetWindowSurface()

Get the video surface for the current hardware or software window.

SDL_Window SDL_OpenChildWindow(SDL_Window parent, int x, int y, int
width, int height)

Create a child window of an existing window. The x and y location is
relative to the upper left hand corner of the parent window. The child
window will have the same depth and other properties as the parent
window.

void *SDL_GetWindowData(SDL_Window w)
void *SDL_SetWindowData(SDL_Window w, void *data)

Store and retrieve the data stored with a window. This allows the
programmer to associate data with a window.

SDL_Window SDL_GetParentWindow(SDL_Window child)

Returns the window ID of the parent window. If the window is a top level
window then it returns NULL;

SDL_Window SDL_GetFirstChildWindow(SDL_Window parent, Uint32 *index)
SDL_Window SDL_GetNextChildWindow(SDL_Window parent, Uint32 *index)

This functions are used to access the children of a specific window.
They return the window ID of each child window. The order in which the
are returned is not necessarily the order in which the were created and
can change. Deleting or creating windows betweens calls to these
functions can change the order and cause some children to be skipped.
Both functions return NULL if all children have been examined. The index
parameter contains state information used by these functions and allows
them to be used in recursive functions that traverse a complete window
tree. Under no circumstances should the index value be relied upon to
have a specific value and it should never be changed by the programmer.

If NULL is passed as the parent parameter then these functions access
the top level windows, i.e. the windows which have no parent.

Example:

SDL_Window w = NULL;
Uint32 index;

for ( w = SDL_GetFirstChildWindow(parent, &index);
w != NULL;
w = SDL_GetNextChildWindow(parent, &index) ) {
/* do something with w */
}

void SDL_CloseWindow(SDL_Window w)

Removes a window from the screen and deletes everything associated with
the window. Works on top level windows and on child windows. All but one
top level window may be freed using this functions. Closing the last top
level window is the same as calling SDL_VideoQuit();

int SDL_SelectWindow(SDL_Window w)

Many SDL functions, especially the SDL_WM functions, SDL_Flip(),
SDL_GL_SwapBuffers(), and all OpenGLfunctions, work only on the video
window returned by SDL_SetVideoMode(). To avoid the need to create
dozens of new functions SDL_SelectWindow() is used to select the current
default window.

int SDL_WM_RaiseWindow()

If possible, raise the window so that it is above all other windows.

int SDL_WM_LowerWindow()

If possible, lower the window so that it is lower all other windows.

int SDL_WM_HideWindow()
int SDL_WM_ShowWindow()

These two functions are used to hide or display a window. This
capability is particularly important for subwindows that are used for
menus and pop ups. They make the current window disappear or appear on
the screen. When a window is shown an expose event will be generated for
that window. You may not hide the main window. The main window may be
iconified but not hidden.

int SDL_WM_DeiconifyWindow()
Restore a window that has been iconified.

int SDL_WM_MoveWindow(int x, int y)

Move the window to a new position. If it is a sub window the location is
relative to the upper left hand corner of the parent window. If it is a
top level window then it is moved relative to the upper left hand corner
of the screen. This function may have no effect on top level windows
because the window manager may override the request.

int SDL_WM_ResizeWindow(int width, int height);

Change the windows size without changing anything else about the window.
After calling this function the new video surface must be retrieved with
a call to SDL_GetWindowSurface().On Sat, 2005-09-10 at 21:11 -0700, Sam Lantinga wrote:

-Sam Lantinga, Software Engineer, Blizzard Entertainment


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


±-------------------------------------+

-First one, what about the integration of glSDL on SDL? When we can download
SDL with glSDL included?

SDL 1.3

-Second one, what about SDL 1.3? where I can download some white papers,
docs, source code or anything related to it?

SDL 1.3 is mostly in experimental phase with support for new things like glSDL,
audio input, etc.

-Last one, what about SDL 2.0? a long time ago… I haven’t listened
anything about it…

grin Been busy with a job and a baby, but Bob Pendleton has put some
effort into working on the multiple-window concept, which was the core
feature for SDL 2.0. I’m not sure what the status is at this point.

I’m not working on it right now. I started back on it in the summer and
then decided to wait until 1.2.9 stabilized. On X I have support for
multiple windows, each can have its own OpenGL context. I do not yet
have support for subwindows. There are some assumptions built in to my
current version that need to be changed. The feed back I got in August
lets me back off of those assumptions.

There are major changes in the set up code to get away from some of the
most FAQ on the list. For example, SetVideoMode is now implemented in
terms of other APIs. It will continue to work as it currently does. But,
it is hoped that people will switch to using a create window API that
will fail if you ask for a video mode not supported in hardware.

oops… Forgot to mention that all the event structures (that need them)
now have a window ID member so you can tell which window experienced the
event. That changes means that a version of SDL with these extensions
can not be binary compatible with older versions of SDL. Which tends
to force the changes to be made in SDL 2.0.

	Bob Pendleton

P.S.

I would love to be able to check my changes into cvs.On Mon, 2005-09-12 at 12:18 -0500, Bob Pendleton wrote:

On Sat, 2005-09-10 at 21:11 -0700, Sam Lantinga wrote:

Here is my latest API document:

SDL Multiple Window API
Data Type
struct SDL_PrivateWindow;
typedef struct SDL_PrivateWindow *SDL_Window;

SDL_Window SDL_OpenWindow(int width, int height, int bitsperpixel,
Uint32 flags)

Create a new top level window. The flags may be any flags that are legal
for a call to SDL_SetVideoMode() and are subject to the same
restrictions. Unlike SDL_SetVideoMode() this function fails if the
requested window is not supported by the hardware. The available video
modes for a new window may be restricted by the video mode set for the
first window. Returns NULL on failure. If a hardware or software surface
is requested it must be retrieved by a call to SDL_GetWindowSurface().

SDL_Surface *SDL_GetWindowSurface()

Get the video surface for the current hardware or software window.

SDL_Window SDL_OpenChildWindow(SDL_Window parent, int x, int y, int
width, int height)

Create a child window of an existing window. The x and y location is
relative to the upper left hand corner of the parent window. The child
window will have the same depth and other properties as the parent
window.

void *SDL_GetWindowData(SDL_Window w)
void *SDL_SetWindowData(SDL_Window w, void *data)

Store and retrieve the data stored with a window. This allows the
programmer to associate data with a window.

SDL_Window SDL_GetParentWindow(SDL_Window child)

Returns the window ID of the parent window. If the window is a top level
window then it returns NULL;

SDL_Window SDL_GetFirstChildWindow(SDL_Window parent, Uint32 *index)
SDL_Window SDL_GetNextChildWindow(SDL_Window parent, Uint32 *index)

This functions are used to access the children of a specific window.
They return the window ID of each child window. The order in which the
are returned is not necessarily the order in which the were created and
can change. Deleting or creating windows betweens calls to these
functions can change the order and cause some children to be skipped.
Both functions return NULL if all children have been examined. The index
parameter contains state information used by these functions and allows
them to be used in recursive functions that traverse a complete window
tree. Under no circumstances should the index value be relied upon to
have a specific value and it should never be changed by the programmer.

If NULL is passed as the parent parameter then these functions access
the top level windows, i.e. the windows which have no parent.

Example:

SDL_Window w = NULL;
Uint32 index;

for ( w = SDL_GetFirstChildWindow(parent, &index);
w != NULL;
w = SDL_GetNextChildWindow(parent, &index) ) {
/* do something with w */
}

void SDL_CloseWindow(SDL_Window w)

Removes a window from the screen and deletes everything associated with
the window. Works on top level windows and on child windows. All but one
top level window may be freed using this functions. Closing the last top
level window is the same as calling SDL_VideoQuit();

int SDL_SelectWindow(SDL_Window w)

Many SDL functions, especially the SDL_WM functions, SDL_Flip(),
SDL_GL_SwapBuffers(), and all OpenGLfunctions, work only on the video
window returned by SDL_SetVideoMode(). To avoid the need to create
dozens of new functions SDL_SelectWindow() is used to select the current
default window.

int SDL_WM_RaiseWindow()

If possible, raise the window so that it is above all other windows.

int SDL_WM_LowerWindow()

If possible, lower the window so that it is lower all other windows.

int SDL_WM_HideWindow()
int SDL_WM_ShowWindow()

These two functions are used to hide or display a window. This
capability is particularly important for subwindows that are used for
menus and pop ups. They make the current window disappear or appear on
the screen. When a window is shown an expose event will be generated for
that window. You may not hide the main window. The main window may be
iconified but not hidden.

int SDL_WM_DeiconifyWindow()
Restore a window that has been iconified.

int SDL_WM_MoveWindow(int x, int y)

Move the window to a new position. If it is a sub window the location is
relative to the upper left hand corner of the parent window. If it is a
top level window then it is moved relative to the upper left hand corner
of the screen. This function may have no effect on top level windows
because the window manager may override the request.

int SDL_WM_ResizeWindow(int width, int height);

Change the windows size without changing anything else about the window.
After calling this function the new video surface must be retrieved with
a call to SDL_GetWindowSurface().

-Sam Lantinga, Software Engineer, Blizzard Entertainment

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


±-------------------------------------+

not that i know anything about developing APIs, but when i first heard about
the multiple window thing tha is how i imagined doing it(
SDL_SetCurrentWindow( some_window_variable ); )

and using all the existing SDL calls to manipulate that window.

also adding the window identifier in the SDL_Events

problem was - i use SDL because i don’t want to know any os dependant
windowing code.

so i got as far as making a (MS)Windows app that could open and close an
arbitrary number of windows and gave up.

do you have somewhere we can get your code Bob, i am very interested to see
what and how you’ve done

not that i know anything about developing APIs, but when i first heard
about the multiple window thing tha is how i imagined doing
it( SDL_SetCurrentWindow( some_window_variable ); )

and using all the existing SDL calls to manipulate that window.

also adding the window identifier in the SDL_Events

Yep, that is about the only way to do it. At first I wanted to make it
at least possible (on OSes where it is possible) for different threads
to work on different windows. But, the underlying structure of SDL works
against that. Not to mention that you would have to add a window ID to
pretty much every SDL function that manipulates a window, and that
includes having to modify the entire OpenGL API.

I think the way to get multithreaded graphics support is to use
something like an internal server that serializes graphics commands
originating in different threads and keeps track of the contexts. That
way graphics would all be done through a single thread, but it would
look like multiple threads could do graphics.

	Bob Pendleton

problem was - i use SDL because i don’t want to know any os dependant
windowing code.

so i got as far as making a (MS)Windows app that could open and close
an arbitrary number of windows and gave up.

do you have somewhere we can get your code Bob, i am very interested
to see what and how you’ve done

Not really. I wish I could put it into the SDL cvs, but that doesn’t
seem to be in the cards any time soon. I am at the point where every
time I update my version against what is in CVS I have to spend several
hours editing to get it to compile again. I have had to make some pretty
serious low level changes in SDL to get this to work. And, I have only
made those changes in the X code, so all the rest of the SDL versions do
not work, and in some cases, to not compile.

	Bob PendletonOn Mon, 2005-09-12 at 22:01 +0100, Brian Barrett wrote:

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

±-------------------------------------+

Sam Lantinga wrote:

-First one, what about the integration of glSDL on SDL? When we can download
SDL with glSDL included?

SDL 1.3

-Second one, what about SDL 1.3? where I can download some white papers,
docs, source code or anything related to it?

SDL 1.3 is mostly in experimental phase with support for new things like glSDL,
audio input, etc.

So, can I send a new version against 1.3 and have it merged ?

Stephane

Sam Lantinga wrote:

It’s supposedly in SDL1.3 CVS, though I haven’t been able to locate that
particular code in it.

No, it’s not in yet. I wanted to re-evaluate the pbuffer support and possibly
pull it before integrating glSDL.

I don’t think it would conflict. But there is one thing that I don’t
like with the current render target support. I’d like to have a pure
pbuffer-like functionnality exposed, and not combined with
render-to-texture (which is implemented as glCopyTexSubImage2D on some
platforms).

Now frame buffer object makes all this outdated anyway…

Stephane

Eric Vidal wrote:

Sam Lantinga wrote:

It’s supposedly in SDL1.3 CVS, though I haven’t been able to locate
that particular code in it.

No, it’s not in yet. I wanted to re-evaluate the pbuffer support and
possibly
pull it before integrating glSDL.

I’ve recently submitted patches to 1.3 to extend pbuffer support to
floating point colors, because currently the OpenGL color buffer float
extensions can only be done on a pbuffer. I wonder what happened to
it. :slight_smile:

If pbuffer support will be pulled out, it might make it impossible to
support floating-point color buffers at all. I can probably think of a
hack to fake the creation of a window with floating-point colors, but
actually uses a pbuffer internally. It will be messy, though.

A possible alternative would be just to redesign the SDL pbuffer API so
that it’s out of the way of glSDL. I don’t yet understand why it would
be in glSDL’s way, though. :slight_smile: Does glSDL uses its own pbuffers to
handle SDL surfaces?

No. But if SDL had “portable” pbuffers, these could be used. Anyway, the
frame buffer object extension is coming in quite strong, support-wise
and is not platform-specific. So I think we’ll use that, if we ever want
to implement this features.

Stephane

I’ve recently submitted patches to 1.3 to extend pbuffer support to
floating point colors, because currently the OpenGL color buffer float
extensions can only be done on a pbuffer. I wonder what happened to it. :slight_smile:

I have your patch still.

A possible alternative would be just to redesign the SDL pbuffer API so
that it’s out of the way of glSDL. I don’t yet understand why it would
be in glSDL’s way, though. :slight_smile: Does glSDL uses its own pbuffers to
handle SDL surfaces?

glSDL doesn’t need pbuffers, Sam was saying he wants to make a decision
about yanking the RenderTarget APIs before doing anything else.
Currently, SDL 1.3’s RenderTargets abstract the platform-specifics of
pbuffers the same way SDL 1.2 abstracts general OpenGL context creation
in SDL_SetVideoMode()…but framebuffer_object sucks about a million
times less than pbuffers and doesn’t require any platform-specific code,
and would make SDL RenderTargets obsolete before they were even released.

–ryan.