Announce: C++ wrapper/interface for SDL events and timers

SDL Development
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello everyone,

I would like to announce sdl++, a work-in-progress C++ wrapper for SDL events
and timers. It provides an object-oriented interface to the SDL Event and
Timer API and encourages type-safety for user data through templates. For example:

typedef SDL_ExtUserEvent<int*> IntEvent;

This introduces a new event subtype whose listeners only accept pointers to
int in their callback. For a listener to be compatible with the event source,
it must provide an implementation of the SDL_Callback<int*> interface:

class IntCallback : public SDL_Callback<int*>
{
public:
Uint32 invoke(SDL_Source*, int* data, void*)
{
cout << *data << endl;
return 0;
}
};

Listeners are attached to a notification source (either a timer or an event)
and data is dispatched to them:

IntEvent myEvent; /* Note that two instances don’t share listeners. */
IntCallback myCallback;
myEvent.attach(&myCallback);
int myData = 42;
myEvent.notifyNow(&myData);
myData = 23;
myEvent.notifyLater(&myData);
SDL_EventHandle::waitEvent();

Since the algorithmic complexity of the dispatch is O(1) (a vector lookup), I
would consider this wrapper an acceptable trade-off between code complexity
and speed penalty at runtime. I’m very much looking forward to your comments,
suggestions, and questions.

You can find a bzip2’ed tarball of the wrapper at
http://www.chriseineke.com/sdl++/index.html

Some things I’d like to do in the future:

  • Add an SDL_Task class that unifies events and timers (it would push an
    event onto the queue when the timer fires).
  • The build infrastructure is broken. I need a “nice” file structure and
    need to fix the Autoconf/Automake files. For now "g++ *.cc sdl-config --libs" is enough. :wink:
  • Write a test harness. There is none at the moment.
  • My solution to the static initialization order fiasco of the instances for
    built-in events sucks. It’s quite ugly and I’m certain a better way
    exists.
  • Add a typedef for the type of the necessary callback to the event
    template.
  • Decide if to stay with camelCase naming convention or to convert to
    stl-like.*
  • -- Christopher C. Eineke -- Email: chris at chriseineke.com -*-
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkpHEsAACgkQPOmqd0kEEbstiwCfSUgDn28RQiH4zuLnW7uChVlf
89sAn1iWmVpqis4uSt2g8Kn1TTNKrZz7
=M8rI
-----END PGP SIGNATURE-----

2

Christopher Eineke wrote:

Hello everyone,

I would like to announce sdl++, a work-in-progress C++ wrapper for SDL events
and timers. It provides an object-oriented interface to the SDL Event and
Timer API and encourages type-safety for user data through templates. For example:

typedef SDL_ExtUserEvent<int*> IntEvent;

I don’t know … Personally, as a developer I don’t like wrappers around libraries,
they are forming an extra layer between me and the library. Of course SDL itself
is a giant wrapper around all kinds of native libraries, and therefore adds big value
for the coder that wants to write portable applications.

Wouldn’t it be a good idea to start the introduction of your project with a
resume of the real problems of software writers that you want to solve? Static
type-safety is not a real issue in my opinion, as it can be implemented very
well already with SDL, using C++.

And please, never use types starting with SDL_…, these should be reserved for
the basic SDL types and functions.

Wouter Boeke

3

It already exist, please have a look at guichan and you will see they wrapp
SDL and some other
libs with clean C++.On Sun, 28 Jun 2009 02:50:43 -0400, Christopher Eineke wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello everyone,

I would like to announce sdl++, a work-in-progress C++ wrapper for SDL
events

4

2009/6/28 W.Boeke <w.boeke at chello.nl>

And please, never use types starting with SDL_…, these should be reserved
for
the basic SDL types and functions.

Also note that C++ has namespaces, which make such prefixes unnecessary.

5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello Wouter,

W.Boeke wrote:

I don’t know … Personally, as a developer I don’t like wrappers around
libraries, they are forming an extra layer between me and the library. Of course
SDL itself is a giant wrapper around all kinds of native libraries, and therefore
adds big value for the coder that wants to write portable applications.

