Yeah, this question keeps being ignored. I believe mostly because
attempts at SavePNG are being compared to Load/SaveBMP in that the
latter doesn’t have any dependencies and amount of code is minimal, so
it doesn’t present a maintenance burden, SDL not being and image i/o
library and there existing the SDL_image.
The argument for existence of BMP support is that some very basic
functionality for loading and saving images in core SDL is useful for
code samples and tests, and for that anything more complicated there
are other libraries.
I fully support that view, except that BMP format has, well, no
compression whatsoever, and incurs additional steps to convert images
to or from it, or additional burden of pulling in SDL_image with its
dependencies and writing requisite glue code, however minimal it has
to be, if one wants to try a test or code sample on a random image
from the net, or upload a screenshot.
Consider the mobile devices, now actively targeted by the SDL. They
don’t have that much memory, or I/O bandwidth, but start to have
screen resolutions big enough so that making screen- or rather
window-shots with SaveBMP becomes sluggish, while eating memory and
flash space. On the other hand, pulling in SDL_image here is not just
an “apt-get install”, even if SDL2 was already released. All while
from what I’ve seen, many apps can get by using only png and rarely
need anything else SDL_image has to offer.
BMP-only in core was ok for desktop-only environment. But it isn’t adequate now.
On the code size:
$ wc -l SDL_bmp.c
567 SDL_bmp.c
$ wc -l SDL_pnglite.c pnglite.c
437 SDL_pnglite.c
1005 pnglite.c
1442 total
pnglite+wrapper is three times larger, but it’s still only 1,5k lines.
And depends only on libz, which probably has larger install base than
C standard library.–
./lxnt
