Archgrove - Implicit Definition

Well, despite embedding a couple of “bonus questions” into yesterdays post, I didn’t receive any answers. I’ll have to make the next ones easier! Anyway, here are the answers.

Question 1: What has become common since DirectX 6 that means DirectX 9 doesn’t need good colour key support?

The answer I was specifically looking for was “hardware accelerated alpha blending”. I would also have taken “transparency” and partial credit would be given for “3D cards”.

Alpha blending is the composition of two images together so that one of them appears to be translucent on top of the other. You’ve all seen the effects –smoke that clouds your vision, see through water etc. Whilst simple mathematically, these operations are pretty CPU intensive. Say we’re going to draw image A over image B, with image A slightly translucent. We have to read every pixel from image A, and blend the colour values with image B, to produce our final image. Even if you only run at 800×600 resolution, that’s 800*600 = 480000 pixels to read twice (one for each image), and the same amount of the actual blending operations – every frame!

Here’s another “Stuff you might want to know”^TM aside.

When someone sends you an image via email, and might notice your paint program opening it as “24 bit”, and if you’re au-fait with graphics, you might have even seen “32 bit”. These “bits” refer to the colours in each pixel the image. Most of the time, 24 bit images are enough – 8 bits for red, 8 bits for green and 8 bits for blue produce all the colours your eye can resolve. So what’s the extra 8 for in 32 bit images? Why – alpha! These 8 bits say, “When you composite this image onto another one, here’s how translucent this pixel is”. These 8 bits are called the “alpha channel”.

The hardware of yore wasn’t really sophisticated enough to handle the operations required for alpha blending, but they did implement colour keying (as a concept, it turns up remarkably often). But today, with the advent of graphics cards that can do a bazillion blended polygons, having specific functionality for colour keying would be redundant. Programs are now expected to just provide an alpha channel for their images, and where they want to “see though” (in the way that colour keys provided), you just set your alpha bits to 100% transparent.

So, specific colour keying functionality in graphics APIs has largely gone the way of the dodo, to be replaced by something more flexible and useful. Vive la progress!

Question 2: Can you tell me why the final phase, which draws the plugin window and the control bar, doesn’t need to use the colour key drawing object?

The answer is basically “As the plugin window and control bar are rectangular, we don’t need to composite them in with colour keys – they cut right out without needing to be see through anywhere”.

This one required a bit of lateral thinking. We know from the first article that we’re now drawing straight onto the AC window – as such, we don’t need to draw onto a big “buffer” first, which will then be copied across. If we did need such a buffer, we’d still have to use colour keys (otherwise, the background of the buffer would completely cover the AC window). Additionally, because all the images we’re drawing are rectangular, and don’t have any see through portions, we don’t have to deal with colour keying for them either! So, we don’t need colour keying at all for the final phase of composition.

I hope that’s not too confusing!

As to further writing, I’ve had requests to make a post about how the memory locations (“memlocs”) are actually found. This is a pretty involved topic, but I’ll try and write something today; maybe I’ll even include a “find your own memloc” quiz! Wow, this just gets better and better, doesn’t it?