Reading RLE compressed BMP

I have extended SDL_bmp.c in order to read RLE_8 and RLE_4 BMP format.
Actually, it runs in my sandbox, but I’d like to have it officially integrated
(it’s not big and complex: just a few tenths of lines!)

Would that be accepted? More generally: how to contribute?
Sam?

Pierre.

Seems like something better to not support, in order to help hasten the
death of BMP …On Sun, Jun 27, 2004 at 08:49:36AM +0000, Pierre G.Richard wrote:

I have extended SDL_bmp.c in order to read RLE_8 and RLE_4 BMP format.
Actually, it runs in my sandbox, but I’d like to have it officially integrated
(it’s not big and complex: just a few tenths of lines!)


Glenn Maynard

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le mardi 29 Juin 2004 01:59, Glenn Maynard a ?crit :> On Sun, Jun 27, 2004 at 08:49:36AM +0000, Pierre G.Richard wrote:

I have extended SDL_bmp.c in order to read RLE_8 and RLE_4 BMP format.
Actually, it runs in my sandbox, but I’d like to have it officially
integrated (it’s not big and complex: just a few tenths of lines!)

Seems like something better to not support, in order to help hasten the
death of BMP …

I think that this kind of comment is misplaced. You have to give the choice to
the developers to use formats adapted to their problems.

Just think of people which MUST take care of RLE compressed BMP’s… maybe
they think like you but cannot afford being so strict.

This is a place for tolerance and charity : let people do mistakes, they will
better understand by themselves.


Michel Nolard
3? Ma?trise en Informatique
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA4TIfyAKwOMHoSb0RAiVAAJ9mjWfxp8//8GeUz2S8COBTJ1Q7SgCeIV+I
EQjh2bSbmDmjLgXhmp6NCXU=
=e3FN
-----END PGP SIGNATURE-----

Seems like something better to not support, in order to help hasten the
death of BMP …

I think that this kind of comment is misplaced. You have to give the choice to
the developers to use formats adapted to their problems.

I tend to agree with Michel.

The death of BMPs may be a desirable thing, but the current SDL spec
advertises support for BMPs, so until that changes, it’s best to support
BMPs as completely as possible. What do other people think?

-Chris
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040629/89d2dd71/attachment.pgp

Thanks to both of you Michel and Chris.

Understand I have no intend to start a mail war in this newsgroup. That is
Glenn’s POV, if he’s happy with, I’m happy with.
Me think: either BMP is supported, or is not supported. Fact is that it is
supported. Legacy? Who cares. Not my point.

SDL_image – implements JPeg, GIF, png, etc…-- uses SDL_LoadBitmap for BMP,
and SDL_LoadBitmap doesn’t do RLE4 and RLE8, which is, IMHO, a hole because
naive customers – what counts at the end – won’t see it.

SDL_image does a bunch of formats. I don’t want to discuss if such or such
format is politicaly correct or not. I want my customers to see any images.
I did it as a programmer, not as a bright political.

And wanted to know if and how I could have the SDL community share my work,
without imposing my humble person.

Thanks to both of you Michel and Chris.

Understand I have no intend to start a mail war in this newsgroup. That is
Glenn’s POV, if he’s happy with, I’m happy with.
Me think: either BMP is supported, or is not supported. Fact is that it is
supported. Legacy? Who cares. Not my point.

SDL_image – implements JPeg, GIF, png, etc…-- uses SDL_LoadBitmap for BMP,
and SDL_LoadBitmap doesn’t do RLE4 and RLE8, which is, IMHO, a hole because
naive customers – what counts at the end – won’t see it.

SDL_image does a bunch of formats. I don’t want to discuss if such or such
format is politicaly correct or not. I want my customers to see any images.
I did it as a programmer, not as a bright political.

Since a discussion of the political correctness of an image format is
pretty far off topic would someone please send me a message off list
that explains what is wrong with .bmp format? And, what could be wrong
with using it?

And wanted to know if and how I could have the SDL community share my work,
without imposing my humble person.

I for one appreciate what you have done and hope your patch is accepted.
Bob PendletonOn Tue, 2004-06-29 at 06:14, Pierre G.Richard wrote:


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

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

The comment is completely appropriate; it was intended (and successful) in
making people spend at least a moment giving consideration to the costs of
supporting old, nearly dead formats (slightly reproliferating its use, and
all of the costs associated with maintaining code that very few will use).On Tue, Jun 29, 2004 at 11:10:55AM +0200, Michel Nolard wrote:

Seems like something better to not support, in order to help hasten the
death of BMP …

I think that this kind of comment is misplaced. You have to give the choice to
the developers to use formats adapted to their problems.


Glenn Maynard

This is not the list for discussing your personal prejudices. Take it
somewhere else.

Improving the support for BMPs, or any other image type, is a valuable
and useful service to the people who use them. Telling people what they
should do is a lot like trying to teach a pig to sing, it wastes your
time and it annoys the pig.

	Bob PendletonOn Tue, 2004-06-29 at 14:25, Glenn Maynard wrote:

On Tue, Jun 29, 2004 at 11:10:55AM +0200, Michel Nolard wrote:

Seems like something better to not support, in order to help hasten the
death of BMP …

I think that this kind of comment is misplaced. You have to give the choice to
the developers to use formats adapted to their problems.

The comment is completely appropriate; it was intended (and successful) in
making people spend at least a moment giving consideration to the costs of
supporting old, nearly dead formats (slightly reproliferating its use, and
all of the costs associated with maintaining code that very few will use).


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

This is not the list for discussing your personal prejudices. Take it
somewhere else.

I’m sorry that you find the desire that code be maintainable, and not be
burdened with support for ancient, dead legacy formats that almost nobody
uses, to be a “personal prejudice”.

Improving the support for BMPs, or any other image type, is a valuable
and useful service to the people who use them. Telling people what they
should do is a lot like trying to teach a pig to sing, it wastes your
time and it annoys the pig.

You’ve used that expression before, in a rude response to a friendly
suggestion that you edit quotations. It was no more appropriate then.

(I’m not interested in attempts to berate a simple question of “is this feature
worthwhile?”–a question that should be asked before every new feature in every
project, and rarely is–as “personal prejudices”, and they are, in fact,
off-topic here; so I won’t be further replying to responses to this subthread.)On Tue, Jun 29, 2004 at 02:34:57PM -0500, Bob Pendleton wrote:


Glenn Maynard

Chris Nelson wrote:

I tend to agree with Michel.

The death of BMPs may be a desirable thing, but the current SDL spec
advertises support for BMPs, so until that changes, it’s best to support
BMPs as completely as possible. What do other people think?

I remember at least one previous requests for RLE bmp support in SDL. If
I remember one, that means there were quite a few :slight_smile:
So that seems a good idea.

Stephane

If we were big enough to tell M$ what to do, we might be able to
kill BMP, but as that’s not the case, I guess we’ll just have to
accept that BMPs show up every now and then, and people will want to
be able to load them. Not all SDL applications are games…

Or maybe we should split SDL_image into one minimal version for games
and other apps where the developers can control what formats are
used, and one add-on library that aims to load anything thrown at it,
within reasonable limits?

Now, if we really want to do anything about obsolete formats, I think
it would make more sense to drop SDL_SaveBMP(). It is currently the
only way to save images without going beyond SDL and SDL_image, and
consequently, the reason why many games use the “obsolete” BMP format
for screenshots. PNG and/or JPG saving in SDL_image, or in a new
SDL_saveimage lib would be a lot nicer, IMHO.

Sure, as it is, you can avoid an extra lib dependency and still get
screenshots - but those screenshots will be in BMP format, which is
anything from slightly annoying to completely unacceptable, depending
on your POV. And unless you’re using BMP for your graphics data, you
most probably already depend on some lib (ie libpng) that could do
the saving as well, so it’s kinda’ silly not to use it…

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Wednesday 30 June 2004 00.52, Glenn Maynard wrote:

On Tue, Jun 29, 2004 at 02:34:57PM -0500, Bob Pendleton wrote:

This is not the list for discussing your personal prejudices.
Take it somewhere else.

I’m sorry that you find the desire that code be maintainable, and
not be burdened with support for ancient, dead legacy formats that
almost nobody uses, to be a “personal prejudice”.

I have extended SDL_bmp.c in order to read RLE_8 and RLE_4 BMP format.
Actually, it runs in my sandbox, but I’d like to have it officially integrated
(it’s not big and complex: just a few tenths of lines!)

Would that be accepted? More generally: how to contribute?
Sam?

Go ahead and submit a patch to the mailing list. If the code is sufficiently
simple, I’ll be happy to add it to CVS.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment