Pnglite wrapper

SDL Development
21

For what it’s worth, I’m pro this (dropping the BMP function entirely).

Seems crazy to have this bundled as part of SDL to me; just drop libpng
into your application if you want png support. It’s documented extensively
and already ported to pretty much everything.~
Doug.

On Mon, Dec 17, 2012 at 6:00 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

I think the problem is that 1.3 was probably the time to do that
(which is when the API kept changing all the time). The jump to 2.0 is
what set the API as being considered stable (as in what’s there will
remain there), unless I misunderstood something.

And yeah, if it was me, I’d rather just get rid of the LoadBMP
altogether (along with SaveBMP, LoadWAV and SaveWAV). In tutorials
loading bitmaps could be a good time to teach newcomers to use the
satellite libraries while for tests we could probably just generate
some quick assets procedurally to do the job.

2012/12/16 Rodrigo :

Since SDL2 is already not backward compatible, this is the right time to
get
rid of that IMO.
SDL2 is not officially realeased it should not a a problem to break some
stuff. Dont you think?

Date: Sun, 16 Dec 2012 17:01:38 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>

To: SDL Development List
Subject: Re: [SDL] pnglite wrapper
Message-ID:

<CAEyBR+U_JwTJ8WCdV_GJ-jcLmUU3x450URntgvL6wCkZWxe1qw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

If I recall correctly, Paint doesn’t even support BMP anymore. At
least for saving. But yeah, there’s the problem you can’t get rid of
SDL_LoadBMP without breaking lots of tutorials and the like - but
adding a second format would then lend to the question of “why not add
more” and result in requests for adding more popular formats (at the
very least JPEG and GIF), which then makes us wonder why shouldn’t the
functions just be used for loading images in general (defeating
SDL_Image’s purpose).

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

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

22

Isn’t libpng already present on all platforms that SDL supports?

23

It’s present on pretty much anything supporting C because libpng is
platform agnostic. Same deal with zlib (which it depends upon).
There’s a generic makefile that will build anywhere.

I think the thing here would be to which languages it got ported (i.e.
bindings), but considering its popularity it’s probably available for
every popular language out there and then some more.

2012/12/17 John :> Isn’t libpng already present on all platforms that SDL supports?

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

24

“Presence” is not really the deal here (and I would differentiate between
compatibility and presence, which implies a default system-wide
installation). I personally would rather that SDL_LoadBMP() be removed to
clean up the core and make it clear that if you really want images loaded
from files, use SDL_image and don’t be fooled into thinking that SDL only
handles BMP.

As far as that, I think this should not be a discussion for including PNG
decode into SDL core. It should be for replacing libpng in
SDL_image. It’s a choice that needs a lot of testing to see what kind of
subformat coverage any replacement has and I think the whole reason for
loading libpng dynamically is because it is constantly being improved.
There’s not much you could do to argue against libpng without collecting a
lot of data.

Jonny DOn Mon, Dec 17, 2012 at 8:19 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

It’s present on pretty much anything supporting C because libpng is
platform agnostic. Same deal with zlib (which it depends upon).
There’s a generic makefile that will build anywhere.

I think the thing here would be to which languages it got ported (i.e.
bindings), but considering its popularity it’s probably available for
every popular language out there and then some more.

2012/12/17 John :

Isn’t libpng already present on all platforms that SDL supports?

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

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

25

Setting up the windows - note the plural, handling the events, setting
up GL context, using the RWops framework, maybe some audio, there’s
much in SDL besides renderers. And, yes, loading image data. If one
uses SDL_image, one pretty much has to use SDL_Surface, there’s no
other way without writing your own wrappers, and why do that?On Mon, Dec 17, 2012 at 12:01 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

Also about this:

Besides, SDL_Texture is there only if one actually uses SDL renderers
for rendering, which isn’t exactly the case with direct use of OpenGL/GLES.

If you use GL directly then you directly skip SDL for everything
except setting up the window. You use neither SDL_Texture nor
SDL_Surface.

–

./lxnt

26

That goes contrary to the goal of a tutorial - show how to do things,
preferably one single thing per tutorial, and do this as simple as
possible.

Pulling in extra dependencies only increases entry “costs”.

And procedural generation is only going to confuse the hell out of
people. Even ones writing those same tutorials.

No, those basic loaders/savers should stay there. I only argue for
adding a trivial PNG one, seeing and feeling how BMP is obsolete.

