SDL2.0 wish-list

SDL Development
1

I am just curious of what we can hope for in SDL2. Is there any
timeline anywhere? Or better yet design draft?

Here is my personal wish list:

  • Keeping the C-level of the library and the general
    "minimalistic/clean" API of SDL
  • Dropping backward-source-level sdl<2 compatibility if so needed
  • Multiple display surfaces - at least one with OpenGL support
  • ForceFeedback-support
  • Multiple mouse support or in general no assumptions on the number of
    devices of things (keyboard, mouse, screens, …)
  • A little more vaguely: Support for newer multimedia hardware like
    webcameras etc. - a grabbing interface

I know the above will “cumber down” the API somewhat, both for API
implementor and user, but is there any other way to keep up with
contemporary hardware?

/Olof

2

Olof Bjarnason wrote:

  • Multiple mouse support or in general no assumptions on the number of
    devices of things (keyboard, mouse, screens, …)

Also, support for pressure sensitive stuff! Tilt and rotation would be
nice too…

  • Gerry
3

I am just curious of what we can hope for in SDL2. Is there any
timeline anywhere? Or better yet design draft?

Here is my personal wish list:

  • Keeping the C-level of the library and the general
    "minimalistic/clean" API of SDL
  • Dropping backward-source-level sdl<2 compatibility if so needed
  • Multiple display surfaces - at least one with OpenGL support
  • ForceFeedback-support
  • Multiple mouse support or in general no assumptions on the number of
    devices of things (keyboard, mouse, screens, …)
  • A little more vaguely: Support for newer multimedia hardware like
    webcameras etc. - a grabbing interface
  • Multiple windows
  • Supported API for integrating with the native GUI API
  • Supported API for integrating with wxWigdets
  • Sound input
  • Backend and blitter plugins

-bobOn Feb 25, 2005, at 11:01 AM, Olof Bjarnason wrote:

4

Hi,

  • A little more vaguely: Support for newer multimedia hardware like
    webcameras etc. - a grabbing interface

This sounds like something useful now, for example in an extension
library. I know there’s a cross-platform audio-in library in development
(?), and I recall a video4linux library for SDL, but what would be
really neat is an abstract, cross-platform video-in solution. Has anyone
done anything in this direction?

Home-brew EyeToy, here we come !-)

Benjamin Deutsch

5

I am just curious of what we can hope for in SDL2. Is there any
timeline anywhere? Or better yet design draft?

Here is my personal wish list:

  • Keeping the C-level of the library and the general
    "minimalistic/clean" API of SDL
  • Dropping backward-source-level sdl<2 compatibility if so needed
  • Multiple display surfaces - at least one with OpenGL support
  • ForceFeedback-support
  • Multiple mouse support or in general no assumptions on the number of
    devices of things (keyboard, mouse, screens, …)
  • A little more vaguely: Support for newer multimedia hardware like
    webcameras etc. - a grabbing interface
  • Multiple windows
  • Supported API for integrating with the native GUI API
  • Supported API for integrating with wxWigdets

I have to admit that I don’t understand the desire to integrate SDL into
a GUI window. All of the GUIs you mention have 2D graphic APIs and they
all have a 3D pane of some sort. They all have an input API… If you
want to program using those GUIs why don’t you just use the whole GUI
and avoid the problems of trying to integrate SDL into them? Can someone
educate me on this?

  • Sound input

I would like to see this one too.

  • Backend and blitter plugins

Can you give more details on what a backend/blitter pluging would be
used for? I ask because the SDL backend is handcrafted for each platform
and the blitter code is (usually) handcrafted for the platform. So, I
don’t get your point and I would like to understand what you mean.

	Bob PendletonOn Fri, 2005-02-25 at 12:05 -0500, Bob Ippolito wrote:

On Feb 25, 2005, at 11:01 AM, Olof Bjarnason wrote:

-bob

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

6

I am just curious of what we can hope for in SDL2. Is there any
timeline anywhere? Or better yet design draft?

Here is my personal wish list:

  • Keeping the C-level of the library and the general
    "minimalistic/clean" API of SDL

I can’t imagine that anyone would dare to mess up the SDL API. It is
just too clean and easy to use.

Keeping it in C makes is possible for people who like different styles
of programming to wrap it any way they want.

  • Dropping backward-source-level sdl<2 compatibility if so needed

Don’t worry.

  • Multiple display surfaces - at least one with OpenGL support

