Image load/save

[Joseph_Carter]

SDL currently isn’t too friendly when it comes to images with alpha.
First, there’s no intrinsic support for images with alpha, loading or
saving. SDL does support Windows BMP files, though, and I see three good
reasons why it should:

1. One of the early stated goals of SDL was to make it easy to port Win32
   games to Linux. This goal has been reached, IMO.

2. Small apps such as demos, tutorial programs, John’s book, etc, need a
   good but simple way to get image data loaded without fuss so they can
   focus on what’s important.

3. Code bloat. The less stuff your program needs, the less that can go
   wrong with any of that stuff. If you don’t really need to be able to
   load lots of image formats, you’re best supporting one or two and
   saving much headache later on.

The problem with BMP is that while it meets the first point better than
any other format could, the second and third points are only met if the
images loaded need no alpha channel. I’ve been told that it is possible
for BMP to support alpha, but nothing does. So SDL (1.3 most likely?)
should also support a format which does handle alpha.

The best format for this is Targa. As most of you probably know from
other rants I make … every couple months or so … I’m an OpenGL guy.
While alpha channels are not used very much outside of OpenGL programs,
they are just about standard issue in OpenGL. And the standard issue
format for images with alpha channels is Targa - not because it’s a nice
high-compression format. Not at all - it’s used because it’s dead simple
to parse when compared with the alternatives!

The problem with Targa is that the loader is not exactly short if it’s any
good. Targa supports storing the image basically any direction you want.
Top to bottom, bottom to top, right to left, all of the above with or
without RLE, and it happens to support paletted images with palettes
bigger than 256 colors.

Most loaders don’t even support RLE. Targa colormap (palette) support is
even more rare. And all too many loaders only support the image left to
right and bottom to top. Basically, even though the format is as simple
as it gets, the parsers are generally not up to spec. The closest one I
didn’t write seems to be the one in SDL_image. But SDL_image is generally
a big dependency to add to a small project, and doesn’t fit well into
things like demos and tutorial programs. Plus SDL_image doesn’t write any
format it can load. (In some cases, this is a good thing. XCF anyone?)

Anyway, it seems like a good idea to me for 1.3 at least. If combined
with some changes to SDL_DisplayFormat, it could result in SDL_Surface
being a reasonable format even for larger OpenGL programs to use. ;)–
Joseph Carter You expected a coherent reply?

There is no snooze button on a cat who wants breakfast.

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020426/c5f3053a/attachment.pgp

[Andrew_Murie]

The problem with BMP is that while it meets the first point better than
any other format could, the second and third points are only met if the
images loaded need no alpha channel. I’ve been told that it is possible
for BMP to support alpha, but nothing does. So SDL (1.3 most likely?)
should also support a format which does handle alpha.

The SDL_image library already handles BMP, JPG, PNG, I think GIF, and
probably could be extended to handle any other format you needed. (PNG has
decent support for alpha, although too many programs seem to ignore it.)
This already works fine, so I’m not sure why 1.3 will need extra image file
handling.

If the SDL_Surface structure needs any additional support, ideally that
should be independant of the image loading code.

[slouken]

The problem with BMP is that while it meets the first point better than
any other format could, the second and third points are only met if the
images loaded need no alpha channel. I’ve been told that it is possible
for BMP to support alpha, but nothing does. So SDL (1.3 most likely?)
should also support a format which does handle alpha.

I agree. Mattias has written targa saving code which will probably join
the BMP code in SDL 1.3

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

[Joseph_Carter]

Cool, when do you plan on forking off a 1.3 branch? ;)On Sat, Apr 27, 2002 at 12:00:29AM -0700, Sam Lantinga wrote:

The problem with BMP is that while it meets the first point better than
any other format could, the second and third points are only met if the
images loaded need no alpha channel. I’ve been told that it is possible
for BMP to support alpha, but nothing does. So SDL (1.3 most likely?)
should also support a format which does handle alpha.

I agree. Mattias has written targa saving code which will probably join
the BMP code in SDL 1.3

–
Joseph Carter My opinions are always right

uh oh, what have I started
rofl… distro nick wars.

• Slackware just waits for /nick Gnome, /nick KDE, and then world war 4
  to break out
  :oP
  
  
  no’one would dare /nick RedHat
  mew.

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020427/daa0f7d5/attachment.pgp

[Joseph_Carter]

But SDL_image is a seperate library. As I said, the additional
dependencies on three new libraries (or more as people extend SDL_image
further) is a lot to ask for when you just need a way to load an image in
some format with an alpha channel.

I have a perfectly valid Targa loader and saver. I use them for such
instances. They depend on nothing and add a whole two files to a project.
They have the side-effect of being basically the most complete Targa
implementation I’ve seen, with the possible exception of the one in
SDL_image. I can understand IMG_Load being able to load a Targa since it
can also load a BMP (by using the SDL functions IIRC), but I do believe
the functions should be in SDL.On Sat, Apr 27, 2002 at 07:49:01PM +1200, Andrew Murie wrote:

The SDL_image library already handles BMP, JPG, PNG, I think GIF, and
probably could be extended to handle any other format you needed. (PNG has
decent support for alpha, although too many programs seem to ignore it.)
This already works fine, so I’m not sure why 1.3 will need extra image file
handling.

If the SDL_Surface structure needs any additional support, ideally that
should be independant of the image loading code.

–
Joseph Carter My opinions are always right

Gates’ Law: Every 18 months, the speed of software halves.

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020427/56210486/attachment.pgp

[Kent_Quirk]

On Sat, 27 Apr 2002 11:39:33 -0700, Joseph Carter scribbled:>On Sat, Apr 27, 2002 at 07:49:01PM +1200, Andrew Murie wrote:

The SDL_image library already handles BMP, JPG, PNG, I think GIF,
and probably could be extended to handle any other format you
needed.
(PNG has decent support for alpha, although too many programs seem
to ignore it.)
This already works fine, so I’m not sure why 1.3 will need extra
image file handling.

If the SDL_Surface structure needs any additional support, ideally
that should be independant of the image loading code.

But SDL_image is a seperate library. As I said, the additional
dependencies on three new libraries (or more as people extend
SDL_image further) is a lot to ask for when you just need a way to
load an image in some format with an alpha channel.

I have a perfectly valid Targa loader and saver. I use them for
such instances. They depend on nothing and add a whole two files to
a project.
They have the side-effect of being basically the most complete Targa
implementation I’ve seen, with the possible exception of the one in
SDL_image. I can understand IMG_Load being able to load a Targa
since it can also load a BMP (by using the SDL functions IIRC), but
I do believe the functions should be in SDL.

I agree with this. I ended up slightly hacking (yes, we’ll make the
changed sources available when we release) the SDL_image library so
it only knows about TGA (because cheap and common), BMP, and PNG
files, so that I didn’t have to carry around a few hundred K worth of
the JPG and GIF code, plus a bunch of other formats I didn’t care
about. It also let me eliminate jpeg.dll.

All I needed was alpha. I like PNG, but I’d have been happy with TGA
– even a less-than-complete implementation of TGA (for example, I’ve
never seen a right-to-left TGA file, though I’ve seen them upside
down frequently).

Kent

–
Kent Quirk, CTO, CogniToy
@Kent_Quirk
http://www.cognitoy.com

[Andy_Preston]

I haven’t looked at SDL_image, but could each format have a disable flag for
configure, or maybe a global #define for each format to enable/disable. I
implemented a similar thing once (albiet a Windows COM library) but I had a
manager that dealt with the images/files and each format could be added
independantly of anything else, the manager just dealt with what it knre
about.

AndyOn Saturday 27 April 2002 16:24, Kent Quirk wrote:

I agree with this. I ended up slightly hacking (yes, we’ll make the
changed sources available when we release) the SDL_image library so
it only knows about TGA (because cheap and common), BMP, and PNG
files, so that I didn’t have to carry around a few hundred K worth of
the JPG and GIF code, plus a bunch of other formats I didn’t care
about. It also let me eliminate jpeg.dll.

[Joseph_Carter]

They have the side-effect of being basically the most complete Targa
implementation I’ve seen, with the possible exception of the one in
SDL_image. I can understand IMG_Load being able to load a Targa
since it can also load a BMP (by using the SDL functions IIRC), but
I do believe the functions should be in SDL.

