[gsoc] Application proposal suggestion (SDL++)

SDL Development
1

Hello,

I’m interested in participating in GSoC with SDL as my mentor
organization. However, I feel that my proposal would be rejected
because it completely is not in line with the rest of the proposals.
I’d like to know if there is any interest at all in such a proposal. I
asked this question on #sdl on IRC, and got an answer to post it to
the group. If there is an initial “we’re interested”, I’d prepare a
much more detailed description.

The basic idea is to create a standard C++/STL based platform and
compiler independent wrapper for SDL. There are several attempts on
the web, but none of them are complete, and the quality varies widely.
I’m perfectly aware that one of SDL’s main advantages is the C API
that allows it to be linked to various programming languages, still I
believe that SDL would benefit from a standard C++ interface. The
design goals for the wrapper that I’d like to achieve are:

  • modern C++ standards – making use of STL and it’s paradigms
  • ultra-portable – both from architecture and compiler point of view
  • lightweight – the wrapper should allow as effective usage as using
    the standard headers
  • very well documented ( doxygen, UML diagrams and tutorials )
  • unified and readable coding conventions and usage
  • wrapping all the SDL structures into classes
  • the wrapper itself could handle memory ( for example keeping a
    surface manager )
  • written also with OpenGL in mind
  • wrapping also the most common SDL libraries ( mixer, image, … ) in
    the same style
  • both 1.2 and 1.3 versions ( if time allows, if not, I’d focus on the
    one of the communities choice )

I’d be willing to discuss this idea in far greater detail if there is
any interest.–
regards,
Kornel Kisielewicz
http://chaosforge.org/

2
  • lightweight – the wrapper should allow as effective usage as using
    the standard headers

I think it might be possible to do this entirely in header files (like
much of Boost, for example), so that when compiling with
optimizations, the C++ wrapping would basically disappear, by getting
fully inlined, if you’re careful. This would both preserve the
performance, and simplify distribution (as far as the runtime linker
is concerned, this would be using the C SDL API, with all of it’s
backward compatibility features).

Might need to license those headers under something really loose like
a two-clause BSD license, though, to avoid licensing headaches (that
code would pretty much be integrated into the binaries using them, I’m
not up on the legal situation of that stuff).

  • the wrapper itself could handle memory ( for example keeping a
    surface manager )

I can definitely imagine a class acting as a smart pointer specialized
for SDL_Surface, for example, which could make memory management
really, really easy. Although you might want to skip wrapping the
"legacy" 1.2 API and go straight to 1.3.

  • wrapping also the most common SDL libraries ( mixer, image, … ) in
    the same style

That would probably need to go with these projects, I guess (it’d be
sort of strange to have some headers for SDL_mixer in SDL itself?).

  • both 1.2 and 1.3 versions ( if time allows, if not, I’d focus on the
    one of the communities choice )

I’d recommend sticking to 1.3, it doesn’t look like much of interest
is going to happen with 1.2…

Of course, I’m not speaking for the “SDL community”, just my opinions here.On Wed, Apr 1, 2009 at 2:37 PM, Kornel Kisielewicz <kornel.kisielewicz at gmail.com> wrote:

–
http://pphaneuf.livejournal.com/

3

I don’t think that a simple wrapper where for example surface-drawing
"C" function calls are somehow “stuck” into class Surface is all that
valuable. That is, the sort of stuff that can be accomplished via
header files alone.

A key thing to consider is that additional value is created from a
wrapper by creating an abstraction layer. That’s a term that is
bandied about a lot but often not truly understood. An abstraction
layer provides a simpler yet possibly more powerful interface to a
more complex underlying interface. So just having a 1-to-1
translation between C++ and C is not an abstraction layer.

What intrigues me about your proposal is integration of SDL with STL.
A long time ago, I did something similar; I integrated STL with MFC
(Microsoft Foundation Classes – their old gui interface). Basically
the idea was that the programmer used the STL APIs (say to manipulate
a list), and this list was “magically” connected to a GUI element; a
combo box, selection box, tree, you name it. So if you change the
list, the GUI element changed on the screen, and so forth.

The idea was that you could basically manipulate the whole GUI using
STL APIs, and the only time you had to actually deal with MFC GUI was
the initial layout. So I call this an “abstraction layer” since the
basic STL container APIs are much simpler (and consistent, and
well-known) than that horrible thing we used to call MFC. :slight_smile:

I wonder if something along those lines can be created for SDL?

Disclaimer: I’m just a dev using SDL so don’t really have any input
into GSoC mentoring…

Regards,
AndrewOn Wed, Apr 1, 2009 at 2:37 PM, Kornel Kisielewicz <kornel.kisielewicz at gmail.com> wrote:

Hello,

I’m interested in participating in GSoC with SDL as my mentor
organization. However, I feel that my proposal would be rejected
because it completely is not in line with the rest of the proposals.
I’d like to know if there is any interest at all in such a proposal. I
asked this question on #sdl on IRC, and got an answer to post it to
the group. If there is an initial “we’re interested”, I’d prepare a
much more detailed description.

The basic idea is to create a standard C++/STL based platform and
compiler independent wrapper for SDL. There are several attempts on
the web, but none of them are complete, and the quality varies widely.
I’m perfectly aware that one of SDL’s main advantages is the C API
that allows it to be linked to various programming languages, still I
believe that SDL would benefit from a standard C++ interface. The
design goals for the wrapper that I’d like to achieve are:

  • modern C++ standards – making use of STL and it’s paradigms
  • ultra-portable – both from architecture and compiler point of view
  • lightweight – the wrapper should allow as effective usage as using
    the standard headers
  • very well documented ( doxygen, UML diagrams and tutorials )
  • unified and readable coding conventions and usage
  • wrapping all the SDL structures into classes
  • the wrapper itself could handle memory ( for example keeping a
    surface manager )
  • written also with OpenGL in mind
  • wrapping also the most common SDL libraries ( mixer, image, … ) in
    the same style
  • both 1.2 and 1.3 versions ( if time allows, if not, I’d focus on the
    one of the communities choice )

I’d be willing to discuss this idea in far greater detail if there is
any interest.

regards,
Kornel Kisielewicz
http://chaosforge.org/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4
  • lightweight – the wrapper should allow as effective usage as using
    the standard headers

I think it might be possible to do this entirely in header files (like
much of Boost, for example), so that when compiling with
optimizations, the C++ wrapping would basically disappear, by getting
fully inlined, if you’re careful. This would both preserve the
performance, and simplify distribution (as far as the runtime linker
is concerned, this would be using the C SDL API, with all of it’s
backward compatibility features).

That’s exactly what I was thinking about actually :). That would also
drasticly increase deployment ease. The C++ headers themselves would
of course be under the same licence as normal headers.

Might need to license those headers under something really loose like
a two-clause BSD license, though, to avoid licensing headaches (that
code would pretty much be integrated into the binaries using them, I’m
not up on the legal situation of that stuff).

If we use the same licence as the normal headers do there wouldn’t be
any more problems wouldn’t there?

  • the wrapper itself could handle memory ( for example keeping a
    surface manager )

I can definitely imagine a class acting as a smart pointer specialized
for SDL_Surface, for example, which could make memory management
really, really easy. Although you might want to skip wrapping the
"legacy" 1.2 API and go straight to 1.3.

If that would be better seen, I’d probably do that. Yes, that’s one of
the major things that made me think about a wrapper actually.

  • wrapping also the most common SDL libraries ( mixer, image, … ) in
    the same style

That would probably need to go with these projects, I guess (it’d be
sort of strange to have some headers for SDL_mixer in SDL itself?).

Of course, but as I understand, SDL_mixer is still part of SDL, or am I wrong?On Wed, Apr 1, 2009 at 8:55 PM, Pierre Phaneuf wrote:

On Wed, Apr 1, 2009 at 2:37 PM, Kornel Kisielewicz <@Kornel_Kisielewicz> wrote:
–
regards,
Kornel Kisielewicz

5

I don’t think that a simple wrapper where for example surface-drawing
"C" function calls are somehow “stuck” into class Surface is all that
valuable. ?That is, the sort of stuff that can be accomplished via
header files alone.

Most serious project that use SDL wrap it up into C++ classes anyway,
so there must be a reason :).

A key thing to consider is that additional value is created from a
wrapper by creating an abstraction layer. ?That’s a term that is
bandied about a lot but often not truly understood. ?An abstraction
layer provides a simpler yet possibly more powerful interface to a
more complex underlying interface. ?So just having a 1-to-1
translation between C++ and C is not an abstraction layer.

In this case this would be a true abstraction layer, because it could
hide internally things that are not needed, yet still retaining the
possibility of using them if the user explicitly desires them.

The idea was that you could basically manipulate the whole GUI using
STL APIs, and the only time you had to actually deal with MFC GUI was
the initial layout. ?So I call this an “abstraction layer” since the
basic STL container APIs are much simpler (and consistent, and
well-known) than that horrible thing we used to call MFC. :slight_smile:

I can imagine ^_^.

I wonder if something along those lines can be created for SDL?

My initial idea was to write the API the way that it seamlessly can be
used with ( and uses ) STL algorithms and data structures. However
what you wrote made me think how far I could take that…On Wed, Apr 1, 2009 at 9:33 PM, Andrew Stone <g.andrew.stone at gmail.com> wrote:

regards,
Kornel Kisielewicz

6

SDL_mixer is its own library, which depends on libSDL (as well as various
libs that allow it to decode and play the various audio and music formas.)

(Just as SDL_image is its own library, which depends on libSDL, libPNG,
libJPEG, etc.)On Wed, Apr 01, 2009 at 09:34:28PM +0200, Kornel Kisielewicz wrote:

Of course, but as I understand, SDL_mixer is still part of SDL, or am I wrong?

–
-bill!
“Tux Paint” - free children’s drawing software for Windows / Mac OS X / Linux!
Download it today! http://www.tuxpaint.org/

7

Hmm, in that case some mechanism should be devised to easily extend
the C++ API with additional managed functionality from other
libraries.On Wed, Apr 1, 2009 at 9:39 PM, Bill Kendrick wrote:

On Wed, Apr 01, 2009 at 09:34:28PM +0200, Kornel Kisielewicz wrote:

Of course, but as I understand, SDL_mixer is still part of SDL, or am I wrong?

SDL_mixer is its own library, which depends on libSDL (as well as various
libs that allow it to decode and play the various audio and music formas.)

(Just as SDL_image is its own library, which depends on libSDL, libPNG,
libJPEG, etc.)

–
regards,
Kornel Kisielewicz

8

Might need to license those headers under something really loose like
a two-clause BSD license, though, to avoid licensing headaches (that
code would pretty much be integrated into the binaries using them, I’m
not up on the legal situation of that stuff).

If we use the same licence as the normal headers do there wouldn’t be
any more problems wouldn’t there?

What I’m thinking about is this: http://lwn.net/Articles/315251/

Basically, the LGPL requires you to distribute your code in a way
where the end-user can replace the LGPL’d code with his own modified
version. As C++ templates get “baked in”, this is simply not possible
(you can’t put templates in a DLL, they don’t even have .cc files!)…