Note that this is trivial code. It isn’t fast. It doesn’t do any
filtering or optimization on save. It doesn’t support 16 bpc images.
It has a couple memcpy()s per load that could be removed. It could
decode image directly into SDL_Surface, taking pitch and pixel format
into account on the fly, but does not, and same for encode.

It is written for easy maintenance, not performance or features. If
you need the latter two, go for SDL_image or libpng directly, by all
means.On Mon, Dec 17, 2012 at 2:00 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

And yeah, if it was me, I’d rather just get rid of the LoadBMP
altogether (along with SaveBMP, LoadWAV and SaveWAV). In tutorials
loading bitmaps could be a good time to teach newcomers to use the
satellite libraries while for tests we could probably just generate
some quick assets procedurally to do the job.

–

./lxnt

27

2012/12/18 Alexander Sabourenkov :

Setting up the windows - note the plural, handling the events, setting
up GL context, using the RWops framework, maybe some audio, there’s
much in SDL besides renderers. And, yes, loading image data. If one
uses SDL_image, one pretty much has to use SDL_Surface, there’s no
other way without writing your own wrappers, and why do that?

I was talking specifically about the video part. Handling the
window(s) is the only non-portable thing in OpenGL, so you’d use SDL
for that, but for the actual drawing and such you wouldn’t touch SDL
at all, just use OpenGL as-is.

2012/12/18 Alexander Sabourenkov :

That goes contrary to the goal of a tutorial - show how to do things,
preferably one single thing per tutorial, and do this as simple as
possible.

Depends. If you’re teaching how to load an image or a sound, you’re
probably better off teaching how to get up SDL_Image or SDL_Mixer
running, given they’re what you should be using for the job really. If
you’re teaching how to show something on screen or something like
that, you’re already teaching two things at the same time (since
you’re also teaching how to load something).

I see no reason why we should let anybody be taught how to do things
the dirty way when we could directly teach how to do things with the
proper tools.

And procedural generation is only going to confuse the hell out of
people. Even ones writing those same tutorials.

Not necessarily, even simple formulas can be useful. Heck, the XOR
texture became famous because of how trivial it is (literally x xor y)
despite looking a lot better than most programmer art.

28

How about moving the SaveBMP function in SDL_image and add the SavePNG API
in SDL_image too?
SavevBMP is old but it could be useful under certain scenarios; maybe its
place in the main library it’s a little off…
VittorioOn Tue, Dec 18, 2012 at 8:59 AM, Alexander Sabourenkov wrote:

On Mon, Dec 17, 2012 at 2:00 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

And yeah, if it was me, I’d rather just get rid of the LoadBMP
altogether (along with SaveBMP, LoadWAV and SaveWAV). In tutorials
loading bitmaps could be a good time to teach newcomers to use the
satellite libraries while for tests we could probably just generate
some quick assets procedurally to do the job.

That goes contrary to the goal of a tutorial - show how to do things,
preferably one single thing per tutorial, and do this as simple as
possible.

Pulling in extra dependencies only increases entry “costs”.

And procedural generation is only going to confuse the hell out of
people. Even ones writing those same tutorials.

No, those basic loaders/savers should stay there. I only argue for
adding a trivial PNG one, seeing and feeling how BMP is obsolete.

Note that this is trivial code. It isn’t fast. It doesn’t do any
filtering or optimization on save. It doesn’t support 16 bpc images.
It has a couple memcpy()s per load that could be removed. It could
decode image directly into SDL_Surface, taking pitch and pixel format
into account on the fly, but does not, and same for encode.

It is written for easy maintenance, not performance or features. If
you need the latter two, go for SDL_image or libpng directly, by all
means.

–

./lxnt

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

29

I was talking specifically about the video part. Handling the
window(s) is the only non-portable thing in OpenGL, so you’d use SDL
for that, but for the actual drawing and such you wouldn’t touch SDL
at all, just use OpenGL as-is.

Your point? Pure GL apps still have a good use for SDL_Surface -
SDL_image, SDL_ttf et al.

Depends. If you’re teaching how to load an image or a sound, you’re
probably better off teaching how to get up SDL_Image or SDL_Mixer
running, given they’re what you should be using for the job really. If
you’re teaching how to show something on screen or something like
that, you’re already teaching two things at the same time (since
you’re also teaching how to load something).

Yes and no. If the subject is how to use external libraries then yes.
Otherwise, you’re not teaching resource acquisition.

