Suggestions for 1.3

Here are a some suggestions and wishes for 1.3.

  1. Where ever possible replace 16 bit values with 32 bit values. This is
    especially important for the limits on the size of buffers. With video
    memory size rapidly heading toward, and soon to pass, 1GB it becomes
    perfectly reasonable to work with images that are larger than can be
    handled with 16 bit size limits. The most likely problem areas are in
    SDL_Rect where all sizes are 16 bits and in the pitch value in
    SDL_Surface that limits the actual width of a surface to 64k. The same
    problem occurs in SDL_Overlay.

  2. Add a GL context lost event. This is really needed on Windows where
    you can lose the context when certain changes are made to windows. While
    it is true that the programmer can learn when the context will be lost
    and code for it, it is much friendlier to just send an event. Simply
    having the event documented makes it much more likely that the
    programmer will know that the context can be lost. This change is an a
    concession to broken OpenGL implementations… but, reality is reality,
    lets make it as easy to live with what we have as we can.

  3. Currently SDL supports pixels up to 32 bits in depth. I think the
    color format should be extended to support pixels up to 64 bits in depth
    and surfaces should be changed to also support 64 bit pixels. IMHO SDL
    needs to support all the same depths that are currently found on video
    cards and many, if not most, currently support 64 bit pixels.

I would really like to see SDL support full floating point color and
surfaces, but that may be to much to ask at this time.

Suggestions 1 and 3 are things I believe we need to do to future proof
SDL. I think that right now we have the opportunity to think about what
future graphics, sound, and input devices are likely to look like and
add the infrastructure to SDL so that we can support them without having
to make binary incompatible changes to SDL to support them.

I haven’t made specific suggests regarding sound, and input devices
because I don’t really know enough about them to a good job. But, I
suspect that supporting sound with more bits/sample, more
samples/second, and more channels is a good start. For input device
support we might want to look at the X input extension and DirectX
device support and come up with something that will let support for new,
and some current, devices be added to SDL in a consistent way.

I’m sure there are areas in SDL that also need to be future proofed that
I haven’t even thought about.

I would really like to hear feedback on my ideas, and detailed
suggestions for other improvements.

	Bob Pendleton

P.S.

BTW, I am willing to do some of the work to implement these, and have
already tested some of the changes I’m suggesting on my own.–
±-------------------------------------+

Le Sun, 05 Feb 2006 15:02:08 -0600
Bob Pendleton a ?crit:

  1. Add a GL context lost event. This is really needed on Windows where
    you can lose the context when certain changes are made to windows. While
    it is true that the programmer can learn when the context will be lost
    and code for it, it is much friendlier to just send an event. Simply
    having the event documented makes it much more likely that the
    programmer will know that the context can be lost. This change is an a
    concession to broken OpenGL implementations… but, reality is reality,
    lets make it as easy to live with what we have as we can.

See https://bugzilla.libsdl.org/show_bug.cgi?id=40
Maybe you have already seen it? It could be done for SDL 1.2.–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux

Le Sun, 05 Feb 2006 15:02:08 -0600
Bob Pendleton <@Bob_Pendleton> a ?crit:

  1. Add a GL context lost event. This is really needed on Windows where
    you can lose the context when certain changes are made to windows. While
    it is true that the programmer can learn when the context will be lost
    and code for it, it is much friendlier to just send an event. Simply
    having the event documented makes it much more likely that the
    programmer will know that the context can be lost. This change is an a
    concession to broken OpenGL implementations… but, reality is reality,
    lets make it as easy to live with what we have as we can.

See https://bugzilla.libsdl.org/show_bug.cgi?id=40
Maybe you have already seen it? It could be done for SDL 1.2.

Certainly it can be done for 1.2 This particular suggestion has been
made many many times in the years I have been on this list. It could
have been done at any time since GL support was first conceived of for
SDL. But it hasn’t been done. My guess is that for an experience Windows
coder this is actually a very small job. But, still it hasn’t been done.
I bring it up again in the hopes that some experience Windows developer
will take on the task an hopefully get it done by 1.3.

Are you volunteering to do the work?

	Bob PendletonOn Sun, 2006-02-05 at 22:14 +0100, Patrice Mandin wrote:


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

Le Sun, 05 Feb 2006 15:53:00 -0600
Bob Pendleton a ?crit:

  1. Add a GL context lost event. This is really needed on Windows where
    you can lose the context when certain changes are made to windows. While
    it is true that the programmer can learn when the context will be lost
    and code for it, it is much friendlier to just send an event. Simply
    having the event documented makes it much more likely that the
    programmer will know that the context can be lost. This change is an a
    concession to broken OpenGL implementations… but, reality is reality,
    lets make it as easy to live with what we have as we can.

See https://bugzilla.libsdl.org/show_bug.cgi?id=40
Maybe you have already seen it? It could be done for SDL 1.2.