I must recant the above because I took a closer look at SDL_image’s
loader. There’s a lot it doesn’t know how to handle. =(

I agree with this. I ended up slightly hacking (yes, we’ll make the
changed sources available when we release) the SDL_image library so
it only knows about TGA (because cheap and common), BMP, and PNG
files, so that I didn’t have to carry around a few hundred K worth of
the JPG and GIF code, plus a bunch of other formats I didn’t care
about. It also let me eliminate jpeg.dll.

Debian’s SDL_image links only libpng, libjpeg, and zlib. That still adds
up to some 300k+ of cruft. Granted it can be stripped down to less (this
requires very little source modding, really… Just #undef a few lines and
it will do what you want) but it’s still an extra library.

All I needed was alpha. I like PNG, but I’d have been happy with TGA
– even a less-than-complete implementation of TGA (for example, I’ve
never seen a right-to-left TGA file, though I’ve seen them upside
down frequently).

libpng is a bear to get compiling with -Werror in gcc and let’s not even
disucss the steaming pile of unreadable crap that calls itself zlib. Ever
notice that nobody seems to think zlib is clean code, but nobody is
willing to rewrite it cleaner? Err, ahem, that’s another rant, sorry.

Anyway, Targa loaders… I’m writing code for loading and saving Targas
which will support all of the required parts of the Targa spec, and some
of the optional enhancements provided by Targa 2.0, a spec which is more than a
decade old.

0, and some of the
optional stuff, mostly because I can’t find my old implementation and even
it was incomplete. The things which most Targa loader

• Reading the footer
  Every Targa written after 1989 should probably have one. Some don’t,
  and it almost doesn’t matter if it did since many loaders don’t even
  look for it. Better image tools put one there though, and it points to
  some useful data, as well as containing the closest thing Targa has to
  a file signature. My Targa save will always put a footer and an
  extension area on the image, always. =p

• Image orientation (required)
  Too many Targa loaders can’t read a top-to-bottom Targa. Very few can
  read right-to-left (probably because it’s just WEIRD maybe?) Weird or
  not, all orientations are expected to work.

• Color keys (optional)
  SDL uses them, but SDL_image doesn’t even look for one. Instead it
  tries to fake it using the alpha channel. It’s part of the extension
  area which is indexed by the footer.

• Gamma value and color correction (optional)
  This is a little tricky since SDL_image doesn’t support these and they
  greatly change how the image looks after it loads. Most Targas don’t
  have it. If one does, I can apply that to the pixels after load. Not
  an optimized case unless the image has a colormap. =p

• Colormap support (required)
  Most loaders can’t read a colormapped image. SDL_image can, if the
  colormap is 256 entries. Targa supports less and more than 256 entries
  in the colormap. SDL_image ignores the colormap index, but supporting
  it is trivial.

• RLE
  The only kind of compression Targa supports. Most people don’t save
  their Targas in RLE format if they expect games to be able to load them
  since most can’t. SDL_image can. Even Quake did.

There are other things which are optional… I don’t intend to support
them since they are not important to the task of displaying a single
image. Scanline offset lists, thumbnails, developer data, etc… It might
or might not be there, but I will simply gloss over it since these things
have no bearing on drawing the image.

There is exactly one thing I don’t plan to support which CAN affect
display of the image - interleave. For those who have the Targa 2.0 spec,
I refer to field 5.6, bits 6 and 7. They’re marked reserved and you’re
expected to make them both 0 in anything you write. If they’re not 0, the
image will fail to load. They are used for two- and four-way interleave
by … something. Nothing I can find uses it or even supports it. Fact
is, it’s not in the spec, so there’s no reference spec. I could figure it
out if I can find even one Targa in that format, but I haven’t done so.
Since I don’t, I’m not going to try to load it, and there’s no way I’d
support saving it.

As you can see, there’s a fair bit of insanity, a bit more than BMP even.
But still less with all of that than say … PNG. Or JPEG. My code will
not, in its first incarnation, support loading SDL_Surface’s. I want to
put up a freely usable (ie, public domain) copy optimized for OpenGL first
(ie, colormapped images will always expand to BGR(A)), and then modify the
code for SDL_Surfaces afterward (ie, saving the color key, keeping the
image paletted if the palette is small enough, etc…)

The save code won’t do anything cute. I might do RLE support, but no
promises. Targas may work for screenshots, but RLE is inadiquate
compression anyway. Want a smaller screenshot? Convert it to JPEG.

I may at some point write a JPEG saver since I need one for my own code,
but a JPEG loader is getting into the big library thing again. Saving one
type is easy. Loading all types … is not.On Sat, Apr 27, 2002 at 07:24:35PM -0400, Kent Quirk wrote:

–
Joseph Carter Here we go again

C’mon! political protest! sheesh. Where’s that anarchist spirit?
– Decklin Foster

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020427/e0c19a71/attachment.pgp

[Torsten_Giebl]

Please keep SDL 1.3 also as small as possible. Don?t do the ALLEGRO thing.
Okay a BMP and TGA Loader is enough, don?t put in BMP or TGA Save Functions.
Why i love SDL and why i switched from ALLEGRO to SDL, because SDL is a lot
smaller.

[Grzegorz_Jaskiewicz]

Please keep SDL 1.3 also as small as possible. Don?t do the ALLEGRO thing.
Okay a BMP and TGA Loader is enough, don?t put in BMP or TGA Save
Functions.
Why i love SDL and why i switched from ALLEGRO to SDL, because SDL is a
lot
smaller.
IMO it should be FASTER ! tons of macros and clases, isn’t a good idea. It
slows down whole liblary about 30-40%. I have done testes, it’s really slow.
The only good thing is interface, it’s very good. But i miss OpenGL aid. I
cannot use surface as a texture, this should be done. Also rendering to
surface, surface copy, surface blt with scale !(it’s in DX). and many other
things, but first SPEED gentelman.!! It can even be big, who cares. It will
never reach size of DX or even DirectDraw.

Grzegorz Jaskiewicz

[James1]

| Please keep SDL 1.3 also as small as possible. Don?t do the ALLEGRO thing.
| Okay a BMP and TGA Loader is enough, don?t put in BMP or TGA Save Functions.
| Why i love SDL and why i switched from ALLEGRO to SDL, because SDL is a lot
| smaller.

I always wondered why SDL has builtin functions for reading BMPs, but
it doesn’t have support for any other format unless you use SDL_image.On Sun, Apr 28, 2002 at 11:34:56AM +0200, Torsten Giebl wrote:

–
Coffee is not for kids

6AD6 865A BF6E 76BB 1FC2 | www.piku.org.uk/public-key.asc
E4C4 DEEA 7D08 D511 E149 | www.piku.org.uk wnzrf at cvxh.bet.hx (rot13’d)

[Kovacs]

I always wondered why SDL has builtin functions for reading BMPs, but
it doesn’t have support for any other format unless you use SDL_image.

Well, because it is very nice to have bitmap loading if you want to test
something quickly. You don’t have to get appropriate SDL_Image version
(possibly compile it) and only then be able to load some images for testing.

Kovacs> --

Coffee is not for kids

6AD6 865A BF6E 76BB 1FC2 | www.piku.org.uk/public-key.asc
E4C4 DEEA 7D08 D511 E149 | www.piku.org.uk wnzrf at cvxh.bet.hx (rot13’d)

---

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

[Joseph_Carter]

BMP save is already there. Simplest Targa save is this, from memory:

SDL_bool
Targa_Save (const char *name, image_t *img)
{
FILE *f;
Uint8 header[];
Uint8 footer[26];
int i;
Uint8 *pbuf;

f = fopen (name, "w");
if (!f)
    return SDL_FALSE;

// Fill in the header
memset (header, 0, sizeof (header));
header[2] = 2;                      // (byte) BGR/BGRA, no RLE
header[10] = img->width & 255;      // (short) Y origin
header[11] = img->width >> 8;
header[12] = img->width & 255;      // (short) image width
header[13] = img->width >> 8;
header[14] = img->height & 255;     // (short) image height
header[15] = img->height >> 8;
if (img->type & IMG_RGBA)
{
    header[16] = 32;                // (byte) bits per pixel
    header[17] = 24;		// (byte) origin and alpha
}
else
{
    header[16] = 24;                // (byte) bits per pixel
    header.imgdesc = 16;            // (byte) origin, no alpha
}
fwrite (header, sizeof (header), 1, f);

// Fill in the pixel data - pixels are BGR(A), not RGB(A)!  Since we
// set the correct origin above, we can write top to bottom.
if (img->type & IMG_RGBA)
{
    pbuf = malloc (4 * img->width * img->height);
    for (i = 0; i < img->width * img->height; i++)
    {
        *pbuf++ = img->colors[i].b;
        *pbuf++ = img->colors[i].g;
        *pbuf++ = img->colors[i].r;
        *pbuf++ = img->colors[i].a;
    }
    fwrite (pbuf, img->width * img->height * 4, 1 , f);
    free (pbuf);
}
else
{
    pbuf = malloc (3 * img->width * img->height);
    for (i = 0; i < img->width * img->height; i++)
    {
        *pbuf++ = img->colors[i].b;
        *pbuf++ = img->colors[i].g;
        *pbuf++ = img->colors[i].r;
    }
    fwrite (pbuf, img->width * img->height * 3, 1 , f);
    free (pbuf);
}

// And now the footer, which is trivial - and besides, every Targa
// since 1989 _should_ have one.  Most people can't seem to be
// bothered to write it in screenshot functions, though.
memset (footer, 0, sizeof (footer));
strcpy (&footer[8], "TRUEVISION-XFILE.");
fwrite (footer, sizeof (footer), 1, f);

fclose (f);
return SDL_TRUE;

}

The one in SDL should actually write bottom to top for compatibility with
all of the stupid Targa loaders which ignore field 5.6, which is about
half of them used in games, including the one used by Id Software.

The above uses my memory format (which is OpenGL friendly), but making it
work with SDL_Surface’s is easy. Colormaps are easy too since SDL only
has one kind of paletted image. The loaders are what’s big, the savers
are pretty simple.On Sun, Apr 28, 2002 at 11:34:56AM +0200, Torsten Giebl wrote:

Please keep SDL 1.3 also as small as possible. Don?t do the ALLEGRO thing.
Okay a BMP and TGA Loader is enough, don?t put in BMP or TGA Save Functions.
Why i love SDL and why i switched from ALLEGRO to SDL, because SDL is a lot
smaller.

–
Joseph Carter Sanity is counterproductive

The Unixverse ends on Tue, 19 Jan 2038 03:14:07 +0000

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020428/ae056612/attachment.pgp

[Joseph_Carter]

Loading a Targa into SDL_Surface’s won’t make it easier to use them in
OpenGL. The hack in test/testgl.c is as good as it gets until
SDL_DisplayFormat is made to do something sane with textures loaded for
OpenGL. The patch to SDL for that is simple - SDL_DisplayFormat and
SDL_DisplayFormatAlpha just need to use a sane pixel format if
(DSL_PublicSurface->flags & SDL_OPENGL)… Probably RGB8 and RGBA8 are
best, unless I can come up with a portable method to query the internal
format of the framebuffer. The internal format of a texture is easy, but
the framebuffer is not a texture in OpenGL 1.x…

The real question is whether or not this consitutes a bugfix or a new
feature. The feature supposedly exists now, it’s just not useful for
OpenGL at the moment. But anyone who wanted to use it would have to check
if their SDL is v1.2.5 or greater. This arguably is no different than
checking the SDL version to apply a bug workaround if need be, but still
it is my understanding that Sam would prefer people not have to do this.

Sam, if you get unbusy, feel free to comment on any of this. ;)On Sun, Apr 28, 2002 at 12:17:15PM +0200, Grzegorz Jaskiewicz wrote:

IMO it should be FASTER ! tons of macros and clases, isn’t a good idea. It
slows down whole liblary about 30-40%. I have done testes, it’s really slow.
The only good thing is interface, it’s very good. But i miss OpenGL aid. I
cannot use surface as a texture, this should be done. Also rendering to
surface, surface copy, surface blt with scale !(it’s in DX). and many other
things, but first SPEED gentelman.!! It can even be big, who cares. It will
never reach size of DX or even DirectDraw.

–
Joseph Carter My opinions are always right

<doogie_> linux takes shit and turns it into something useful.
<doogie_> windows takes something useful and turns it into shit

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020428/1cd199fd/attachment.pgp

[Joseph_Carter]

Win32 games often use BMP because they don’t need a loader for it. Since
one of the early goals of SDL was to be able to port those things to Linux
easily, it was necessary to support loading the file format which these
games all expected to Just Work™…

Nowadays it serves as a quick file format to use in SDL when you don’t
want to mess with the heavier-weight image libraries. The whole
discussion pertaining to Targa is happening because BMP works great if you
don’t need an alpha channel. ;)On Sun, Apr 28, 2002 at 11:24:59AM +0100, James wrote:

| Please keep SDL 1.3 also as small as possible. Don?t do the ALLEGRO thing.
| Okay a BMP and TGA Loader is enough, don?t put in BMP or TGA Save Functions.
| Why i love SDL and why i switched from ALLEGRO to SDL, because SDL is a lot
| smaller.

I always wondered why SDL has builtin functions for reading BMPs, but
it doesn’t have support for any other format unless you use SDL_image.

–
Joseph Carter glDisable (DX8_CRAP);

DalNet is like the special olympics of IRC. There’s a lot of
drooling goin’ on and everyone is a ‘winner’.

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020428/399e4d9b/attachment.pgp

[slouken]

The real question is whether or not this consitutes a bugfix or a new
feature. The feature supposedly exists now, it’s just not useful for
OpenGL at the moment.

Sam, if you get unbusy, feel free to comment on any of this.

I just got back from a belly dance show, and I’m about to go out again,
but I have a minute here…

I would consider this a bugfix, since DisplayFormat() doesn’t do anything
meaningful for OpenGL modes right now, so feel free to submit a patch.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

[Torsten_Giebl]

I agree. Mattias has written targa saving code which will probably join
the BMP code in SDL 1.3

I agree, too. BMP and TGA loading functions in the new SDL 1.3 but not more
formats in the standard library.

CU

[Joseph_Carter]

Sam, if you get unbusy, feel free to comment on any of this.

I just got back from a belly dance show, and I’m about to go out again,
but I have a minute here…

w00t =)

I would consider this a bugfix, since DisplayFormat() doesn’t do anything
meaningful for OpenGL modes right now, so feel free to submit a patch.

I’ll be happy to submit one as soon as I get a reply to a query I have
submitted to people who eat, sleep, and breathe OpenGL. I think I’m going
to find that what I really want to do with it will require OpenGL 2.0,
but I can at least do something sane in the meantime.

Is there a preferred method for assembling a PixelFormat inside the code,
or is pretty much anything that works (ie, filling one in by hand) a good
enough method?On Sun, Apr 28, 2002 at 07:59:31PM -0700, Sam Lantinga wrote:

–
Joseph Carter Intelligent backside at large

<Anarchy> acf: maybe April 1 next year slashdot needs to run “Rob Malda
accepts new job as head of Debian project” 8)

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020429/e64ffdcb/attachment.pgp

[slouken]

Is there a preferred method for assembling a PixelFormat inside the code,
or is pretty much anything that works (ie, filling one in by hand) a good
enough method?

You can use the functions in src/video/SDL_pixels_c.h

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

[Joseph_Carter]

Got it, thanks. This patch should be all you need provided that contexts
created with the SDL_OPENGLBLIT flag also get the SDL_OPENGL flag (which
IIRC they do…)

I decided to keep this as simple as possible so that you can upload the
pixel data to OpenGL blindly after calling SDL_DisplayFormat{,Alpha} on
the source. Just feed the thing to glBindTexture/glTexImage2D with GL_RGB
or GL_RGBA respectively and it’ll do the right thing.

Or at least, it will as far back as OpenGL 1.1 - it’s an exercise for the
reader to support OpenGL 1.0 if they actually care about it. But IMO,
since even Microsoft has managed to upgrade OpenGL libraries since 1.0,
they should too. I mean it’s not too much to ask for people to upgrade
their libraries at least once a decade or so, is it? ;)On Mon, Apr 29, 2002 at 05:40:26PM -0700, Sam Lantinga wrote:

Is there a preferred method for assembling a PixelFormat inside the code,
or is pretty much anything that works (ie, filling one in by hand) a good
enough method?

You can use the functions in src/video/SDL_pixels_c.h

–
Joseph Carter The guy with a rocket launcher

CosmicRay: you complete me
err…
heh

• BenC goes back to coding
• elmo looks at benc
  something we should know about you and cosmicray, Ben?

-------------- next part --------------
Index: src/video/SDL_video.c

RCS file: /home/slouken/libsdl.org/cvs/SDL12/src/video/SDL_video.c,v
retrieving revision 1.23
diff -u -r1.23 SDL_video.c
— src/video/SDL_video.c 2002/03/20 02:37:44 1.23
+++ src/video/SDL_video.c 2002/04/30 11:52:45
@@ -843,6 +843,21 @@
SDL_SetError(“No video mode has been set”);
return(NULL);
}
+

• /* If PublicSurface is an OpenGL context, treat it specially */
• if ((SDL_PublicSurface->flags&SDL_OPENGL) == SDL_OPENGL)
• {

•   SDL_PixelFormat *format;
  

•   SDL_Surface *converted;
  

•   /* Use a format perfect for GL_RGB texture uploads */
  

•   format = SDL_AllocFormat(24, 0xFF000000, 0x00FF0000, 0x0000FF00);
  

•   converted = SDL_ConvertSurface(surface, format, SDL_SWSURFACE);
  

•   SDL_FreeFormat(format);
  

•   return(converted);
  

• }
• /* Set the flags appropriate for copying to display surface */
  if (((SDL_PublicSurface->flags&SDL_HWSURFACE) == SDL_HWSURFACE) && current_video->info.blit_hw)
  flags = SDL_HWSURFACE;
  @@ -877,38 +892,53 @@
  SDL_SetError(“No video mode has been set”);
  return(NULL);
  }

• vf = SDL_PublicSurface->format;

• switch(vf->BytesPerPixel) {

•   case 2:
  

•   /* For XGY5[56]5, use, AXGY8888, where {X, Y} = {R, B}.
  

•      For anything else (like ARGB4444) it doesn't matter
  

•      since we have no special code for it anyway */
  

•   if ( (vf->Rmask == 0x1f) &&
  

•        (vf->Bmask == 0xf800 || vf->Bmask == 0x7c00)) {
  

•   	rmask = 0xff;
  

•   	bmask = 0xff0000;
  

•   }
  

•   break;
  

• /* OpenGL needs special treatment */
• if ((SDL_PublicSurface->flags&SDL_OPENGL) != SDL_OPENGL)
• {

•   /* Set the format for 32 bit GL_RGBA texture uploads */
  

•   rmask = 0xff000000;
  

•   gmask = 0x00ff0000;
  

•   bmask = 0x0000ff00;
  

•   amask = 0x000000ff;
  

•   case 3:
  

•   case 4:
  

•   /* Keep the video format, as long as the high 8 bits are
  

•      unused or alpha */
  

•   if ( (vf->Rmask == 0xff) && (vf->Bmask == 0xff0000) ) {
  

•   	rmask = 0xff;
  

•   	bmask = 0xff0000;
  

•   flags = SDL_SWSURFACE;
  

• } else {

•   vf = SDL_PublicSurface->format;
  

•   switch(vf->BytesPerPixel) {
  

•       case 2:
  

•   	/* For XGY5[56]5, use, AXGY8888, where {X, Y} = {R, B}.
  

•   	   For anything else (like ARGB4444) it doesn't matter
  

•   	   since we have no special code for it anyway */
  

•   	if ( (vf->Rmask == 0x1f) &&
  

•   	     (vf->Bmask == 0xf800 || vf->Bmask == 0x7c00)) {
  

•   		rmask = 0xff;
  

•   		bmask = 0xff0000;
  

•   	}
  

•   	break;
  

•       case 3:
  

•       case 4:
  

•   	/* Keep the video format, as long as the high 8 bits are
  

•   	   unused or alpha */
  

•   	if ( (vf->Rmask == 0xff) && (vf->Bmask == 0xff0000) ) {
  

•   		rmask = 0xff;
  

•   		bmask = 0xff0000;
  

•   	}
  

•   	break;
  

•       default:
  

•   	/* We have no other optimised formats right now. When/if a new
  

•   	   optimised alpha format is written, add the converter here */
  

•   	break;
    }
  

•   break;
  

•   default:
  

•   /* We have no other optimised formats right now. When/if a new
  

•      optimised alpha format is written, add the converter here */
  

•   break;
  

•   flags = SDL_PublicSurface->flags & SDL_HWSURFACE;
  

•   flags |= surface->flags & (SDL_SRCALPHA | SDL_RLEACCELOK);
  

  }
• format = SDL_AllocFormat(32, rmask, gmask, bmask, amask);

• flags = SDL_PublicSurface->flags & SDL_HWSURFACE;
• flags |= surface->flags & (SDL_SRCALPHA | SDL_RLEACCELOK);
  converted = SDL_ConvertSurface(surface, format, flags);
  SDL_FreeFormat(format);
  return(converted);
  -------------- next part --------------
  A non-text attachment was scrubbed…
  Name: not available
  Type: application/pgp-signature
  Size: 273 bytes
  Desc: not available
  URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020430/3f2db81f/attachment.pgp