I see no reason why we should let anybody be taught how to do things
the dirty way when we could directly teach how to do things with the
proper tools.

The reason is that you do not want to overwhelm the student with loads
of glue code if the subject of tutorial isn’t
"Using external libraries with tons of dependencies and completely unrelated
procedural techniques to do trivial things this tutorial isn’t about".
(also, ‘S’ in SDL stands for ‘simple’).On Tue, Dec 18, 2012 at 12:12 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

–

./lxnt

30

TL;DR: A non-library dependency inducing static SDL_LoadPNG would be
great, but lets keep SDL_LoadBMP anyway.

My own take if it’s worth anything is that the BMP loader/saver should
remain as is. The costs for keeping it are pretty minimal really; the
only tangible benefit in removing it is that it makes the API slightly
cleaner.

As for a PNG loader built into SDL, that’s definitely a Good Thing. The
PNG format occupies the same niche as BMP in that it’s a lossless and
relatively simple format that supports alpha channels and indexing etc.
whilst also being compressed and (arguably) better supported in image
editors.

“Just use SDL_image” is not a good alternative as it entails potentially
many other library dependencies. This isn’t such a big deal on the
desktop but in the mobile space it’s a massive pain in the ass.On 18/12/12 08:26, Vittorio Giovara wrote:

How about moving the SaveBMP function in SDL_image and add the SavePNG
API in SDL_image too?
SavevBMP is old but it could be useful under certain scenarios; maybe
its place in the main library it’s a little off…
Vittorio

31

2012/12/18 Alexander Sabourenkov :

That goes contrary to the goal of a tutorial - show how to do things,
preferably one single thing per tutorial, and do this as simple as
possible.

Depends. If you’re teaching how to load an image or a sound, you’re
probably better off teaching how to get up SDL_Image or SDL_Mixer
running, given they’re what you should be using for the job really. If
you’re teaching how to show something on screen or something like
that, you’re already teaching two things at the same time (since
you’re also teaching how to load something).

I see no reason why we should let anybody be taught how to do things
the dirty way when we could directly teach how to do things with the
proper tools.

While we’re on the subject, I see no reason to have an SDL_Image in
the first place.? Pretty much anyone who is going to use SDL is going
to want to import image resources from a modern image format.? So
why is that in a satellite library instead of core SDL?? Especially
considering how certain popular mobile platforms don’t like external
libraries, making your task harder for each new external library you
want to use.? Why not just incorporate SDL_Image into SDL core,
and save everyone the hassle?>From: Sik the hedgehog <sik.the.hedgehog at gmail.com>

Subject: Re: [SDL] pnglite wrapper

32

Alexander, this gets into pedagogy perhaps too much. SDL should do what it
does well and simply. A dependency on SDL_image (or a lighter alternative
that just has PNG support, like SDL_pnglite) should not be a problem at all
for a real application. If students can’t handle linking to more than one
library, then maybe they’re being taught things in the wrong order? Teach
them programming, then teach them graphics and multimedia.

Jonny DOn Tue, Dec 18, 2012 at 4:46 AM, Tim Angus wrote:

On 18/12/12 08:26, Vittorio Giovara wrote:

How about moving the SaveBMP function in SDL_image and add the SavePNG
API in SDL_image too?
SavevBMP is old but it could be useful under certain scenarios; maybe
its place in the main library it’s a little off…
Vittorio

TL;DR: A non-library dependency inducing static SDL_LoadPNG would be
great, but lets keep SDL_LoadBMP anyway.

My own take if it’s worth anything is that the BMP loader/saver should
remain as is. The costs for keeping it are pretty minimal really; the only
tangible benefit in removing it is that it makes the API slightly cleaner.

As for a PNG loader built into SDL, that’s definitely a Good Thing. The
PNG format occupies the same niche as BMP in that it’s a lossless and
relatively simple format that supports alpha channels and indexing etc.
whilst also being compressed and (arguably) better supported in image
editors.

“Just use SDL_image” is not a good alternative as it entails potentially
many other library dependencies. This isn’t such a big deal on the desktop
but in the mobile space it’s a massive pain in the ass.

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

33

Because SDL seems to behave more as a portable “wrapper” (sorta) for
the OS APIs than anything else. You’re still expected to handle
everything besides getting access to the resources.

And yeah, while it’d be nice to have that, I can see why it’s split
like this. The rendering functions seem to be the odd one out of this,
and they’re a new addition in 2.0 really (you were expected to handle
the rendering in 1.2 on your own - I think there was some blit
function and nothing else, even something like drawing a single pixel
needed to be done by hand).

2012/12/18 Mason Wheeler :>>From: Sik the hedgehog <@Sik_the_hedgehog>

Subject: Re: [SDL] pnglite wrapper

2012/12/18 Alexander Sabourenkov :

That goes contrary to the goal of a tutorial - show how to do things,
preferably one single thing per tutorial, and do this as simple as
possible.

Depends. If you’re teaching how to load an image or a sound, you’re
probably better off teaching how to get up SDL_Image or SDL_Mixer
running, given they’re what you should be using for the job really. If
you’re teaching how to show something on screen or something like
that, you’re already teaching two things at the same time (since
you’re also teaching how to load something).

I see no reason why we should let anybody be taught how to do things
the dirty way when we could directly teach how to do things with the
proper tools.

While we’re on the subject, I see no reason to have an SDL_Image in
the first place. Pretty much anyone who is going to use SDL is going
to want to import image resources from a modern image format. So
why is that in a satellite library instead of core SDL? Especially
considering how certain popular mobile platforms don’t like external
libraries, making your task harder for each new external library you
want to use. Why not just incorporate SDL_Image into SDL core,
and save everyone the hassle?

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

34

While we’re on the subject, I see no reason to have an SDL_Image in the first
place.

SDL_Image was useful back when image formats didn’t have a semi-official, freely
available, portable maintained library. Back then, you copied code to load targa
or bmp files out of books and it seemed to work. These days, anyone who wants to
load png or jpeg can use the official library directly.

Pretty much anyone who is going to use SDL is going to want to import image
resources from a modern image format.

Many games pre-process, batch, or “wad” images into a simpler, custom format at
compile-time.

35

2012/12/18 John :

SDL_Image was useful back when image formats didn’t have a semi-official,
freely available, portable maintained library. Back then, you copied code to
load targa or bmp files out of books and it seemed to work. These days,
anyone who wants to load png or jpeg can use the official library directly.

libpng and jpeglib are not that trivial to use, though. Yes, they
aren’t exactly hard, but loading an image still requires calling
several functions and using a callback for reading from a stream.
Compare this to having a premade function that takes care of all this
for you, and you can see how such libraries can still be helpful.

Many games pre-process, batch, or “wad” images into a simpler, custom format
at compile-time.

Many just use standard formats as-is, though (generally PNG or JPEG).

36

Mm.

I can see the attraction of having a couple of generic resource loaders
built into SDL, but honestly, I don’t think it’s a great idea.

It’ll just be a management nightmare. You either load SDL up with external
dependencies on libpng, etc. (this is a terrible idea!) or drop a minimal
baseline import/export script into SDL, which is rubbish and doesn’t
actually support the format, and get people complaining that it doesn’t
work.

Honestly, if you want easy, trivial baseline image support, just drop
http://nothings.org/stb_image.c into your project. BAM! Done.

If you want tests that load images, drop stb_image.c (or pnglite, or
whatever) into your test. It’s really easy stuff.

If we had a large foundation trying to turn SDL into Unity with its own
native level editor and a asset pipeline, then maybe there’d be a place for
resource loaders in SDL; but we don’t. We have a few people working on
keeping it up to date, and community contributions. Small baseline
functionality that is easy to port to new platforms = win.~
Doug.

On Wed, Dec 19, 2012 at 4:33 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

2012/12/18 John :

SDL_Image was useful back when image formats didn’t have a semi-official,
freely available, portable maintained library. Back then, you copied
code to
load targa or bmp files out of books and it seemed to work. These days,
anyone who wants to load png or jpeg can use the official library
directly.

libpng and jpeglib are not that trivial to use, though. Yes, they
aren’t exactly hard, but loading an image still requires calling
several functions and using a callback for reading from a stream.
Compare this to having a premade function that takes care of all this
for you, and you can see how such libraries can still be helpful.

Many games pre-process, batch, or “wad” images into a simpler, custom
format
at compile-time.

Many just use standard formats as-is, though (generally PNG or JPEG).

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

37

Message-ID:
<CABZtw9OcvE9CxPq7yEm670P=MgqO7PYmO-Fdnhn52gCZWWLPcA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

And procedural generation is only going to confuse the hell out of
people. Even ones writing those same tutorials.