That is being worked on. It is turning out to be a lot tougher than
expected. But, it is being worked on. Even after the first few platforms
are completed it will take a while for all platforms to be converted.
The idea that there is only one window is coded deeply into the heart of
SDL.

  • ForceFeedback-support

That would be nice to see. AFAIK there is a real need for someone(s) to
work on the Linux support for modern input devices.

  • Multiple mouse support or in general no assumptions on the number of
    devices of things (keyboard, mouse, screens, …)

I would like to see that too. I don’t know about windows, but X11 has
had an extension for handling multiple input devices for about 15 years,
so there is a standard way to detect and access multiple input devices.
Of course, that means that people have to actually implement the code in
X to identify and use those devices. Seriously, you should be able to
access multiple joysticks and drive force feedback and rumble packs
through X11. Oh Well…

  • A little more vaguely: Support for newer multimedia hardware like
    webcameras etc. - a grabbing interface

I would like to see that too.

I know the above will “cumber down” the API somewhat, both for API
implementor and user, but is there any other way to keep up with
contemporary hardware?

Nope, not other way.

So… Olof, which parts are you going to start working on?

	Bob PendletonOn Fri, 2005-02-25 at 17:01 +0100, Olof Bjarnason wrote:

/Olof

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

7
  • Sound input
    I would like to see that too, I’m willing to help if needed.
8

I am just curious of what we can hope for in SDL2. Is there any
timeline anywhere? Or better yet design draft?

Here is my personal wish list:

  • Keeping the C-level of the library and the general
    "minimalistic/clean" API of SDL
  • Dropping backward-source-level sdl<2 compatibility if so needed
  • Multiple display surfaces - at least one with OpenGL support
  • ForceFeedback-support
  • Multiple mouse support or in general no assumptions on the number
    of
    devices of things (keyboard, mouse, screens, …)
  • A little more vaguely: Support for newer multimedia hardware like
    webcameras etc. - a grabbing interface
  • Multiple windows
  • Supported API for integrating with the native GUI API
  • Supported API for integrating with wxWigdets

I have to admit that I don’t understand the desire to integrate SDL
into
a GUI window. All of the GUIs you mention have 2D graphic APIs and they
all have a 3D pane of some sort. They all have an input API… If you
want to program using those GUIs why don’t you just use the whole GUI
and avoid the problems of trying to integrate SDL into them? Can
someone
educate me on this?

It’s not so much that SDL should integrate into a GUI window, but that
SDL should be able to exist in the same application as one. SDL might
have faster blitters or a nicer input API than ,
or you might be recycling existing SDL code into a larger application.
You might need the sound APIs or joystick input APIs that does not have. Maybe you need to add some dialogs to your
application that need to do things that SDL has no support for at all,
but does with very little effort?

Extending existing applications with SDL based material is definitely a
use case for the view stuff, though. Let’s say you had to make
something that worked as a plug-in, and you wanted to use SDL because
it’s what you know, or what you like, or because you’re reusing
existing code?

  • Backend and blitter plugins

Can you give more details on what a backend/blitter pluging would be
used for? I ask because the SDL backend is handcrafted for each
platform
and the blitter code is (usually) handcrafted for the platform. So, I
don’t get your point and I would like to understand what you mean.

It’d just be nice to be able to load new blitter code into SDL on the
fly. For example, I’ve been working on a patch to add Altivec
accelerated blitters to SDL, and it’s a pain to have to recompile SDL
every time I want to change something. It will be a pain to get the
patches merged upstream, and it will be a pain to maintain my own fork
of SDL until it does. It would be a lot easier to say “hey, download
this .so and put it inside your (official) SDL framework and your
application will run at least 3x faster on computers with altivec”.

All of the tests for the blitters are coming out of a function table
anyway, there’s no particularly good reason this code has to live
inside of SDL_blit_[NA].c. These source files are also horrifyingly
ugly and long right now, and will continue to get uglier with each
optimization.

As for backends, wouldn’t it have been nice if glSDL could’ve just
plugged right into SDL as-is?

-bobOn Feb 25, 2005, at 3:07 PM, Bob Pendleton wrote:

On Fri, 2005-02-25 at 12:05 -0500, Bob Ippolito wrote:

On Feb 25, 2005, at 11:01 AM, Olof Bjarnason wrote:

9

I am just curious of what we can hope for in SDL2. Is there any
timeline anywhere? Or better yet design draft?

