sdlmm-general — Catch-all discussion mailing list.

Re: [SDLmm-general] Takeover

[Giovanni F. <gaf...@gm...>]

Hi David,

Are you currently maintaining SDLmm? I'd volunteer for taking
ownership over and continuing development.

Cheers,
-- Giovanni



---------- Forwarded message ----------
From: Giovanni Funchal <gaf...@gm...>
Date: Wed, Jun 27, 2012 at 3:32 PM
Subject: Takeover
To: sdl...@li...


Hi,

I've seen no development being done on SDLmm for a while. I'm
currently tinkering with my own C++/SDL wrapper and would gladly take
over as the owner and maintainer of SDLmm. If the current owner could
please contact me we can discuss the details.

Thanks,
-- Giovanni

[SDLmm-general] Takeover

[Giovanni F. <gaf...@gm...>]

Hi,

I've seen no development being done on SDLmm for a while. I'm
currently tinkering with my own C++/SDL wrapper and would gladly take
over as the owner and maintainer of SDLmm. If the current owner could
please contact me we can discuss the details.

Thanks,
-- Giovanni

Re: [SDLmm-general] Patch for SDLmm

[David H. <da...@he...>]

I admit I don't exactly pay much attention to SDLmm these days. If you
want I can give you access to the repository however. Is that
something you'd like to get?


Martin Bickel <bi...@as...> writes:

> Hi,
>
> it's nice to see some activity again in the SDLmm SVN repository.
>
> We are using SDLmm for Advanced Strategic Command (www.asc-hq.org) and
> currently include a forked copy of SDLmm with some bugfixes and small
> enhancements.
>
> A patch with these changes is attached. It would be nice to see it
> included in the SVN repository.
>
> Do you plan any official release of SDLmm? If you do such a release, I
> would switch to using that for ASC instead statically linking our own copy.
>
> Best regards,
> Martin
>
> Index: src/sdlmm_basesurface.h
> ===================================================================
> --- src/sdlmm_basesurface.h	(revision 215)
> +++ src/sdlmm_basesurface.h	(working copy)
> @@ -1,6 +1,6 @@
>  /*
>   * SDmm - a C++ wrapper for SDL and related libraries
> - * Copyright © 2001 David Hedbor <da...@he...>
> + * Copyright © 2001 David Hedbor <da...@he...>
>   * 
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License as
> @@ -193,6 +193,12 @@
>      */
>      Color GetPixel(const SRect& point) const { return GetPixel(point.x, point.y); }
>  
> +    //! Get the color of the pixel
> +    /*!
> +    \warning You can only use this function when the surface is locked.
> +     */
> +    Color GetPixel(const SPoint& point) const { return GetPixel(point.x, point.y); }
> +    
>      //! Sets the color key (transparent pixel) in a blittable surface
>      //! and enables or disables RLE blit acceleration.
>      /*!
> Index: src/sdlmm_pixelformat.h
> ===================================================================
> --- src/sdlmm_pixelformat.h	(revision 215)
> +++ src/sdlmm_pixelformat.h	(working copy)
> @@ -1,6 +1,6 @@
>  /*
>   * SDmm - a C++ wrapper for SDL and related libraries
> - * Copyright © 2001 David Hedbor <da...@he...>
> + * Copyright © 2001 David Hedbor <da...@he...>
>   * 
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License as
> @@ -61,6 +61,7 @@
>      Uint8 Rshift() const { return me->Rshift; }
>      Uint8 Gshift() const { return me->Gshift; }
>      Uint8 Bshift() const { return me->Bshift; }
> +    Uint8 Ashift() const { return me->Ashift; }
>  
>      Uint8 Rloss() const { return me->Rloss; }
>      Uint8 Gloss() const { return me->Gloss; }
> @@ -98,6 +99,7 @@
>        \sa GetRGB, GetRGBA, MapRGBA
>      */
>      Color MapRGB(Uint8 r, Uint8 g, Uint8 b) const;
> +    Color MapRGB(const SDL_Color& colorrgb) const { return MapRGB(colorrgb.r, colorrgb.g, colorrgb.b); }
>      
>      Color MapRGB(const ColorRGB& colorrgb) const { return MapRGB(colorrgb.r, colorrgb.g, colorrgb.b); }
>      
> Index: src/sdlmm_basesurface.cpp
> ===================================================================
> --- src/sdlmm_basesurface.cpp	(revision 215)
> +++ src/sdlmm_basesurface.cpp	(working copy)
> @@ -1,6 +1,6 @@
>  /*
>   * SDLmm - a C++ wrapper for SDL and related libraries
> - * Copyright © 2001 David Hedbor <da...@he...>
> + * Copyright © 2001 David Hedbor <da...@he...>
>   * 
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License as
> @@ -149,7 +149,7 @@
>          g = *(the_pixel + pf.Gshift()/8);
>          b = *(the_pixel + pf.Bshift()/8);
>          color = r << pf.Rshift();
> -        color |= g << pf.Rshift();
> +        color |= g << pf.Gshift();
>          color |= b << pf.Bshift();
>          return color;
>        }
> Index: src/sdlmm_surface.h
> ===================================================================
> --- src/sdlmm_surface.h	(revision 215)
> +++ src/sdlmm_surface.h	(working copy)
> @@ -1,6 +1,6 @@
>  /*
>   * SDmm - a C++ wrapper for SDL and related libraries
> - * Copyright © 2001 David Hedbor <da...@he...>
> + * Copyright © 2001 David Hedbor <da...@he...>
>   * 
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License as
> @@ -83,9 +83,8 @@
>  
>      static Surface CreateSurface(const BaseSurface& other) {
>        return Surface(
> -          SDL_CreateRGBSurface(other.w(), other.h(),
> +          SDL_CreateRGBSurface(SDL_SWSURFACE, other.w(), other.h(),
>                                 other.GetPixelFormat().BitsPerPixel(),
> -                               other.pitch(),
>                                 other.GetPixelFormat().Rmask(),
>                                 other.GetPixelFormat().Gmask(),
>                                 other.GetPixelFormat().Bmask(),
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com_______________________________________________
> SDLmm-general mailing list
> SDL...@li...
> https://lists.sourceforge.net/lists/listinfo/sdlmm-general

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
A bird in the bush usually has a friend in there with him.

[SDLmm-general] Patch for SDLmm

[Martin B. <bi...@as...>]

Hi,

it's nice to see some activity again in the SDLmm SVN repository.

We are using SDLmm for Advanced Strategic Command (www.asc-hq.org) and
currently include a forked copy of SDLmm with some bugfixes and small
enhancements.

A patch with these changes is attached. It would be nice to see it
included in the SVN repository.

Do you plan any official release of SDLmm? If you do such a release, I
would switch to using that for ASC instead statically linking our own copy.

Best regards,
Martin

[SDLmm-general] Takeover?

[David H. <da...@he...>]

I just got a notice that someone wishes to take over SDLmm on SF. Is
that someone on this list? 
-- 
[ Below is a random fortune, which is unrelated to the above message. ]
How you look depends on where you go.

Re: [SDLmm-general] back in action

[David H. <da...@he...>]

"Martin Bickel" <bi...@as...> writes:

> The patch does not include changes that were necessary for building
> SDLmm with Borland C++ Builder. The RCSID macros caused conflicts, so I
> removed them all. IMHO, they have nothing lost in the global namespace.
> I suggest, if they are need at all, to at least put them into the SDLmm
> namespace. 


The purpose of RCSID macros is to allow the command "ident" to list
the versions of the files in the library. Naturally with Borland C++,
this is of no consequence.

Example output:

: 0 neotron@stellar ident ~/src/SDLmm/src/.libs/libSDLmm.so
/home/neotron/src/SDLmm/src/.libs/libSDLmm.so:
     $Id: sdlmm_global.cpp,v 1.17 2001/06/25 23:24:52 rad_ad Exp $
     $Id: sdlmm_basesurface.cpp,v 1.18 2001/08/27 22:14:53 neotron Exp $
     $Id: sdlmm_surface.cpp,v 1.18 2001/06/25 23:24:52 rad_ad Exp $
     $Id: sdlmm_display.cpp,v 1.14 2001/06/25 23:24:52 rad_ad Exp $
     $Id: sdlmm_pixelformat.cpp,v 1.5 2001/07/09 01:14:13 rad_ad Exp $
     $Id: sdlmm_srect.cpp,v 1.9 2001/08/30 23:58:45 rad_ad Exp $
     $Id: sdlmm_event.cpp,v 1.9 2001/08/27 02:11:14 rad_ad Exp $
     $Id: sdlmm_audio.cpp,v 1.5 2001/06/25 23:24:52 rad_ad Exp $
     $Id: sdlmm_timer.cpp,v 1.7 2001/06/25 23:24:52 rad_ad Exp $
     $Id: sdlmm_joystick.cpp,v 1.5 2001/06/25 23:24:52 rad_ad Exp $
     $Id: sdlmm_cd.cpp,v 1.5 2001/06/25 23:24:52 rad_ad Exp $
     $Id: sdlmm_videoinfo.cpp,v 1.4 2001/06/25 23:24:52 rad_ad Exp $

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
You will be the victim of a bizarre joke.

Re: [SDLmm-general] back in action

[David H. <da...@he...>]

"Martin Bickel" <bi...@as...> writes:

> On Wed, 13 Apr 2005 11:11:58 -0700, David Hedbor wrote:
>
>>I will now add the negative effects of exceptions.
>>
>>1) It complicates memory handling. I.e if you have code such as this:
>>
>>void myfunc() {
>>  Type *data = new Type();
>>  Type->do_something();
>>  delete data;
>>}
>
> Then you have bad application code which you should fix, and not blame
> SDLmm for it :->
> Since exceptions are the standard C++ mechanism for reporting errors
> and even the standard library uses them, you should write exception
> safe code anyway, regardless if SDLmm uses it or not.

Exceptions are optional (-fno-exceptions). And yes, the above is the
error of the code but it does show why exceptions aren't all perfect
for error handling. Error handling that makes it easier to get memory
leaks could be bad if used too much.

>>I do_something throws an error which is recovered properly by the
>>method calling myfunc, we now have leaked a reference to Type. Often
>>this can be mostly fixed by using some sort of automatic or reference
>>counted pointer object, but it's still a potental issue. 
>
> But the goal of SDLmm is to provide a C++ abstraction of the SDL
> functions. We shouldn't design the library around potential programs
> that for whatever reason don't use the C++ mechanisms for automatic
> memory management. If someone really wants to go the messy C way, he
> can call SDL directly. 

Automatic memory handling that's useful is something you need to
implement in the application layer. My main point is that it's really
really easy to make exceptions optional, enabled by default or
not. I would go as far as suggesting a run-time flag to disable the
use of exceptions. That way an app built on return codes will work
with a library that has exception handling turned on. It will be
mostly a free operation with little addtional code. No need to break
backwards compatibility when it's so easy to maintain it.

>>
>>2) Even if you always correctly catch errors (you expect) when you
>>   need to delete objects or handle the error, an unexpected exception
>>   could still result in leaks since you for whatever reason didn't
>>   handle it (sloppy programming or lack of knowledge of possible
>>   exceptions). 
>
> Ok, but an unexpected error return is far worse!
> An unexpected exception passes through several layours of the
> application until it is handled and the application can safely recover
> or cleanly exit.
> An unexpected error return goes totally unnoticed and the application
> either gets stuck or crashes without you having any chance to recover
> or even get an idea what the hell happened.

That pretty much depends on the case. It's easy to "hide" the fact
that something might thrown an exception (java is much better here
since you have to declare that a function can throw an exception
where in C++ this isn't the case). With return codes, you either get
one or you don't and you can see on the function whether or not it
returns something. Sure not handling the return code can have equally
bad results.

>>3) Exceptions are best used for exceptional errors. I.e errors that
>>   you cannot recover from. Using exceptions is slower than using
>>   normal error handling and does complicate coding in the case it's
>>   simply a warning or recoverable error.
>
> I totally agree there. Exceptions are a mechanism to report and handle
> bad errors. They are not intended to replace return results.

I would go as far as saying non-recoverable errors primarily. 

> So we should perhaps go into detail and ask: which occasion are in
> SDLmm where an exception might be thrown? 
>
> In my opinion, all File I/O errors should be handled through
> exceptions. Failed memory allocations as well (the new operator already
> does this, but SDL uses malloc...). 

As far as I know, you can't easily determine that an error in SDL
occured due to failed memory allocation. You get "-1" return code and
a textual representation of the error, not an "errno" type error
code. How do you know if it's a memory related error? :)


-- 
[ Below is a random fortune, which is unrelated to the above message. ]
All the troubles you have will pass away very quickly.

Re: [SDLmm-general] back in action

[Martin B. <bi...@as...>]

On Wed, 13 Apr 2005 11:11:58 -0700, David Hedbor wrote:


>I will now add the negative effects of exceptions.
>
>1) It complicates memory handling. I.e if you have code such as this:
>
>void myfunc() {
>  Type *data = new Type();
>  Type->do_something();
>  delete data;
>}

Then you have bad application code which you should fix, and not blame
SDLmm for it :->
Since exceptions are the standard C++ mechanism for reporting errors
and even the standard library uses them, you should write exception
safe code anyway, regardless if SDLmm uses it or not.


>I do_something throws an error which is recovered properly by the
>method calling myfunc, we now have leaked a reference to Type. Often
>this can be mostly fixed by using some sort of automatic or reference
>counted pointer object, but it's still a potental issue. 

But the goal of SDLmm is to provide a C++ abstraction of the SDL
functions. We shouldn't design the library around potential programs
that for whatever reason don't use the C++ mechanisms for automatic
memory management. If someone really wants to go the messy C way, he
can call SDL directly. 


>
>2) Even if you always correctly catch errors (you expect) when you
>   need to delete objects or handle the error, an unexpected exception
>   could still result in leaks since you for whatever reason didn't
>   handle it (sloppy programming or lack of knowledge of possible
>   exceptions). 

Ok, but an unexpected error return is far worse!
An unexpected exception passes through several layours of the
application until it is handled and the application can safely recover
or cleanly exit.
An unexpected error return goes totally unnoticed and the application
either gets stuck or crashes without you having any chance to recover
or even get an idea what the hell happened.


>3) Exceptions are best used for exceptional errors. I.e errors that
>   you cannot recover from. Using exceptions is slower than using
>   normal error handling and does complicate coding in the case it's
>   simply a warning or recoverable error.

I totally agree there. Exceptions are a mechanism to report and handle
bad errors. They are not intended to replace return results.

So we should perhaps go into detail and ask: which occasion are in
SDLmm where an exception might be thrown? 

In my opinion, all File I/O errors should be handled through
exceptions. Failed memory allocations as well (the new operator already
does this, but SDL uses malloc...). 



Regards,
   Martin

Re: [SDLmm-general] back in action

[David H. <da...@he...>]

Erich Herz <er...@gm...> writes:

> Hey everyone,
>
> I'm in process of cranking out a crappy gaim plugin, but I am hoping
> to start working on SDLmm really soon.  I know you are eager to see
> any work at all, since it's been 4 years since the last commit :P 
> This post is mainly to put things on the table for discussion.
>
> Now David has said that he has specifically left exceptions out of the
> library... I understand that a project goal is to stay as close to SDL
> as possible, which means, of course, using return values for error
> checking.  As much as I think this goal makes it easier on the
> programmer used to writing in SDL, I think that this attitude
> inherently means that some of the advantages of C++ are going to be
> lost (exception handling would be one, however small).  I'm of the
> opinion that, with some degree of restraint, perhaps this goal should
> be stretched a bit to allow for further development / improvement and
> not just a stagnant project.  David had already outlined his intention
> of adding "additional features" to SDLmm, such as the sprite class,
> but I wonder if this attitude can't be applied to the current source.
>
> Anyway, here's my case for exception handling:
>
> 1) Exceptions offer a consistent way of handling errors.  We know that
> if an error occurs within the library, an exception will be thrown. 
> No need to check error values, check global error variables, pass
> references or pointers to objects containing this type of information,
> etc...

This is true.

>
> 2) Exceptions reduce the amount of code the user of the library has to
> write.  Instead of having something like:
> if (SDL_CreateSurface(...) == -1) {
>    /* error handling code */
> }
> and then having to rewrite the same construct again each time we call
> a function, we need only put the body of main inside a try block, and
> we can write code without having to _worry_ about error handling.
>
> Motto: "less code? yayyy!"

Also true.

> 3) Exceptions can hold additional information about the error, and not
> just an error code or something retrieved from a global variable.  I
> know this is an advantage, somehow... :)

Yes, this is true as well.


I will now add the negative effects of exceptions.

1) It complicates memory handling. I.e if you have code such as this:

void myfunc() {
  Type *data = new Type();
  Type->do_something();
  delete data;
}

I do_something throws an error which is recovered properly by the
method calling myfunc, we now have leaked a reference to Type. Often
this can be mostly fixed by using some sort of automatic or reference
counted pointer object, but it's still a potental issue. If automatic
pointers aren't used, you would get code like (pseudocode example):

void myfunc() {
  Type *data = new Type();
  try { Type->do_something();}
  catch ExpectedError err { delete data; throw err; }
  delete data;
}

which really isn't an much improvement over:

bool myfunc() {
  Type *data = new Type();
  if(Type->do_something() != OK) 
  { delete data; return false; }
  delete data;
  return true;
}

2) Even if you always correctly catch errors (you expect) when you
   need to delete objects or handle the error, an unexpected exception
   could still result in leaks since you for whatever reason didn't
   handle it (sloppy programming or lack of knowledge of possible
   exceptions). 

3) Exceptions are best used for exceptional errors. I.e errors that
   you cannot recover from. Using exceptions is slower than using
   normal error handling and does complicate coding in the case it's
   simply a warning or recoverable error.

I'm not saying no to exceptions entirely but I'd really want to keep
the "original" calling conventions there, perhaps with a define. Also
SDL already has an error reporting mechanism. Sure it's a global error
string, but it's there. I could definitely see an error object used
which at its creation queries the error string and is then
thrown. However from Java programming, where exceptions are used
exclusively for errors, I can tell by experience that exceptions
doesn't make programming easier (well C++ exceptions are somewhat
different but similar never the less).

> There's a good discussion about exceptions on this page, if you're interested:
> http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=77463
>
> Exceptions aside, before I actually DO anything, I want to read
> through the code thoroughly, and alongside reading, fixing it up a bit
> ... is there any coding convention being used for the project right
> now?

Err. Yes. Mine. :) Seriously, I typically write code like this:

void foo(int x, string y) {
  char *bar;
  int i;
  if(bar == NULL) {
    ...
  } else if(foo) {
    ...	 
  }
  switch(i) {
  case 10:
    hello;
  case 1:
    gazonk
  }
}

with 2 character indentation, tab being set to the "standard" 8
characters. Emacs uses tabs/spaces automatically for indentation
although I'm not against changing it to be purely spaces. Just don't
code with an app that uses 2 or 4 or whatever char / tab. I also
don't like code such as:

if(X) {
} else 
  if(Y) {
  } else
    if(x) {
    }
since it is rather unclear and space wasting compared to 

if(X) {
} else if(Y) {
} else if(x) {
}

I sometimes uses 

void foo()
{
}

for functions.

> Anyway, I'd like very much to hear peoples' feedback about exception
> handling.  Any additional concerns / requests / comments about the
> library, or what could be done better would make my job a lot easier.

Making it use either would be great:

bool Display:Init(..) {
  int success = SDL_Init(..) == 0;
#ifdef USE_EXCEPTIONS
  if(!success) {
    throw new SDLmm::Exception(ret);
  }
#endif
  return success;
}

That would be backwards and SDL compatible with optional C++
exception error handling.

I should say though that I haven't entirely stuck to SDL standard
return codes. I typically translate the response to a boolean (true ==
success, false == error) where possible (i.e where SDL only has one
error response). SDL typically uses -1 for ERROR, and 0 for OK. I like
'true' to be OK not ERROR. :)

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
You'll wish that you had done some of the hard things when they were easier
to do.

[SDLmm-general] SDLmm

[Matthew A. N. <the...@ya...>]

I am happy to see a new developer on the project.  I just wanted to say I am 
happy you have decided to use exceptions and I also wanted to volunteer my 
services if you need any help on the project.  I have attempted to develop a 
small pong clone in C++ using SDL and looking back on that project really made 
me wish there were c++ bindings for sdl.  With that said, I started programming 
in C++ a few years ago (4?), and have recently been reading through The C++ 
Programming Language, a very good read.

There is a need for this project and if you need any assistance with this I 
would be happy to help.
-- 
Matthew A. Nicholson
Matt-land.com

Re: [SDLmm-general] back in action

[Martin B. <bi...@as...>]

Hi,

it's nice to see some action at the SDLmm project again.

We are using SDLmm for Advanced Strategic Command (www.asc-hq.org). The
current version does not use it very much, but ASC2, which is currently
under development, uses it to a much greater extent. Since we are using
Paragui for dialogs in ASC2, I'll keep an eye that both libraries get
along each other :)

To make packaging and building of ASC easier, we included SDLmm in the
ASC source package, so I could fix several problems with SDLmm without
the need for an official SDLmm release. I'm attaching a patch with the
fixes. 

The patch does not include changes that were necessary for building
SDLmm with Borland C++ Builder. The RCSID macros caused conflicts, so I
removed them all. IMHO, they have nothing lost in the global namespace.
I suggest, if they are need at all, to at least put them into the SDLmm
namespace. 


I also agree that error handling using exceptions is better than the
current use of return codes. 



Martin

[SDLmm-general] back in action

[Erich H. <er...@gm...>]

Hey everyone,

I'm in process of cranking out a crappy gaim plugin, but I am hoping
to start working on SDLmm really soon.  I know you are eager to see
any work at all, since it's been 4 years since the last commit :P 
This post is mainly to put things on the table for discussion.

Now David has said that he has specifically left exceptions out of the
library... I understand that a project goal is to stay as close to SDL
as possible, which means, of course, using return values for error
checking.  As much as I think this goal makes it easier on the
programmer used to writing in SDL, I think that this attitude
inherently means that some of the advantages of C++ are going to be
lost (exception handling would be one, however small).  I'm of the
opinion that, with some degree of restraint, perhaps this goal should
be stretched a bit to allow for further development / improvement and
not just a stagnant project.  David had already outlined his intention
of adding "additional features" to SDLmm, such as the sprite class,
but I wonder if this attitude can't be applied to the current source.

Anyway, here's my case for exception handling:

1) Exceptions offer a consistent way of handling errors.  We know that
if an error occurs within the library, an exception will be thrown. 
No need to check error values, check global error variables, pass
references or pointers to objects containing this type of information,
etc...

2) Exceptions reduce the amount of code the user of the library has to
write.  Instead of having something like:
if (SDL_CreateSurface(...) == -1) {
   /* error handling code */
}
and then having to rewrite the same construct again each time we call
a function, we need only put the body of main inside a try block, and
we can write code without having to _worry_ about error handling.

Motto: "less code? yayyy!"

3) Exceptions can hold additional information about the error, and not
just an error code or something retrieved from a global variable.  I
know this is an advantage, somehow... :)

There's a good discussion about exceptions on this page, if you're interested:
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=77463

Exceptions aside, before I actually DO anything, I want to read
through the code thoroughly, and alongside reading, fixing it up a bit
... is there any coding convention being used for the project right
now?

Anyway, I'd like very much to hear peoples' feedback about exception
handling.  Any additional concerns / requests / comments about the
library, or what could be done better would make my job a lot easier.

Thanks all,
Erich Herz

[SDLmm-general] New developer

[David H. <da...@he...>]

Just added Erich Herz to the list of developers for this project. This
might help returning it from its current hiatus. :)

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
Clothes make the man.  Naked people have little or no influence on society.
		-- Mark Twain

Re: [SDLmm-general] sdlmm and Debian

[Bartosz F. a. f. <fe...@o2...>]

On Tue, May 11, 2004 at 09:59:22PM +0200, Martin Bickel wrote:
> Hey, some traffic on this mailing list :-)

:)
=20
> I'm the author of ASC and very much like the idea of making a debian
> package of ASC :-)

Oh... so you were next person which I'd like to write to ;)
May I use your e-mail with talks related to ASC packaging?
I mean you use some Yahoo groups for development issues, but I tried to
subscribe to it, and got problems with it.

In fact such personal contact would be much better for me.
Or maybe there are dozens of developers, then I certainly start working on
this mailing lists ;)
=20
> But regarding SDLmm, your message is the first one on this list for
> more than 2 years, so I doubt if there is much usage of SDLmm apart
> from ASC (which makes most of its graphic handling without SDLmm...).

Doh... I should check archives first ;)
=20
> We also have the option of merging the current SDLmm version into the
> ASC source (there is a library directory with other libraries) and
> don't bother about making two distinct packages.=20

That would be great. I mean packaging libraries isn't the esiest and=20
the most pleasant task ;)

One more question... when do you intend to merge this library?
I can't start packaging without that.

Thanks a lot for answer.

regards
fEnIo

--=20
      _      Bartosz Fenski | mailto:fe...@o2... | pgp:0x13fefc40 | IRC:fEn=
Io
    _|_|_     32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska
    (0 0)          phone:+48602383548 | Slackware - the weakest link
ooO--(_)--Ooo  http://skawina.eu.org | JID:fe...@ja... | RLU:172001

Re: [SDLmm-general] sdlmm and Debian

[Martin B. <bi...@as...>]

On Tue, 11 May 2004 00:30:50 +0200, Bartosz Fenski aka fEnIo wrote:

>I'm trying to package Advanced Strategic Command (free, turn-based
>strategy game) for Debian. It depends on your c++ wrapper,=20
>which unfortunatelly is absent in Debian too.
>
>What do you think about packaging it?
>I mean may I count on you with SDLmm specific problems which could
>occure during packaging/maintaining?
>
>SDLmm in Debian would be probably useful for you too. Debian is known as
>one of the distribution which supports very much architectures.
>You will have possibility to look at build logs from them.
>This could help you to achieve one of your main task - portability.=20

Hey, some traffic on this mailing list :-)

I'm the author of ASC and very much like the idea of making a debian
package of ASC :-)

But regarding SDLmm, your message is the first one on this list for
more than 2 years, so I doubt if there is much usage of SDLmm apart
from ASC (which makes most of its graphic handling without SDLmm...).

We also have the option of merging the current SDLmm version into the
ASC source (there is a library directory with other libraries) and
don't bother about making two distinct packages. 


Regards,
   Martin

[SDLmm-general] sdlmm and Debian

[Bartosz F. a. f. <fe...@o2...>]

Hello SDLmm developers.

I'm trying to package Advanced Strategic Command (free, turn-based
strategy game) for Debian. It depends on your c++ wrapper,=20
which unfortunatelly is absent in Debian too.

What do you think about packaging it?
I mean may I count on you with SDLmm specific problems which could
occure during packaging/maintaining?

SDLmm in Debian would be probably useful for you too. Debian is known as
one of the distribution which supports very much architectures.
You will have possibility to look at build logs from them.
This could help you to achieve one of your main task - portability.=20

Anyway, just tell me what do you think about it.
Thanks a lot for any comments/suggestions.

regards
fEnIo

ps. I've just subscribed to your mailing list, so please don't CC me.

--=20
      _      Bartosz Fenski | mailto:fe...@o2... | pgp:0x13fefc40 | IRC:fEn=
Io
    _|_|_     32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska
    (0 0)          phone:+48602383548 | Slackware - the weakest link
ooO--(_)--Ooo  http://skawina.eu.org | JID:fe...@ja... | RLU:172001

Re: [SDLmm-general] SDLmm configure.in

[Martin B. <ma...@as...>]

On Thu, 13 Mar 2003 13:26:12 +0200, I.S.Kuten wrote:

>I have a problem to include SDLmm to my application on ./configure stage .
>[...]
>configure:4555: gcc -o conftest -g -O2 -I/usr/include/SDL -D_REENTRANT   conftest.c  -L/usr/lib -Wl,-rpath,/usr/lib -lSDL

Looks like you need to tell autoconf that you are writing a C++ program
instead of a C program. If I recall correctly, the macro for that is
AC_LANG_CPLUSPLUS .

Regards,
  Martin

[SDLmm-general] SDLmm configure.in

[I.S.Kuten <i....@sa...>]

I have a problem to include SDLmm to my application on ./configure stage .

this is a part of my configure.in

CFLAGS="$CFLAGS $SDL_CFLAGS"
LIBS="$LIBS $SDL_LIBS"
CXXFLAGS="$CFLAGS"
    
dnl Check for SDLMM 
    
AM_PATH_SDLMM($SDLMM_VERSION,
            :,
            AC_MSG_ERROR([*** SDLMM version $SDLMM_VERSION not found!])
)


What's wrong ?


----------------------- configure.log--------------------------------
configure:4426: checking for sdlmm-config
configure:4444: found /usr/bin/sdlmm-config
configure:4457: result: /usr/bin/sdlmm-config
configure:4465: checking for SDLmm version >= 0.1.8
configure:4555: gcc -o conftest -g -O2 -I/usr/include/SDL -D_REENTRANT   conftest.c  -L/usr/lib -Wl,-rpath,/usr/lib -lSDL
In file included from /usr/include/SDLmm/sdlmm.h:125,
                 from configure:4512:
/usr/include/SDLmm/sdlmm_global.h:27: parse error before "SDLmm"
/usr/include/SDLmm/sdlmm_global.h:27: syntax error before '{' token
/usr/include/SDLmm/sdlmm_global.h:78: parse error before '}' token
In file included from /usr/include/SDLmm/sdlmm.h:126,
                 from configure:4512:
/usr/include/SDLmm/sdlmm_spoint.h:24: syntax error before '{' token
/usr/include/SDLmm/sdlmm_spoint.h:40: parse error before '&' token
/usr/include/SDLmm/sdlmm_spoint.h:48: parse error before ':' token
/usr/include/SDLmm/sdlmm_spoint.h:55: `point' undeclared here (not in a function)
/usr/include/SDLmm/sdlmm_spoint.h:56: parse error before '}' token
/usr/include/SDLmm/sdlmm_spoint.h:140: conflicting types for `y'
/usr/include/SDLmm/sdlmm_spoint.h:55: previous declaration of `y'
/usr/include/SDLmm/sdlmm_spoint.h:141: parse error before '}' token
I

[SDLmm-general] SEL

[David H. <da...@he...>]

Heya. Reading the SDL mailing list I just found out about SEL. Looking
at the code I see that it seems to be based on SDLmm (both in code and
spirit, i.e trying to create a C++ wrapper lib with "the same" syntax
as SDL). 

That said, I first have a complaint - you have used code from SDLmm
(which is fine) w/o maintaining the original copyright. That's not OK.
Any files which has any SDLmm code in them need to have my copyright
in them as well (i.e shared copyright). AUTHORS should also mention me
(and the others who have worked on SDLmm really).

Now, I have a proposition to make - from my point of view SEL is SDLmm
at a later stage in the development game. Thus developing SDLmm (which
I haven't done much about recently due to being too busy in other
areas) would pretty much be a waste of time.

Thus, how would you feel about a merge of efforts? I would dismantle
SDLmm in favor of SEL, and would get developer access and such for
SEL. If this were to happen, I would suggest this:

 - Copyright statement changed to The SEL Group (or something like
   that - an entity instead of individuals).
 - AUTHORS would list all people part of the project.
 - If someone submits code, the copyright should be transferred from
   them to the project.
 - Add some CVS access, not necessarily on SF but still. CVS would be
   a nice-to-have feature.

Adam Gates is the other major contributor to SDLmm and if he's
interested he should of course be able to join SEL as well.

Comments on this proposition? It's really very dumb to have two
"identical" but split efforts.

	-- dh

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
My sister opened a computer store in Hawaii.  She sells C shells down 
by the seashore.

[SDLmm-general] SDLmm, Paragui - some thoughts

[David H. <da...@he...>]

Ok, after starting the SDLmm project, I started using ParaGUI for a
couple of apps (latest being a puzzle game). Well, what I've noticed
so far is that with ParaGUI I don't feel a need for SDLmm in most
cases. So that made me start thinking - perhaps it's better to build
more low-level SDL stuff into ParaGUI (kind of a merge of the good
features from SDLmm). Examples could be object oriented surfaces
(which really is what SDLmm is about right now). Using
SDL_BlitSurface, SDL_Fill etc feels primitive compared to using the
architecture in SDLmm. On the other hand, those features aren't really
enough to warrant the use of SDLmm _with_ ParaGUI.

Adam, you are on the ParaGUI list too it seems. What do you think? I'm
a ParaGUI developer as well and I notice myself both using and
programming ParaGUI more than SDLmm. It's simply easier for A LOT of
things (and harder for some, lower-level stuff).

Comments?

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
What do you have when you have six lawyers buried up to their necks in sand?
Not enough sand.

[SDLmm-general] release

[David H. <da...@he...>]

I have released 0.1.8 now. However the files are not yet visible for
some reason. In any case, Adam, do you want to create a VC6 binary release?
-- 
[ Below is a random fortune, which is unrelated to the above message. ]
Humor in the Court:
Q: Now, you have investigated other murders, have you not, where there was
   a victim?

[SDLmm-general] code style

[Adam G. <ad...@pr...>]

I recently had a look at "Artistic Style" (
http://astyle.sourceforge.net/ ).

Seems pretty good to me. What do you think we use it on sdlmm to keep
the style
consistent? If we do chose to use it which options should we use?

Adam.

Re: [SDLmm-general] The very last question

[Andreas K. <ak...@ix...>]

On Mon, Jul 23, 2001 at 02:11:36PM -0700, David Hedbor wrote:
> I would like to cooperate, but the main issue is the difference in
> goals. You want an STL like interface to SDL etc, while SDLmm aim for
> an SDL like interface. Are you willing to change? Probably not. Are
> we? Probably not. So what else can we do?

Hmm, you're probably right.
I wish you good luck on your journey.

Andreas

[SDLmm-general] CHANGES file

[David H. <da...@he...>]

I added a CHANGES file to point out the differences since the last
release. Did I forget anything?
-- 
[ Below is a random fortune, which is unrelated to the above message. ]
Larkinson's Law:
	All laws are basically false.

Re: [SDLmm-general] The very last question

[David H. <da...@he...>]

Andreas Kloeckner <ak...@ix...> writes:

> On Mon, Jul 23, 2001 at 09:19:10AM +1000, Adam Gates wrote:
> > Sorry for ignoring your emails. I was leaving it to David to answer as
> > he is the leader.
> > 
> > I have had a look at your code for sdlucid. And I must say I don't like
> > it. At least not for sdlmm. Sdlmm is only trying to be a c++ wrapper for
> > sdl. It should have no dependencies on other libraries.
> 
> As I've said before, if it's only about the library dependency - forget it.
> That code could be integrated into the wrapper in case ixlib isn't present.

The one main issue in my opinion is that SDLmm aim to be extremely
close to the SDL syntax, whether it's a good idea or not. I know that
SDL doesn't have the most consistent function names etc, but if a
library had completely different syntax, like your lib, that does make
the initial learning curve higher for someone who already knows SDL.

> > We already have
> > the video stuff completed.
> 
> i.e. wrapped. No additional functionality, no additional abstraction?
> Is this what you want? 

No, not quite. Wrapped as in similar syntax. We will have additional
functionality like drawing primitives etc (we already have some).

> > The only other area you have covered seems to
> > be audio. I am not that familiar with the audio side as I haven't
> > actually used it or seen an example.
> 
> I don't know whether integrating your video and my audio would be a good
> idea.

I would like to cooperate, but the main issue is the difference in
goals. You want an STL like interface to SDL etc, while SDLmm aim for
an SDL like interface. Are you willing to change? Probably not. Are
we? Probably not. So what else can we do?

-- 
[ Below is a random fortune, which is unrelated to the above message. ]
Cahn's Axiom:
	When all else fails, read the instructions.