Technically speaking, I slightly disagree with this. I think that
teaching people the correct way to access pixels (particularly how to
use it to e.g. create an “image” of a single color) in an SDL_Surface
should actually be the tutorial immediately before using images.
Anything more, though, certainly would be overkill.> Date: Tue, 18 Dec 2012 10:59:08 +0300

From: Alexander Sabourenkov
To: SDL Development List
Subject: Re: [SDL] pnglite wrapper

Date: Tue, 18 Dec 2012 05:12:06 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] pnglite wrapper
Message-ID:
<CAEyBR+WgiJTr3hhJ9EZ8LMCPyijMS_j12TGwV4KrL_egT9xtWQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

And procedural generation is only going to confuse the hell out of
people. Even ones writing those same tutorials.

Not necessarily, even simple formulas can be useful. Heck, the XOR
texture became famous because of how trivial it is (literally x xor y)
despite looking a lot better than most programmer art.

Procedural texture generation has it’s place, but with the exception
of the simplest cases, that place is after conventional textures
instead of before it.

Date: Tue, 18 Dec 2012 05:40:41 -0800 (PST)
From: Mason Wheeler
To: SDL Development List
Subject: Re: [SDL] pnglite wrapper
Message-ID:
<1355838041.71667.YahooMailNeo at web122505.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=“iso-8859-1”

While we’re on the subject, I see no reason to have an SDL_Image in
the first place.? Pretty much anyone who is going to use SDL is going
to want to import image resources from a modern image format.? So
why is that in a satellite library instead of core SDL?? Especially
considering how certain popular mobile platforms don’t like external
libraries, making your task harder for each new external library you
want to use.? Why not just incorporate SDL_Image into SDL core,
and save everyone the hassle?

Because you haven’t convinced Sam. For what it’s worth, I think it’s a
bad idea. I’d like to see a binary bundle released eventually, and I
think that the satellite libraries need to get prominent billing on
the site’s main page, but shoehorning it into the code of SDL itself
will just make it harder to compile a standard version of SDL.

38

Teaching people wrong should not be considered teaching. Having some
functions in the library just to demonstrate it’s glorious simplicity is
cheating. And technically incorrect.On 18.12.2012 8:59, Alexander Sabourenkov wrote:

On Mon, Dec 17, 2012 at 2:00 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

And yeah, if it was me, I’d rather just get rid of the LoadBMP
altogether (along with SaveBMP, LoadWAV and SaveWAV). In tutorials
loading bitmaps could be a good time to teach newcomers to use the
satellite libraries while for tests we could probably just generate
some quick assets procedurally to do the job.

That goes contrary to the goal of a tutorial - show how to do things,
preferably one single thing per tutorial, and do this as simple as
possible.

–

KM

39

For one, I’m against making the core larger than it already is. I would
like to see SDL focus on its strength, the OS API layer. Haven’t most of us
already written our own format wrappers? Shouldn’t this be left as an
exercise for the newcomer? If you say we could just make an "SDL lite"
build available, would anything have changed from the SDL + SDL_image
system? Let’s have people attach their own image library of choice.

40

Here are my thoughts on things:

  • LoadBMP is not essential in SDL, but it IS a proof of concept of how
    to build your own image loading
  • SDL_image should continue to be separate from SDL, because it only
    acts as an ease-of-use wrapper for some popular image formats.
  • Most serious apps tend to package their own image and asset
    loading/handing system, thus SDL_image acts as a “quick and dirty” lib
    until you have the time to devote to your own loading systems.

I don’t mean to smash SDL_image in any way, though, because I use it all
the time for some smaller apps and tests all the time.

With that in mind, pnglite should remain it’s own satellite library,
because a good concept (something Mr. Dearborn brought up) is that SDL
should do the minimal work in the background and do it well, and leave
other jobs to satellite libraries and the programmer.

It would be fairly simple to add some compile switches into SDL_image so
you specify either libpng or pnglite support.On Wed, Dec 19, 2012 at 1:46 PM, Chris Bush wrote:

For one, I’m against making the core larger than it already is. I would
like to see SDL focus on its strength, the OS API layer. Haven’t most of us
already written our own format wrappers? Shouldn’t this be left as an
exercise for the newcomer? If you say we could just make an "SDL lite"
build available, would anything have changed from the SDL + SDL_image
system? Let’s have people attach their own image library of choice.

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