Here is my personal wish list:

  • Keeping the C-level of the library and the general
    "minimalistic/clean" API of SDL
  • Dropping backward-source-level sdl<2 compatibility if so needed
  • Multiple display surfaces - at least one with OpenGL support
  • ForceFeedback-support
  • Multiple mouse support or in general no assumptions on the number
    of
    devices of things (keyboard, mouse, screens, …)
  • A little more vaguely: Support for newer multimedia hardware like
    webcameras etc. - a grabbing interface
  • Multiple windows
  • Supported API for integrating with the native GUI API
  • Supported API for integrating with wxWigdets

I have to admit that I don’t understand the desire to integrate SDL
into
a GUI window. All of the GUIs you mention have 2D graphic APIs and they
all have a 3D pane of some sort. They all have an input API… If you
want to program using those GUIs why don’t you just use the whole GUI
and avoid the problems of trying to integrate SDL into them? Can
someone
educate me on this?

It’s not so much that SDL should integrate into a GUI window, but that
SDL should be able to exist in the same application as one. SDL might
have faster blitters or a nicer input API than ,
or you might be recycling existing SDL code into a larger application.
You might need the sound APIs or joystick input APIs that does not have. Maybe you need to add some dialogs to your
application that need to do things that SDL has no support for at all,
but does with very little effort?

Extending existing applications with SDL based material is definitely a
use case for the view stuff, though. Let’s say you had to make
something that worked as a plug-in, and you wanted to use SDL because
it’s what you know, or what you like, or because you’re reusing
existing code?

  • Backend and blitter plugins

Can you give more details on what a backend/blitter pluging would be
used for? I ask because the SDL backend is handcrafted for each
platform
and the blitter code is (usually) handcrafted for the platform. So, I
don’t get your point and I would like to understand what you mean.

It’d just be nice to be able to load new blitter code into SDL on the
fly. For example, I’ve been working on a patch to add Altivec
accelerated blitters to SDL, and it’s a pain to have to recompile SDL
every time I want to change something. It will be a pain to get the
patches merged upstream, and it will be a pain to maintain my own fork
of SDL until it does. It would be a lot easier to say “hey, download
this .so and put it inside your (official) SDL framework and your
application will run at least 3x faster on computers with altivec”.

All of the tests for the blitters are coming out of a function table
anyway, there’s no particularly good reason this code has to live
inside of SDL_blit_[NA].c. These source files are also horrifyingly
ugly and long right now, and will continue to get uglier with each
optimization.

As for backends, wouldn’t it have been nice if glSDL could’ve just
plugged right into SDL as-is?

That makes very good sense. Thanks for clarifying that for me.

	Bob PendletonOn Fri, 2005-02-25 at 15:50 -0500, Bob Ippolito wrote:

On Feb 25, 2005, at 3:07 PM, Bob Pendleton wrote:

On Fri, 2005-02-25 at 12:05 -0500, Bob Ippolito wrote:

On Feb 25, 2005, at 11:01 AM, Olof Bjarnason wrote:

-bob

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

10

… and makes it easy to port to: handheld game systems, bigger game consoles,
cellphones, PDAs, older computer architectures/OSes, etc. ;^)

-bill!On Fri, Feb 25, 2005 at 02:19:03PM -0600, Bob Pendleton wrote:

Keeping it in C makes is possible for people who like different styles
of programming to wrap it any way they want.

11

Keeping it in C makes is possible for people who like different styles
of programming to wrap it any way they want.

… and makes it easy to port to: handheld game systems, bigger game consoles,
cellphones, PDAs, older computer architectures/OSes, etc. ;^)

Yes! Portability is one of the main reasons why people write new code in
C. Other highly portable languages get their portability by being
written in C :slight_smile: C may not be “perfect” but it has become the closest
thing to a universal assembly language that has ever existed.

	Bob PendletonOn Fri, 2005-02-25 at 15:02 -0800, Bill Kendrick wrote:

On Fri, Feb 25, 2005 at 02:19:03PM -0600, Bob Pendleton wrote:

-bill!

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

12

All of the tests for the blitters are coming out of a function table
anyway, there’s no particularly good reason this code has to live
inside of SDL_blit_[NA].c. These source files are also horrifyingly
ugly and long right now, and will continue to get uglier with each
optimization.

I agree we should clean this up, but I don’t really see a value in
exposing the mechanism. The hypothetical of “here’s a faster blitter you
can drop in” should just get included in SDL, rather than per-application.