My goal is to let programmers write less code than they should need to. In
this wrapper’s case it also makes the code interface-oriented, encapsulates
the Timer API and Events API into instantiable objects, decentralizes event
processing, and introduces type-safety for user data pointers. I’m certain
that’s added value right there. :wink:

Wouldn’t it be a good idea to start the introduction of your project with a
resume of the real problems of software writers that you want to solve?
Static type-safety is not a real issue in my opinion, as it can be implemented
very well already with SDL, using C++.

I didn’t like to manually cast void* and centrally manage event dispatch.
That’s all. The above advantages resulted from there. I certainly don’t think
my C++ wrapper is superior. It obviously has its disadvantages, like being
written in C++ and being object-oriented in itself.

And please, never use types starting with SDL_…, these should be
reserved for the basic SDL types and functions.

Yes, that’s a good point. I have addressed that and put everything into its
own namespace, sdlpp. I’ve also addressed some of the ToDo items in my first
announcement. First, I fixed the build infrastructure. It’s now building
correctly by issuing “autoreconf && cd build && …/configure && make”. Second,
I started to write a test harness (in CppUnit) that contains a couple of
applicable test cases. Third, after moving everything into its own namespace,
I switched from camel case to an stl-like naming convention. sdl++ v0.0.2 is
now available at http://www.chriseineke.com/sdl++/index.html

I’ll be happy to discuss anybody’s issues and concerns. As I mentioned before,
suggestions are welcome anytime.

Best regards,
Chris

  • -- Christopher C. Eineke -- Email: chris at chriseineke.com -*-
  • -- Independent Software Developer -- Cell: 1-519-852-3409 -*-
  • -- at your service. -- Home: 1-226-663-3651 -*-

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkpNWNAACgkQPOmqd0kEEbvqZQCgmutaM/4IidnroM+gPGKPp4qc
hoQAn1oyRItQr9zvpFHfBcMJTYOiJm4t
=ylND
-----END PGP SIGNATURE-----

6

Christopher Eineke skrev:

Yes, that’s a good point. I have addressed that and put everything
into its
own namespace, sdlpp.

As a C++ developer I would expect the namespace to be SDL. Calling it
sdlpp does not really make sense (I assume that pp stands for ++ in
C++). I know that I am using C++, no need to include that in the
namespace identifier. I just want to use SDL::Surface (or say “using
SDL;” and then just use Surface).

7

Christopher Eineke wrote:

W.Boeke wrote:

I don’t know … Personally, as a developer I don’t like wrappers around
libraries, they are forming an extra layer between me and the library. Of course
SDL itself is a giant wrapper around all kinds of native libraries, and therefore
adds big value for the coder that wants to write portable applications.

My goal is to let programmers write less code than they should need to. In
this wrapper’s case it also makes the code interface-oriented, encapsulates
the Timer API and Events API into instantiable objects, decentralizes event
processing, and introduces type-safety for user data pointers. I’m certain
that’s added value right there. :wink:

Hi Christopher,
After I sent my first reply I realized that my aversion stemmed from the word
‘wrapper’, whereas what you propose actually appears to be ‘a library built
on top of SDL’. Sounds much better.

Wouldn’t it be a good idea to start the introduction of your project with a
resume of the real problems of software writers that you want to solve?
Static type-safety is not a real issue in my opinion, as it can be implemented
very well already with SDL, using C++.

I didn’t like to manually cast void* and centrally manage event dispatch.

But you don’t have to! Using pure SDL functions you can dispatch events without
needing to cast pointers. I know because I did this in my toolkit SDL-widgets.
It depends on how you organize things.

It obviously has its disadvantages, like being
written in C++ and being object-oriented in itself.

That’s not a disadvantage, but an advantage! C++ is better and more convenient
than C. The only problem with C++ is the way it is teached by the object-oriented
gurus, who tell you that class members should be hidden and only be accessible by
getter and setter functions, and similar superfluous prescriptions. Why would a
software writer hide things for himself? Use your common sense and take from
this multi-paradigma language only what you need!

Wouter Boeke

8