But it’d be a cinch to just put those headers only under a really
liberal license like the two-clause BSD
(http://techbase.kde.org/Policies/Licensing_Policy#BSD_License) that
basically says “do whatever you want, as long as you give credit and
don’t hold us responsible if it sets your cat on fire”. I’m pointing
at that license simply on the account that it’s the simplest and
shortest license that I know of. :slight_smile:

If that would be better seen, I’d probably do that. Yes, that’s one of
the major things that made me think about a wrapper actually.

Making the API (strongly, if possible) exception-safe would be a huge
improvement, right there.

As someone else pointed out, it’s not that difficult to make those
wrappings, but it’d be nice to have a common set of "official"
wrappers that everyone uses, and thus gets debugged really well. I
wouldn’t want to drag in all sorts of other language wrappers (the
Delphi and Python wrappers seem fairly popular, for example), but C++
wrappers would be so razor-thin (nothing to build, no need to have a
C++ compiler to build SDL, no extra library dependencies, just a few
extra files in the headers directory) that I think it’d be worth it.

That would probably need to go with these projects, I guess (it’d be
sort of strange to have some headers for SDL_mixer in SDL itself?).

Of course, but as I understand, SDL_mixer is still part of SDL, or am I wrong?

They might be in the SDL “umbrella project”, but there’s no trace of
them in SDL-1.2.13.tar.gz. It’d be kind of weird to have C++ wrappers
for things you don’t even have the headers for! That said, wrapping
them too could be a good idea (I’m not using them, myself, so meh),
I’m just saying the headers wrapping them should go with the
appropriate package tarballs.On Wed, Apr 1, 2009 at 3:34 PM, Kornel Kisielewicz <kornel.kisielewicz at gmail.com> wrote:

–
http://pphaneuf.livejournal.com/

9

Hmm, in that case some mechanism should be devised to easily extend
the C++ API with additional managed functionality from other
libraries.

Something that could be part of the SDL C++ API and help out with
SDL_image would be wrappers for SDL_rwops <-> iostreams (so you can
pass in an iostream wherever SDL needs an SDL_rwops, which is the case
in SDL_image’s API, and wrap an SDL_rwop in an iostream).On Wed, Apr 1, 2009 at 3:40 PM, Kornel Kisielewicz <kornel.kisielewicz at gmail.com> wrote:

–
http://pphaneuf.livejournal.com/

10

But it’d be a cinch to just put those headers only under a really
liberal license like the two-clause BSD
(http://techbase.kde.org/Policies/Licensing_Policy#BSD_License) that
basically says “do whatever you want, as long as you give credit and
don’t hold us responsible if it sets your cat on fire”. I’m pointing
at that license simply on the account that it’s the simplest and
shortest license that I know of. :slight_smile:

As far as I’m concerned, I’d gladly put such headers under a fully
liberal licence ( personally I was thinking about the Boost licence,
but any equivalent one fits ).

If that would be better seen, I’d probably do that. Yes, that’s one of
the major things that made me think about a wrapper actually.

Making the API (strongly, if possible) exception-safe would be a huge
improvement, right there.

Agreed, that’d be goal in itself.

As someone else pointed out, it’s not that difficult to make those
wrappings, but it’d be nice to have a common set of "official"
wrappers that everyone uses, and thus gets debugged really well. I
wouldn’t want to drag in all sorts of other language wrappers (the
Delphi and Python wrappers seem fairly popular, for example), but C++
wrappers would be so razor-thin (nothing to build, no need to have a
C++ compiler to build SDL, no extra library dependencies, just a few
extra files in the headers directory) that I think it’d be worth it.

That’s my goal :)On Wed, Apr 1, 2009 at 10:16 PM, Pierre Phaneuf wrote:

–
regards,
Kornel Kisielewicz

11

That’s what I had in mind when talking about STLification. There are a
few more tricks here that can be done with streams to allow maximum
mobility of usage.On Wed, Apr 1, 2009 at 10:22 PM, Pierre Phaneuf wrote:

On Wed, Apr 1, 2009 at 3:40 PM, Kornel Kisielewicz <@Kornel_Kisielewicz> wrote:

Hmm, in that case some mechanism should be devised to easily extend
the C++ API with additional managed functionality from other
libraries.

Something that could be part of the SDL C++ API and help out with
SDL_image would be wrappers for SDL_rwops <-> iostreams (so you can
pass in an iostream wherever SDL needs an SDL_rwops, which is the case
in SDL_image’s API, and wrap an SDL_rwop in an iostream).

–
regards,
Kornel Kisielewicz

12

As far as I’m concerned, I’d gladly put such headers under a fully
liberal licence ( personally I was thinking about the Boost licence,
but any equivalent one fits ).

Awesome, the Boost license is even more simple and liberal! (no need
to even credit when distributing binaries, just keeping the license
text when distributing sources)On Wed, Apr 1, 2009 at 4:58 PM, Kornel Kisielewicz <kornel.kisielewicz at gmail.com> wrote:

–
http://pphaneuf.livejournal.com/

13

In the past I have rather strongly opposed putting this kind of thing in
SDL for the simple reason that C is easier to embed in more other languages
than is C++. And, right now I still oppose putting it in SDL.

OTOH, the proposal as I have been reading it is very interesting. I would
like to see it done just to see how the process worked out and to see how
usable the result was. The design would have to be carried out in the full
light of the mailing list and would require careful monitoring to damp out
the inevitable flames. :frowning:

OTTH, I’m believe this could be a very long process. It is unlikely to be
complete by the time GSOC 2009 ends. The usual first approach to this
problem (as I have seen several times) tends to wind up ignoring a huge part
of what you can actually do with SDL. Not to mention that 1.3 may still
contain instabilities that could result in work stoppages in parts of the
project. So, I expect this to be an iterative process that might not
stabilize during the first few iterations. The person proposing the work
needs to understand that, and the GSOC people need to understand that
successful completion of the project does not imply that the code will be
complete at the end of the sumer.

OTFH, The focus on STL worries me. It may well be that STL approaches are
not applicable. In the 10 seconds (so, yeah, I can be completely wrong) I’ve
spent thinking about this I only see a tiny number of things where STL
concepts are applicable. But, aside from that I believe that starting with
an STL mind set, or any mind set, may keep the project from finding a model
that is well suited for SDL’s application space. We should not accept STL as
the obviously correct starting point.

Ok, I’ve gone through the other hand, the third hand, and the fourth hand…
so maybe I should stop.

Bob PendletonOn Wed, Apr 1, 2009 at 4:04 PM, Pierre Phaneuf wrote:

On Wed, Apr 1, 2009 at 4:58 PM, Kornel Kisielewicz <kornel.kisielewicz at gmail.com> wrote:

As far as I’m concerned, I’d gladly put such headers under a fully
liberal licence ( personally I was thinking about the Boost licence,
but any equivalent one fits ).

Awesome, the Boost license is even more simple and liberal! (no need
to even credit when distributing binaries, just keeping the license
text when distributing sources)

–
http://pphaneuf.livejournal.com/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

14

2009/4/2 Bob Pendleton :

In the past I have rather strongly opposed putting this kind of thing in
SDL for the simple reason that C is easier to embed in more other languages
than is C++. And, right now I still oppose putting it in SDL.

I do not suggest putting it in the main distro, but as a
side-download for people wanting a workable thought out and complete
C++ interface.

OTOH, the proposal as I have been reading it is very interesting. I would
like to see it done just to see how the process worked out and to see how
usable the result was. The design would have to be carried out in the full
light of the mailing list and would require careful monitoring to damp out
the inevitable flames. :frowning:

This is something that I already have forseen. Before any coding would
start, a preliminary report would be presented to the list. This
report would list the major design decisions, and would include
interfaces for the major classes. Even after coding starts, there’d be
regular status reports – in the case of such a project I think that
the mailing list would be a far better target for such reports than a
blog.

OTTH, I’m believe this could be a very long process. It is unlikely to be
complete by the time GSOC 2009 ends. The usual first approach to this
problem (as I have seen several times) tends to wind up ignoring a huge part
of what you can actually do with SDL.

As long as the unimplemented features would be marked in a TODO list,
and as long as all the basic interfaces would be there, it would
already be a good foundation easy to expand. Also, I quite believe
that it is doable, as long as not too many design flame wars break
out on the list :>. A good idea is to start a design discussion on the
next feature while starting implementing one that has been agreed
upon.

Not to mention that 1.3 may still
contain instabilities that could result in work stoppages in parts of the
project.

I am ready to cope with that. Note that implementing a full-blown C++
API would be a great way to fully coverage-test 1.3.

stabilize during the first few iterations. The person proposing the work
needs to understand that, and the GSOC people need to understand that
successful completion of the project does not imply that the code will be
complete at the end of the sumer.

Agreed.

OTFH, The focus on STL worries me. It may well be that STL approaches are
not applicable.

I’m thinking more STL-aware, than STL-focused. I’ve seen horrible
abuses of STL, and I think I can fend those off ;-).