–ryan.

13
  • Keeping the C-level of the library and the general
    "minimalistic/clean" API of SDL
  • Dropping backward-source-level sdl<2 compatibility if so needed

Being 100% thread-safe would be good! Passing some
sort of SDL instance pointer into every function would
go a long way toward having thread-safety.

Correct alpha blending would be great for Tux Paint.
When non-linear sRGB image data is crudely blended as
if it were linear, the result comes out too dark. The
hue can even change.

Floating-point surfaces would help reduce error.

Sadly, I must remind people of Second System Syndrome,
also known as Second System Effect. It’s from a book
by Fred Brooks, “The Mythical Man Month”. It is always
tempting to throw out lots of valuable old code to get
a fresh clean start, but featuritis quickly leads to
inclusion of the kitchen sink. It may be better to keep
hacking away at the old code, even if it does seem icky.On Fri, 2005-02-25 at 17:01 +0100, Olof Bjarnason wrote:

14
  • Keeping the C-level of the library and the general
    "minimalistic/clean" API of SDL
  • Dropping backward-source-level sdl<2 compatibility if so needed

Being 100% thread-safe would be good! Passing some
sort of SDL instance pointer into every function would
go a long way toward having thread-safety.

Making every function re-entrant with mutexes and stuff would probably
just make it slower and harder to debug, and it wouldn’t fix the issue
that many of the underlying event systems and GUIs expect operations to
happen in particular thread(s). I’m not really sure that would be a
win at all.

Getting rid of any global state would be a really good idea, though.

Correct alpha blending would be great for Tux Paint.
When non-linear sRGB image data is crudely blended as
if it were linear, the result comes out too dark. The
hue can even change.

That sounds like a hard problem… SDL doesn’t even have the concept of
color spaces. It might be better to do this as an extension like
SDL_image, since I don’t think most people would want/need this kind of
functionality given what people are currently using SDL for.

Even the linear alpha blending in SDL is crude, it does it the "cheap"
way by dividing by 256, not 255. The Altivec patches I’m working on do
correct linear alpha blending, but only if you have a PowerPC with
Altivec.

Floating-point surfaces would help reduce error.

Floating-point surfaces would be great, but the problem with that is
that you’ve doubled the memory bandwidth you need (compared to ARGB
32bit), and you’ll probably more or less need SIMD in order to do blits
with these surfaces at an acceptable speed.

-bobOn Feb 25, 2005, at 11:48 PM, Albert Cahalan wrote:

On Fri, 2005-02-25 at 17:01 +0100, Olof Bjarnason wrote:

15

Being 100% thread-safe would be good! Passing some
sort of SDL instance pointer into every function would
go a long way toward having thread-safety.

God, no.

Whether we break compatibility or not, let’s not guarantee that every
existing SDL app will need fixing.

–ryan.

16

I’d wish for openGL compatible format enums so that GL_RGB,GL_UNSIGNED_SHORT_5_6_5 would become the same pixel format in SDL.
I say this for being more easily direct with code, instead of having to check endianess for RGB vs. BGR ordering…
also it would help define the commonly used formats for easy use.
this might be a seperate function from SDL_CreateRGBSurface, or a #define trick…
I’ve been thinking of doing this in SDL1.2 as an addon, but it wouldn’t get the same integration there.

And I hear there’s support for the gl pbuffer extension…
where a surface’s pixels are already a texture…
if so, it should be in 2.0 too!

-LIM-

17

Albert Cahalan wrote:

Passing some
sort of SDL instance pointer into every function would
go a long way toward having thread-safety.

No, it wouldn’t. Passing a global SDL instance pointer around is no safer
than the implict global state in the current design, and giving each thread
its own SDL instance won’t accomplish anything that can’t be accomplished
right now with separate processes.

It would be nice if it was safe to call all SDL functions from different
threads, so long as only one thread calls an SDL function at any one time.
It would even be nice if certain functions that do not affect the implicit
global that were made reentrant and documented as such. Anything more is
better done at a higher level.–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com

18
  • Keeping the C-level of the library and the general
    "minimalistic/clean" API of SDL
  • Dropping backward-source-level sdl<2 compatibility if so needed

Being 100% thread-safe would be good! Passing some
sort of SDL instance pointer into every function would
go a long way toward having thread-safety.