As a C++ developer I would expect the namespace to be SDL. Calling it
sdlpp does not really make sense (I assume that pp stands for ++ in
C++). I know that I am using C++, no need to include that in the
namespace identifier. I just want to use SDL::Surface (or say “using
SDL;” and then just use Surface)

I second this notion. Why sdlpp when you’re simply wrapping SDL? (I see that you’re actually doing this in SDL++.hpp, good on ya, but you might as well use SDL in all those files you include…)

I’d also like to suggest that you make some typedefs to SDL types that you use externally, IE:
namespace SDL {
typedef EventType SDL_EventType;
}

I suggest providing optionally included wrappers for other libraries that extend SDL functionality, like SDL_net, SDL_gfx and SDL_mixer.

Also, I request that you branch this to wrap SDL 1.3. SDL 1.3 is very promising, and I’d love for a C++ wrapper over it to be ready as soon as it’s released.

9

Two things:

  1. namespace SDL should probably be reserved for an “official” SDL wrapper
    (though it doesn’t really matter since you’re unlikely to use both at the same
    time)
  2. In general, since your header files would include SDL.h anyway, the
    original SDL_ types would still be accessible from the user’s code, which
    makes it kinda pointless to mirror those types in your own namespace.

You could do this though if you really want to hide it:

namespace libraryspace {
namespace {
#include “SDL.h”
typedef ::libraryspace::EventType SDL_EventType;
}
}

just keep in mind this will really screw things up for the user if they need
anything in any header files included from SDL.h (like cstdlib for example)
due to header guards.On Sunday, 5 July 2009 13:51:30 Nate Fries wrote:

As a C++ developer I would expect the namespace to be SDL. Calling it
sdlpp does not really make sense (I assume that pp stands for ++ in
C++). I know that I am using C++, no need to include that in the
namespace identifier. I just want to use SDL::Surface (or say “using
SDL;” and then just use Surface)

I second this notion. Why sdlpp when you’re simply wrapping SDL? (I see
that you’re actually doing this in SDL++.hpp, good on ya, but you might as
well use SDL in all those files you include…)

I’d also like to suggest that you make some typedefs to SDL types that you
use externally, IE: namespace SDL {
typedef EventType SDL_EventType;
}

10

Isn’t this already provided by SDLmmhttp://sdlmm.sourceforge.net/index.html
?On Sun, Jun 28, 2009 at 2:50 AM, Christopher Eineke wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello everyone,

I would like to announce sdl++, a work-in-progress C++ wrapper for SDL
events
and timers. It provides an object-oriented interface to the SDL Event and
Timer API and encourages type-safety for user data through templates. For
example:

typedef SDL_ExtUserEvent<int*> IntEvent;

This introduces a new event subtype whose listeners only accept pointers to
int in their callback. For a listener to be compatible with the event
source,
it must provide an implementation of the SDL_Callback<int*> interface:

class IntCallback : public SDL_Callback<int*>
{
public:
Uint32 invoke(SDL_Source*, int* data, void*)
{
cout << *data << endl;
return 0;
}
};

Listeners are attached to a notification source (either a timer or an
event)
and data is dispatched to them:

IntEvent myEvent; /* Note that two instances don’t share listeners. */
IntCallback myCallback;
myEvent.attach(&myCallback);
int myData = 42;
myEvent.notifyNow(&myData);
myData = 23;
myEvent.notifyLater(&myData);
SDL_EventHandle::waitEvent();

Since the algorithmic complexity of the dispatch is O(1) (a vector lookup),
I
would consider this wrapper an acceptable trade-off between code complexity
and speed penalty at runtime. I’m very much looking forward to your
comments,
suggestions, and questions.

You can find a bzip2’ed tarball of the wrapper at
http://www.chriseineke.com/sdl++/index.html

Some things I’d like to do in the future:

  • Add an SDL_Task class that unifies events and timers (it would push an
    event onto the queue when the timer fires).
  • The build infrastructure is broken. I need a “nice” file structure and
    need to fix the Autoconf/Automake files. For now “g++ *.cc sdl-config --libs” is enough. :wink:
  • Write a test harness. There is none at the moment.
  • My solution to the static initialization order fiasco of the instances
    for
    built-in events sucks. It’s quite ugly and I’m certain a better way
    exists.
  • Add a typedef for the type of the necessary callback to the event
    template.
  • Decide if to stay with camelCase naming convention or to convert to
    stl-like.
  • -- Christopher C. Eineke -- Email: chris at chriseineke.com -*-
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkpHEsAACgkQPOmqd0kEEbstiwCfSUgDn28RQiH4zuLnW7uChVlf
89sAn1iWmVpqis4uSt2g8Kn1TTNKrZz7
=M8rI
-----END PGP SIGNATURE-----

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

11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello Nate,

Sorry for the late reply. I was quite busy… :slight_smile:

Nate Fries wrote:

As a C++ developer I would expect the namespace to be SDL. Calling it
sdlpp does not really make sense (I assume that pp stands for ++ in
C++). I know that I am using C++, no need to include that in the
namespace identifier. I just want to use SDL::Surface (or say “using
SDL;” and then just use Surface)

I second this notion. Why sdlpp when you’re simply wrapping SDL? (I see
that you’re actually doing this in SDL++.hpp, good on ya, but you might
as well use SDL in all those files you include…)

Better safe than sorry. If there ever is going to be an official C++ layer for
SDL I’d like to be on the safe side with mine. I think that the namespace
alias for sdlpp is good enough, though.

I’d also like to suggest that you make some typedefs to SDL types that
you use externally, IE:
namespace SDL {
typedef EventType SDL_EventType;
}

I don’t think I understand. Do you mean that sdlpp::Library_event should be
aliased to sdlpp::SDL_Library_event? In my code, I like to either use the
namespace prefix or put in a using sdlpp::.

I suggest providing optionally included wrappers for other libraries
that extend SDL functionality, like SDL_net, SDL_gfx and SDL_mixer.

Yes, that is an excellent idea. I’ll add that as soon as I have the core
library mostly implemented. Clients could #define SDLPP_NEED_NET or
SDL_NEED_GFX if they want the extended functionality.

Also, I request that you branch this to wrap SDL 1.3. SDL 1.3 is very
promising, and I’d love for a C++ wrapper over it to be ready as soon as
it’s released.

I shall try, at least. Is there a roadmap that I can look at? I would like to
complete my SDL-1.2 layer first before I start branching to the higher version.

Best regards.

  • -- Christopher C. Eineke -- Email: chris at chriseineke.com -*-
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkpc/CsACgkQPOmqd0kEEbv1hACcCG1WvZmueOLAZ9HHVzbEnclo
i3sAmwWV3+84Oj6HNOp3udJwQpSDYvmn
=AoQk
-----END PGP SIGNATURE-----

12

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello Erik,

Erik wrote:

As a C++ developer I would expect the namespace to be SDL. Calling it
sdlpp does not really make sense (I assume that pp stands for ++ in
C++). I know that I am using C++, no need to include that in the
namespace identifier. I just want to use SDL::Surface (or say “using
SDL;” and then just use Surface).

Incidentally, I’ve done a lot of changes in recent days. A lot of renaming,
bugfixing, and adding features. The latest release now has support for
cursors, joysticks, rects, colors, tasks, timers, conditions, mutexes,
semaphores, surfaces, events, and threads. It’s available at
http://www.chriseineke.com/sdl++/index.html

The online documentation is available at
http://www.chriseineke.com/sdl++/doc/html/index.html

Enjoy! :slight_smile:

P.S. Does anybody feel annoyed by my announcements? I’m thinking that I should
take them to a separate mailing list…

  • -- Christopher C. Eineke -- Email: chris at chriseineke.com -*-
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkpc/awACgkQPOmqd0kEEbtKhACgrQZqtClkUlKfPIeNFWT102L1
pb4AoK7Z04sr46uvECN2nlGurGgxqcBi
=Nkyu
-----END PGP SIGNATURE-----

13

I’m not annoyed by it.

As for the other stuff you said:

I don’t think I understand. Do you mean that sdlpp::Library_event
should be
aliased to sdlpp::SDL_Library_event? In my code, I like to either use the
namespace prefix or put in a using sdlpp::.
No, i think that SDL_* (no namespace, the original C SDL API type)
should be typedefed like
namespace SDL { typedef SDL_* *; }