Ok, I’ve gone through the other hand, the third hand, and the fourth hand…
so maybe I should stop.

Why stop, all comments are really helpful!–
regards,
Kornel Kisielewicz

15

First, I hate it when people talk about C++ & STL like they’re two
seperate things. Large tracts of the STL are incorporated into the C++
language definition. It’s just the C++ standard library, okay?

Okay, now that I got THAT rant of my chest…

I did a research project on API design, based around SDL. I spent some
time considering the implementation of what you propose, some
thoughts:

Many C-oriented constructs used within SDL can be tricky to
translate directly into C++ constructs in a way that maintains
compatibility - Exceptions are the best example of this; how do
properly support exceptions, while still maintaining the integrity of
C code? Think of the scenario where someone is porting from C to C++
and wants to leave large chunks of code as C; this happens in the real
world. This is particularly important, as exceptions are about the
only reason to actually write a C++ wrapper for SDL - If you’re not
going to use exceptions, then you may as well use the ‘naked’ C calls,
as you’ll have to do C-style error checking anyway…

Wrapping structs in classes exposes some weaknesses in the SDL APIs.
For example, SDL_UnionRect doesn’t translate well into
sdl::Rectangle::union(), for obvious reasons, but actually, more
importantly, it isn’t a union operation; SDL_UnionRect returns an
SDL_Rect that is large enough to enclose both the rectangles passed
in. So, you have 2 weaknesses; a name that is a reserved word in
another language and an API that doesn’t describe acurately what it
does.

Automatic memory management should be used with extreme care. This
is particularly difficult when dealing with C comptibility; what
happens when someone makes a C call to free memory? This makes things
VERY tricky. I would argue that it is not merely sufficient to say
"well if they do that, it’s their own fault" - “A library should be
easy to use and difficult to misuse” - one has to find a way to
enforce behaviour to prevent mixed code from failing. How do you do
that without cripplling the performance?

The conclusion I drew from this, is that, actually, the “best” way
to design a C library, is to design it alongside the bindings for
atleast 2 other languages (rule-of-three). In the case of SDL, the
obvious choices are C++ (real-world) and Python (PyGame being as well
know as it is). It’s not so much about making it work perfectly with
every other language, it’s about thinking about the problem in
different ways to allow you to spot problems you may have otherwise
missed.

I know my tone may seem a little negative. It’s not meant to be; I’m
simply being realistic :slight_smile:

Eddy

2009/4/2 Kornel Kisielewicz <kornel.kisielewicz at gmail.com>:> 2009/4/2 Bob Pendleton :

In the past I have rather strongly opposed putting this kind of thing in
SDL for the simple reason that C is easier to embed in more other languages
than is C++. And, right now I still oppose putting it in SDL.

I do not suggest putting it in the main distro, but as a
side-download for people wanting a workable thought out and complete
C++ interface.

OTOH, the proposal as I have been reading it is very interesting. I would
like to see it done just to see how the process worked out and to see how
usable the result was. The design would have to be carried out in the full
light of the mailing list and would require careful monitoring to damp out
the inevitable flames. :frowning:

This is something that I already have forseen. Before any coding would
start, a preliminary report would be presented to the list. This
report would list the major design decisions, and would include
interfaces for the major classes. Even after coding starts, there’d be
regular status reports – in the case of such a project I think that
the mailing list would be a far better target for such reports than a
blog.

OTTH, I’m believe this could be a very long process. It is unlikely to be
complete by the time GSOC 2009 ends. The usual first approach to this
problem (as I have seen several times) tends to wind up ignoring a huge part
of what you can actually do with SDL.

As long as the unimplemented features would be marked in a TODO list,
and as long as all the basic interfaces would be there, it would
already be a good foundation easy to expand. Also, I quite believe
that it is doable, as long as not too many design flame wars break
out on the list :>. A good idea is to start a design discussion on the
next feature while starting implementing one that has been agreed
upon.

Not to mention that 1.3 may still
contain instabilities that could result in work stoppages in parts of the
project.

I am ready to cope with that. Note that implementing a full-blown C++
API would be a great way to fully coverage-test 1.3.

stabilize during the first few iterations. The person proposing the work
needs to understand that, and the GSOC people need to understand that
successful completion of the project does not imply that the code will be
complete at the end of the sumer.

Agreed.

OTFH, The focus on STL worries me. It may well be that STL approaches are
not applicable.

I’m thinking more STL-aware, than STL-focused. I’ve seen horrible
abuses of STL, and I think I can fend those off ;-).

Ok, I’ve gone through the other hand, the third hand, and the fourth hand…
so maybe I should stop.

Why stop, all comments are really helpful!

–
regards,
Kornel Kisielewicz

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

16

2009/4/2 Bob Pendleton <@Bob_Pendleton>:

In the past I have rather strongly opposed putting this kind of thing
in
SDL for the simple reason that C is easier to embed in more other
languages
than is C++. And, right now I still oppose putting it in SDL.

I do not suggest putting it in the main distro, but as a
side-download for people wanting a workable thought out and complete
C++ interface.

OTOH, the proposal as I have been reading it is very interesting. I would
like to see it done just to see how the process worked out and to see how
usable the result was. The design would have to be carried out in the
full
light of the mailing list and would require careful monitoring to damp
out
the inevitable flames. :frowning:

This is something that I already have forseen. Before any coding would
start, a preliminary report would be presented to the list. This
report would list the major design decisions, and would include
interfaces for the major classes. Even after coding starts, there’d be
regular status reports – in the case of such a project I think that
the mailing list would be a far better target for such reports than a
blog.

Your answer makes me think you didn’t understand what I meant. You don’t
actually get to do the design, you’re just the poor guy who has to create
it. What did that mean?

It means that the original design you submit will not be the final design.

BTW: treat Mr. Cullen’s comments as gold. They are dead on.

Bob PendletonOn Wed, Apr 1, 2009 at 6:50 PM, Kornel Kisielewicz < kornel.kisielewicz at gmail.com> wrote:

OTTH, I’m believe this could be a very long process. It is unlikely to be
complete by the time GSOC 2009 ends. The usual first approach to this
problem (as I have seen several times) tends to wind up ignoring a huge
part
of what you can actually do with SDL.

As long as the unimplemented features would be marked in a TODO list,
and as long as all the basic interfaces would be there, it would
already be a good foundation easy to expand. Also, I quite believe
that it is doable, as long as not too many design flame wars break
out on the list :>. A good idea is to start a design discussion on the
next feature while starting implementing one that has been agreed
upon.

Not to mention that 1.3 may still
contain instabilities that could result in work stoppages in parts of the
project.

I am ready to cope with that. Note that implementing a full-blown C++
API would be a great way to fully coverage-test 1.3.

stabilize during the first few iterations. The person proposing the work
needs to understand that, and the GSOC people need to understand that
successful completion of the project does not imply that the code will be
complete at the end of the sumer.

Agreed.

OTFH, The focus on STL worries me. It may well be that STL approaches are
not applicable.

I’m thinking more STL-aware, than STL-focused. I’ve seen horrible
abuses of STL, and I think I can fend those off ;-).

Ok, I’ve gone through the other hand, the third hand, and the fourth
hand…
so maybe I should stop.

Why stop, all comments are really helpful!

–
regards,
Kornel Kisielewicz

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

17

A C++ SDL lib could offer some really fancy run-time programming
abstractions for composing various image transformations and
convolutions. The main advantage of tying it to SDL would be that the
selected video back-end could determine the implementation of image
transformation pipelines at run-time.

Effect outline = transient_surface(source(0).dimensions) |
blit(source(0)) | propagate_opaque | value_invert | blit(source(0));

outline.render(screen, rendered_text);–
http://codebad.com/

18

A C++ SDL lib could offer some really fancy run-time programming
abstractions for composing various image transformations and
convolutions. The main advantage of tying it to SDL would be that the
selected video back-end could determine the implementation of image
transformation pipelines at run-time.

I’d say that’d probably be way out of the scope of an “SDL C++
binding”. Are those features in SDL itself? I have to admit I didn’t
look at all the features that the new “renderer” architecture has,
maybe there’s a bunch of effects I missed…On Thu, Apr 2, 2009 at 12:54 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:

–
http://pphaneuf.livejournal.com/

19

No, there are not, but there already are SDL C++ bindings, I wasn’t
sure how much more functionality one might need to justify another
SDL/C++ mating, so I suggested this!On Thu, Apr 2, 2009 at 7:00 PM, Pierre Phaneuf wrote:

I’d say that’d probably be way out of the scope of an “SDL C++
binding”. Are those features in SDL itself? I have to admit I didn’t
look at all the features that the new “renderer” architecture has,
maybe there’s a bunch of effects I missed…

–
http://codebad.com/

20

No, there are not, but there already are SDL C++ bindings, I wasn’t
sure how much more functionality one might need to justify another
SDL/C++ mating, so I suggested this!

Making a razor-thin one that came standard with SDL and wouldn’t add
any build-time requirements for games would be pretty cool, I think.
You’re quite right that there are some, looking around on the library
registry on libsdl.org (and pruning the dead links):

http://sel.sourceforge.net/
http://sdlucid.sourceforge.net/
http://sdlmm.sourceforge.net/
http://burningsmell.org/qdsdl/
http://osdl.berlios.de/

I intentionally left out a bunch of libraries that are “C++ game
libraries” that implement a ton of abstractions and helpers on top.
Some of those are very old, some are somewhat hefty, others are
headers-only, etc… There’s definitely something to learn here, in
any case.On Thu, Apr 2, 2009 at 7:08 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:

–
http://pphaneuf.livejournal.com/