Certainly it can be done for 1.2 This particular suggestion has been
made many many times in the years I have been on this list. It could
have been done at any time since GL support was first conceived of for
SDL. But it hasn’t been done. My guess is that for an experience Windows
coder this is actually a very small job. But, still it hasn’t been done.
I bring it up again in the hopes that some experience Windows developer
will take on the task an hopefully get it done by 1.3.

Are you volunteering to do the work?

Hum, well, I could start writing a patch, yes.–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux

Hello !

Here are a some suggestions and wishes for 1.3.

  1. Where ever possible replace 16 bit values with 32 bit values. This is
    especially important for the limits on the size of buffers. With video
    memory size rapidly heading toward, and soon to pass, 1GB it becomes
    perfectly reasonable to work with images that are larger than can be
    handled with 16 bit size limits. The most likely problem areas are in
    SDL_Rect where all sizes are 16 bits and in the pitch value in
    SDL_Surface that limits the actual width of a surface to 64k. The same
    problem occurs in SDL_Overlay.

  2. Add a GL context lost event. This is really needed on Windows where
    you can lose the context when certain changes are made to windows. While it
    is true that the programmer can learn when the context will be lost and
    code for it, it is much friendlier to just send an event. Simply having
    the event documented makes it much more likely that the programmer will
    know that the context can be lost. This change is an a concession to
    broken OpenGL implementations… but, reality is reality, lets make it as
    easy to live with what we have as we can.

  3. Currently SDL supports pixels up to 32 bits in depth. I think the
    color format should be extended to support pixels up to 64 bits in depth
    and surfaces should be changed to also support 64 bit pixels. IMHO SDL
    needs to support all the same depths that are currently found on video
    cards and many, if not most, currently support 64 bit pixels.

I would really like to see SDL support full floating point color and
surfaces, but that may be to much to ask at this time.

Suggestions 1 and 3 are things I believe we need to do to future proof
SDL. I think that right now we have the opportunity to think about what
future graphics, sound, and input devices are likely to look like and add
the infrastructure to SDL so that we can support them without having to
make binary incompatible changes to SDL to support them.

I haven’t made specific suggests regarding sound, and input devices
because I don’t really know enough about them to a good job. But, I suspect
that supporting sound with more bits/sample, more samples/second, and more
channels is a good start. For input device support we might want to look
at the X input extension and DirectX device support and come up with
something that will let support for new, and some current, devices be
added to SDL in a consistent way.

I’m sure there are areas in SDL that also need to be future proofed that
I haven’t even thought about.

I would really like to hear feedback on my ideas, and detailed
suggestions for other improvements.

100 %

CU

Bob Pendleton wrote:

  1. Add a GL context lost event. This is really needed on Windows where
    you can lose the context when certain changes are made to windows. While
    it is true that the programmer can learn when the context will be lost
    and code for it, it is much friendlier to just send an event. Simply
    having the event documented makes it much more likely that the
    programmer will know that the context can be lost. This change is an a
    concession to broken OpenGL implementations… but, reality is reality,
    lets make it as easy to live with what we have as we can.

IIRC, the only time the OpenGL context is lost is after
SDL_SetVideoMode. In this case, SDL should always create a new OpenGL
context and teh application should always reload its textures because
there is no guarantee that any textures handled by OpenGL are still in
the optimal format for the new video mode. (For example, consider
switching from windowed mode to a 32 bit full-screen mode, with a
desktop colro depth of 16 bits.)–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com

See https://bugzilla.libsdl.org/show_bug.cgi?id=40
Maybe you have already seen it? It could be done for SDL 1.2.

There was already a patch for this a long time ago. It wasn’t implemented
because at the time SDL 1.3 had some very grandiose ideas about reworking
things so it wasn’t necessary. Now that’s no longer the case, but the
code in question has changed quite a bit since then, and for the life of
me I can’t remember who submitted it to the list. Glen Maynard rings a bell…

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Hum, yes, I know what I are a newbie in SDL, but I have some ideas…

  1. A alphabetical list of functions, no a disorderer list.
  2. Better support for AVI, MPEG, etc
  3. A GUI more complete to create and usewindows, buttons, etc . Also
    http://www.wxwidgets.org/

Only a litte idea :wink:

Hello !

  1. A GUI more complete to create and usewindows, buttons, etc . Also
    http://www.wxwidgets.org/

Okay, SDL should support multiwindows in the future,
but not should get GUI stuff. SDL = “Simple” DirectMedia Layer

Most of the GUI toolkits work were well with SDL, for example FLTK :

http://www.syntheticsw.com/~wizard/projects/fltk-demo/

CU

  1. A GUI more complete to create and usewindows, buttons, etc . Also
    http://www.wxwidgets.org/

Okay, SDL should support multiwindows in the future,
but not should get GUI stuff. SDL = “Simple” DirectMedia Layer

Most of the GUI toolkits work were well with SDL, for example FLTK :

http://www.syntheticsw.com/~wizard/projects/fltk-demo/

I think SDL should stay focused on being a thin portability library.
It should avoid implementing things like GUI toolkits within itself
just because they are nice. I like lightweight libraries.

a1

“Me too.”

I believe adding multiwindow support and some minor WM support
features (that is, what you need to make an SDL based GUI toolkit
"blend in") would be much more useful than explicit support for, or
integration of, any specific GUI toolkit.

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

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Monday 06 February 2006 08:44, mal content wrote:

  1. A GUI more complete to create and usewindows, buttons, etc .
    Also
    http://www.wxwidgets.org/

Okay, SDL should support multiwindows in the future,
but not should get GUI stuff. SDL = “Simple” DirectMedia Layer

Most of the GUI toolkits work were well with SDL, for example
FLTK :

http://www.syntheticsw.com/~wizard/projects/fltk-demo/

I think SDL should stay focused on being a thin portability library.
It should avoid implementing things like GUI toolkits within itself
just because they are nice. I like lightweight libraries.

Bob Pendleton wrote:

  1. Add a GL context lost event. This is really needed on Windows where
    you can lose the context when certain changes are made to windows. While
    it is true that the programmer can learn when the context will be lost
    and code for it, it is much friendlier to just send an event. Simply
    having the event documented makes it much more likely that the
    programmer will know that the context can be lost. This change is an a
    concession to broken OpenGL implementations… but, reality is reality,
    lets make it as easy to live with what we have as we can.

IIRC, the only time the OpenGL context is lost is after
SDL_SetVideoMode. In this case, SDL should always create a new OpenGL
context and teh application should always reload its textures because
there is no guarantee that any textures handled by OpenGL are still in
the optimal format for the new video mode.

Don’t you also lose all retained structures as well as the stacked
context information?

Either way, it sounds like this problem can be fixed with a very small
patch.

(For example, consider
switching from windowed mode to a 32 bit full-screen mode, with a
desktop colro depth of 16 bits.)

Bob PendletonOn Sun, 2006-02-05 at 16:57 -0700, Rainer Deyke wrote:


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

See https://bugzilla.libsdl.org/show_bug.cgi?id=40
Maybe you have already seen it? It could be done for SDL 1.2.

There was already a patch for this a long time ago. It wasn’t implemented
because at the time SDL 1.3 had some very grandiose ideas about reworking
things so it wasn’t necessary.

Yeah, I keep getting the temptation to put a wrapper around OpenGL to
manage all of keep track of the content of the OpenGL context, and then
I look at how many function definitions there are in OpenGL and I think
"no, that’s not going to happen…". :slight_smile:

	Bob PendletonOn Sun, 2006-02-05 at 22:09 -0800, Sam Lantinga wrote:

Now that’s no longer the case, but the
code in question has changed quite a bit since then, and for the life of
me I can’t remember who submitted it to the list. Glen Maynard rings a bell…

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment


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


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

Le Sun, 05 Feb 2006 22:09:33 -0800
Sam Lantinga a ?crit:

See https://bugzilla.libsdl.org/show_bug.cgi?id=40
Maybe you have already seen it? It could be done for SDL 1.2.

There was already a patch for this a long time ago. It wasn’t
implemented because at the time SDL 1.3 had some very grandiose ideas
about reworking things so it wasn’t necessary. Now that’s no longer
the case, but the code in question has changed quite a bit since then,
and for the life of me I can’t remember who submitted it to the list.
Glen Maynard rings a bell…

OK, here is the small patch. I add a new flag for the SDL_Surface screen
flag. The flag is cleared before calling any _SetVideoMode. Then
it is the responsibility of the driver to set the flag if the OpenGL
context has been kept (not destroyed). I added the small patch for the
x11 driver. Then, the application can check this bit to see if the
OpenGL context has been destroyed or not. So now we can have:

  • Old applications with new SDL: Don’t care about the bit
  • New applications with old SDL: Always see the bit as zero, so behave
    the same.
  • New applications with new SDL: What we intended.

Both windib and windx5 always destroy the context, I don’t know about
other video drivers. At least, for my part (using OSMesa on Atari),
simply resizing the context does not destroy it, so I will do this part
myself.

Also, it seems there is no need for a special event, as SDL_VIDEORESIZE
only tell about the new size, and the application must call
SDL_SetVideoMode().

Of course, any comments are welcomed.–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: oglctx.diff
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060206/8564ad63/attachment.txt

A thing I’ve been a bit annoyed about, is the inconsistence in naming of
types, e.g. SDL_Surface vs SDL_mutex. OTOH, I guess this could be easily
fixed with a #define or typedef already in 1.2 without too much hassle.

Or is this a feature and not a bug? Please enlighten me. :slight_smile:

// Martin

Hey

I would wery much like a way to enumerate soundcards, like it is possible
with CD drives and joysticks.
It is nice to let the user choose witch soundcard to use in an app.

In other words:
int SDL_NumAudioDevs()
const char *AudioDevName(int index)
SDL_AudioSpec *SLD_AudioDevCap(int index)
int SDL_OpenAudio(int index)

-Martin