Also, I think I forgot to mention this, but a 1:1 object-oriented
version of the SDL API (plus
maybe some additional member functions to perform some common tasks for
the programmer) is
kinda my ideal for an C++ SDL wrapper.

I shall try, at least. Is there a roadmap that I can look at? I would
like to
complete my SDL-1.2 layer first before I start branching to the
higher version.

This is the closest thing there is to a “planned feature list” that I
know of:
http://icculus.org/cgi-bin/finger/finger.pl?user=icculus&date=2007-10-07&section=sdl13

14

Okay, I’m looking at the documentation…

Doesn’t it make sense for CreateRGB and CreateRGBFrom to be static
functions of the Surface class, and return a Surface object as opposed
to an SDL_Surface?

This is just one thing I noticed and figured I should correct.

15

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Nate Fries wrote:

Doesn’t it make sense for CreateRGB and CreateRGBFrom to be static
functions of the Surface class, and return a Surface object as opposed
to an SDL_Surface?

Let me ask something related: Should they be functions at all? There are
Surface constructors that use the same arguments. They could be made to use
SDL_Create… instead.

  • -- Christopher C. Eineke -- Email: chris at chriseineke.com -*-
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkpdLJMACgkQPOmqd0kEEbtsKQCg1AXxCbNxupj0SOlZKwbvar9F
wFIAoMuTOhW7yDmC8kmioE4D3Uglq3ur
=V+H1
-----END PGP SIGNATURE-----

16

Yeah, I’d rather have:
Surface* surf = new Surface(…);
than
Surface* surf = Surface::Create(…);

Seems more like proper C++ form to use the constructor.

Jonny DOn Tue, Jul 14, 2009 at 9:10 PM, Christopher Eineke wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Nate Fries wrote:

Doesn’t it make sense for CreateRGB and CreateRGBFrom to be static
functions of the Surface class, and return a Surface object as opposed
to an SDL_Surface?

Let me ask something related: Should they be functions at all? There are
Surface constructors that use the same arguments. They could be made to use
SDL_Create… instead.

  • -- Christopher C. Eineke -- Email: chris at chriseineke.com -*-
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkpdLJMACgkQPOmqd0kEEbtsKQCg1AXxCbNxupj0SOlZKwbvar9F
wFIAoMuTOhW7yDmC8kmioE4D3Uglq3ur
=V+H1
-----END PGP SIGNATURE-----

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

17

So nobody thinks this is already provided by SDLmm? Could anybody clarify
for me?On Mon, Jul 6, 2009 at 11:54 AM, Jordy D <@Jordy_D> wrote:

Isn’t this already provided by SDLmmhttp://sdlmm.sourceforge.net/index.html
?

On Sun, Jun 28, 2009 at 2:50 AM, Christopher Eineke <chris at chriseineke.com wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello everyone,

I would like to announce sdl++, a work-in-progress C++ wrapper for SDL
events
and timers. It provides an object-oriented interface to the SDL Event and
Timer API and encourages type-safety for user data through templates. For
example:

typedef SDL_ExtUserEvent<int*> IntEvent;

This introduces a new event subtype whose listeners only accept pointers
to
int in their callback. For a listener to be compatible with the event
source,
it must provide an implementation of the SDL_Callback<int*> interface:

class IntCallback : public SDL_Callback<int*>
{
public:
Uint32 invoke(SDL_Source*, int* data, void*)
{
cout << *data << endl;
return 0;
}
};

Listeners are attached to a notification source (either a timer or an
event)
and data is dispatched to them:

IntEvent myEvent; /* Note that two instances don’t share listeners. */
IntCallback myCallback;
myEvent.attach(&myCallback);
int myData = 42;
myEvent.notifyNow(&myData);
myData = 23;
myEvent.notifyLater(&myData);
SDL_EventHandle::waitEvent();

Since the algorithmic complexity of the dispatch is O(1) (a vector
lookup), I
would consider this wrapper an acceptable trade-off between code
complexity
and speed penalty at runtime. I’m very much looking forward to your
comments,
suggestions, and questions.

You can find a bzip2’ed tarball of the wrapper at
http://www.chriseineke.com/sdl++/index.html

Some things I’d like to do in the future:

  • Add an SDL_Task class that unifies events and timers (it would push an
    event onto the queue when the timer fires).
  • The build infrastructure is broken. I need a “nice” file structure and
    need to fix the Autoconf/Automake files. For now “g++ *.cc sdl-config --libs” is enough. :wink:
  • Write a test harness. There is none at the moment.
  • My solution to the static initialization order fiasco of the instances
    for
    built-in events sucks. It’s quite ugly and I’m certain a better way
    exists.
  • Add a typedef for the type of the necessary callback to the event
    template.
  • Decide if to stay with camelCase naming convention or to convert to
    stl-like.
  • -- Christopher C. Eineke -- Email: chris at chriseineke.com -*-
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkpHEsAACgkQPOmqd0kEEbstiwCfSUgDn28RQiH4zuLnW7uChVlf
89sAn1iWmVpqis4uSt2g8Kn1TTNKrZz7
=M8rI
-----END PGP SIGNATURE-----

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

18

Then remove them if they provide duplicate functionality.

Another suggestion: provide a secondary version of Surface that uses the
glSDL wrapper and is optionally compiled with the library.
I’m not sure how good the glSDL wrapper really is, but since I’ve
actually heard of it there must be some people who use it…

19

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jordy D wrote:

So nobody thinks this is already provided by SDLmm? Could anybody
clarify for me?

On short notice:

    • Doesn’t seem to provide proper wrappers for: CDs (I don’t either, but it’s
      on my todo list), Joysticks, Timers, Conditions, Cursors, Mutexes, Semaphores,
      and Threads.
    • Memory management seems to be left to the clients. My layer uses shared_ptrs
      with shallow copying to ensure consistency.
    • No “Task” class
    • Event handlers for built-in events are just a bunch of virtual functions you
      either override or not. My layer provides decentralized event handling, allows
      for easy adding of new user events and managing of collections of listeners,
      and enables type-safe pointers to user data for threads, built-in events, user
      events, and tasks.

Yes, I know the documentation in my tree is lacking quite a bit. That’s also
on my todo list.

Best regards.

  • -- Christopher C. Eineke -- Email: chris at chriseineke.com -*-
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkpdPx4ACgkQPOmqd0kEEbthPwCglyWvoOnTTob43tZ7deCYk//f
ioMAn0ZhhyKb8ufGdpB19FxBK3SQBHZe
=MOpF
-----END PGP SIGNATURE-----

20

Ah, OK. Just making sure this wasn’t a duplicate project, otherwise I
would say you should go help them out instead of making your own. But
they might disagree on the memory management aspect and if you want to
do it that way, you should make your own.On Tue, Jul 14, 2009 at 10:29 PM, Christopher Eineke wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jordy D wrote:

So nobody thinks this is already provided by SDLmm? Could anybody
clarify for me?

On short notice:

    • Doesn’t seem to provide proper wrappers for: CDs (I don’t either, but
      it’s
      on my todo list), Joysticks, Timers, Conditions, Cursors, Mutexes,
      Semaphores,
      and Threads.
    • Memory management seems to be left to the clients. My layer uses
      shared_ptrs
      with shallow copying to ensure consistency.
    • No “Task” class
    • Event handlers for built-in events are just a bunch of virtual
      functions you
      either override or not. My layer provides decentralized event handling,
      allows
      for easy adding of new user events and managing of collections of
      listeners,
      and enables type-safe pointers to user data for threads, built-in events,
      user
      events, and tasks.

Yes, I know the documentation in my tree is lacking quite a bit. That’s
also
on my todo list.

Best regards.

  • -- Christopher C. Eineke -- Email: chris at chriseineke.com -*-
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkpdPx4ACgkQPOmqd0kEEbthPwCglyWvoOnTTob43tZ7deCYk//f
ioMAn0ZhhyKb8ufGdpB19FxBK3SQBHZe
=MOpF
-----END PGP SIGNATURE-----

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