Making every function re-entrant with mutexes and stuff would probably
just make it slower and harder to debug, and it wouldn’t fix the issue
that many of the underlying event systems and GUIs expect operations to
happen in particular thread(s). I’m not really sure that would be a
win at all.

If some GUI is defective enough to require that operations happen
in a particular thread, simply document this limitation. Then the
app developers can judge for themselves whether or not that GUI is
worth supporting.

Correct alpha blending would be great for Tux Paint.
When non-linear sRGB image data is crudely blended as
if it were linear, the result comes out too dark. The
hue can even change.

That sounds like a hard problem… SDL doesn’t even have the concept of
color spaces.

It’s not seriously getting into color spaces. It’s just a matter
of changing the way the pixel data maps to brightness.

It might be better to do this as an extension like
SDL_image, since I don’t think most people would want/need this kind of
functionality given what people are currently using SDL for.

Current use of SDL includes: Tux Paint, a drawing program

Painting a fuzzy yellow line on a blue background gives
ugly dark borders around the line. This is because SDL
does not do alpha blending correctly.

Even the linear alpha blending in SDL is crude, it does it the "cheap"
way by dividing by 256, not 255. The Altivec patches I’m working on do
correct linear alpha blending, but only if you have a PowerPC with
Altivec.

Correct, or simply not as horrible?

Correct means a lookup table. (or some very slow math!)

Floating-point surfaces would help reduce error.

Floating-point surfaces would be great, but the problem with that is
that you’ve doubled the memory bandwidth you need (compared to ARGB
32bit), and you’ll probably more or less need SIMD in order to do blits
with these surfaces at an acceptable speed.

I’d do this by looking up the top 16 bits (of the float!) in a table.
That gets you the sign bit, exponent, one (free), and 7 fraction bits.
Better yet, shift out the sign bit first to get another fraction bit.On Sat, 2005-02-26 at 00:40 -0500, Bob Ippolito wrote:

On Feb 25, 2005, at 11:48 PM, Albert Cahalan wrote:

On Fri, 2005-02-25 at 17:01 +0100, Olof Bjarnason wrote:

19

my votes:
improve SDL blit performance

  • Auto-manage software back buffer surface for better
    performance on fullscreen hardware blits
  • Mechanism to handle dirty rectangles within SDL

Right now its not “simple” to do well performing 2D in
SDL. Would be nice to free us of these complex chores.

-Jason Robertson__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

20
  • Keeping the C-level of the library and the general
    "minimalistic/clean" API of SDL
  • Dropping backward-source-level sdl<2 compatibility if so needed

Being 100% thread-safe would be good! Passing some
sort of SDL instance pointer into every function would
go a long way toward having thread-safety.

Making every function re-entrant with mutexes and stuff would probably
just make it slower and harder to debug, and it wouldn’t fix the issue
that many of the underlying event systems and GUIs expect operations
to
happen in particular thread(s). I’m not really sure that would be a
win at all.

If some GUI is defective enough to require that operations happen
in a particular thread, simply document this limitation. Then the
app developers can judge for themselves whether or not that GUI is
worth supporting.

Mac OS X requires that all operations related to the GUI be serialized
to the main thread, with few exceptions.

Even the linear alpha blending in SDL is crude, it does it the "cheap"
way by dividing by 256, not 255. The Altivec patches I’m working on
do
correct linear alpha blending, but only if you have a PowerPC with
Altivec.

Correct, or simply not as horrible?

Correct means a lookup table. (or some very slow math!)

The algorithm I’m using is ((src * alpha) + (dst * (255 - alpha))) /
255. This is, by definition, correct linear alpha blending (at 8 bits
precision). Technically it’s implemented more like this:

tmp = (1 + (src * alpha) + (dst * (255 - alpha)))
res = (tmp + (tmp >> 8)) >> 8

But that is equivalent to dividing by 255 for every possible value you
could generate here [0, 255*255].

Slow math? My Altivec per-pixel alpha blit is not only correct, but is
several times faster than the incorrect scalar implementation. A
lookup table slows you down when your bottleneck isn’t the CPU.

-bobOn Feb 26, 2005, at 7:47 AM, Albert Cahalan wrote:

On Sat, 2005-02-26 at 00:40 -0500, Bob Ippolito wrote:

On Feb 25, 2005, at 11:48 PM, Albert Cahalan wrote:

On Fri, 2005-02-25 at 17:01 +0100, Olof Bjarnason wrote: