XScreenSaver 4.20 out now! Fun stuff:

• glslideshow should be a lot faster now (that's partly what all those OpenGL test programs I was having you run were about.)
• carousel is a new slideshow program that draws 7 images at once that is chock full of the awesome.
• starwars uses real fonts instead of that crappy line-segment font it had been using; it looks a zillion times better now.
• bsod -only nvidia (watch it change)
• sonar shows ping times.
• substrate -circle-percent 100
• boing -scanlines
• boing -smooth lighting
• boxfit (click in the window to restart early)
• fiberlamp (move the window around)

<LJ-CUT text=" --More--(69%) "> Help wanted:

I'm really happy with how carousel turned out, but there's some weird alpha-blending glitch that I can't figure out. Click and drag with the mouse until the text label of one of the images is on top of another image, so that you can see the text on a non-black background. Sometimes it looks right, but sometimes there are black boxes around the characters. Now here's the weird part: the same piece of text will have boxes when over one image, but not when over another! You can drag it left and right and see the boxes appear and disappear depending on what's underneath it.

So, somehow alpha-blending isn't working right, but I can't figure out why. It's very confusing that it's intermittent like this: I'd expect it to always work or always not!

Maybe I'm creating the texture wrong? I'm using INTENSITY / LUMINANCE / BYTE and handing it 8bpp data (where the values are either 0 or 255.) I'm trying to say, "create a texture whose R, G, B, and A are all the same value." texfont.c line 81.

Update:

Thanks everybody, I fixed carousel by drawing the images, then making a second pass to draw the text. (It'll be in the next release.)

When dealing with alpha in OpenGL, you have to render your scene back to front, from the point of view of the observer. I knew this at some point, but I forgot.

You don't have to jump through that hoop with normal polygons, because GL has a depth buffer. That means that for every pixel on the screen, it stores not only its color, but also its depth (distance from the observer.) So when you tell it to draw a "far" pixel, and there's a "near" pixel on the screen already, it doesn't overwrite it, and life is easy.

But, apparently alpha blending was an afterthought or something, so GL doesn't store the transparency of the pixels it writes, only the color. That is, when combining two pixels, it knows the transparency level of the pixel being written, but not of the pixel that's already there. So you can draw "50% tranparent" on top of "100% opaque", but not the other way around (which, in a sane world, would give you the same result, assuming the transparent pixel was closer to the observer.)

Not storing alpha in the color buffer seems pretty goofy to me, since they are almost certainly using 32bpp instead of packed 24bpp anyway, meaning there's an unused byte just sitting there...