Journal: Dr. Dobb's Journal May 1991 v16 n5 p131(7) ----------------------------------------------------------------------------- Title: Further ruminations of the Edsun CEG/DAC. (Hardware Review) (Continuous Edge Graphics Digital-to-Analog-Converter) (evaluation) Author: Abrash, Michael. AttFile: Program: GP-MAY91.ASC Source code listing. Summary: Edsun Laboratories' CEG/DAC (Continuous Edge Graphics Digital-to-Analog Converter) (CEG/DAC) enables a VGA system to display graphics at near 24-bit-per-pixel (bpp) quality, but is better suited to static than dynamic images. The CEG/DAC is not a true 24-bpp device but achieves its performance by embedding information to reprogram the palette in the bitmap and pixel weighting, a process of specifying pixel colors as weighted mixes of adjacent pixels. Pixel weighting also works well for eliminating jaggedness in lines in static images but does not work well for performing temporal aliasing for sequences of animated images. Methods for working around CEG/DAC's limitations in generating dynamic images are discussed. Several routines demonstrate the visual capabilities of the technology. ----------------------------------------------------------------------------- Descriptors.. Company: Edsun Laboratories Inc. (Products). Product: Edsun Laboratories Continuous Edge Graphics Digital-to-Analog Converter (Graphics coprocessor). Topic: Graphics Coprocessors Integrated Circuits Digital to Analog Convertors Evaluation. Feature: illustration chart program. Caption: A typical CEG/DAC pixel weighting sequence. (chart) An example of the special CEG/DAC line-drawing pixel weighting sequence. (chart) Routine to animate a line rotating about its center. (program) ----------------------------------------------------------------------------- Full Text: If late, I find myself asking many questions, but finding few easy answers. How do lawyers manage to innovate without the incentive and protection of patents for their work? Why is this nation capable of mounting an awesome attack half a world away in just a couple of months, but unable to devise a coherent energy policy in ten years? Why does anyone buy a 386*387 machine when a 486 costs just about the same and is two to five times faster at floating point operations? I wonder about these things, I do. And, for lo these many weeks since last we spoke, I have wondered this: What is the place, in the grand scheme of things, of the Edsun Continuous Edge Graphics Digital-toAnalog-Converter (CEG/DAC)? What is it that this chip can and cannot do? The CEG/DAC As I discussed last month, the CEG/DAC is a VGA DAC substitute that makes a VGA capable of displaying graphics of near 24-bit-per-pixel (bpp) quality. This is accomplished via two features: Embedding in the bitmap information that reprograms the palette (EDP), and specifying pixel colors as mixes of the colors of neighboring pixels (pixel weighting). I stated last month that I think that Super VGA-plus-CEG/DAC may well be the next PC graphics standard. i still think that. The question I now have is: What sorts of graphics are the features of the CEG/DAC good for, out of the many things a PC programmer might wish for? Were the CEG/DAC a true 24-bpp device, there'd be no question; it would be able to display any sort of graphics at all, limited only by the speed of the graphics code. However, the CEG/DAC is not a true 24-bpp device, and although sometimes it is a good substitute, sometimes it clearly is not-and often it is somewhere in between. I have come to think that the CEG/DAC is more useful for static images than for dynamic images (animation, real-time screen updates, and the like); in particular, the limitations of pixel weighting must be attended to carefully when animating. For example, consider the simple task of drawing a line. Drawing Lines Through Space The standard technique for drawing lines rapidly is Bresenham's Algorithm. Bresenham-style lines suffer from one flaw: They tend to look jagged, because the line jumps abruptly from one pixel to the next. The traditional cure for jaggles is antialiasing. Technically, antialiasing is the process of removing spurious signals resulting from undersampling, typically with a low-pass filter, but in the context of graphics, antialiasing has come to mean any process that helps eliminate jaggies. The CEG/DAC's pixel weighting feature is designed to do exactly that, by allowing you to mix the colors of horizontally neighboring pixels. Pixel weighting works very well for smoothing jaggies in a single, static image. Run Listing Two (page 149), which when linked to Listing One (page 149) draws a rotating nonantialiased line floating point rather than Bresenham's is used for clarity and to save space, but the same points are drawn), and press a key to freeze the image; you will see prominent jaggies along the length of the line. Now run Listing Three (page 150) linked to Listing One (if you have a CEG/DAC) or Listing Four (page 150) linked to Listing One (if you don't) to draw an antialiased line, and press a key to freeze the image. (Listing Three antialiases using CEG/DAC pixel weighting, as described later, and Listing Four emulates pixel weighting by setting up the VGA palette with 32 weighted mixes of the line and background colors.) The jaggies are gone, replaced with smooth edges. There are two sorts of aliasing in graphics, though. What we've just seen is spatial aliasing-aliasing over space, in this case over the pixels of the screen. There's also temporal aliasing, aliasing from one image to the next as animation is performed. When Listing Two is allowed to run freely, temporal aliasing is clearly visible in the form of jaggies crawling wildly along the edges of the line. It is this distracting and often hideous effect that drives the need for temporal antialiasing. Drawing Lines Over Time Pixel weighting doesn't serve particularly well for temporal antialiasing, for a number of reasons. The line animation performed by Listings Three and Four looks better than that of Listing Two, but there are still shifting patterns in the line, the line's brightness varies, and the line's motion appears less than perfectly smooth. There are several reasons for this, two of which have nothing to do with the CEG/DAC: The aspect ratio in 320 x 200 mode isn't 1: 1, and the fineness and accuracy of motion is limited by the use of integer coordinates. (Then again, pixel weighting is poorly suited to drawing based on fractional coordinates, because such drawing must often represent three or more color influences on a single pixel.) However, a number of other problems are directly related to the nature of the CEG/DAC. For one thing, the line's brightness varies with angle. This is a side effect of the way the CEG/DAC handles Y-major lines (lines that are longer along the Y axis than the X axis). Normally, the CEG/DAC requires at least three pixels in a row to specify a single weighted pixel: Two colors to average between and a pixel weighting, which averages between the two colors, as shown in Figure 1. (I'm speaking of Advanced-8 mode here, the mode in which the maximum number of colors is available.) Requiring three or more pixels across for pixel weighting in this fashion would make it impossible to draw thin lines, especially in close proximity. Edsun solved this by introducing a special case. If a pixel color is followed by a pixel mix and then by another color, the first color is taken to specify a line color, and the mix is taken to speci6, the weighting between the line color and the background color for the two pixels of the line, as shown in Figure 2. The mix itself is applied to the pixel that specified the line color, and the complement of the mix is applied to the pixel that specified the mix. in other words, a color-mix pair in the middle of a line of colors is taken to be a standalone unit specifying a cross-section of a two-pixel-wide line, and the mix is applied to spread the color across the two pixels in such a way that the intensity of the line color totals 100 percent. (Neither is this the only special case; CEG/DAC programming is not trivial.) A total line intensity of 100 percent on each scan line sounds good, but in fact it is rarely correct. A vertical line should indeed have 100 percent intensity across each scan line. However, as the line tilts toward 45 degrees, the intensity per scan line should increase toward @2, because the line is covering more ground from one scan line to the next. With pixel weighting, however, the intensity per scan line remains the same, so the overall brightness of the line decreases. Also, the width of a line drawn with 100 percent-sum pixel weighting varies with angle; horizontal and vertical lines are only one pixel wide, but all other lines spread across two pixels along the minor axis (the axis along which the line's length is less). The line's width, measured along the normal, also varies along the length of the line; this shows up as motion along the edges of the line as it turns, although it is more subdued than normal jaggies. The above caveats are also true of static images drawn with pixel weighting, but there they are not nearly as noticeable. I've said before that graphics is the art of fooling the eye and the brain. They're easily fooled for man things., for example, they're quite willing to interpret a sequence of slightly different images, displayed at a rate of 30 images per second, as motion. By the same token, however, disturbances in the smooth progression of change over time stick out like red flags. Don't ask me why-, probably it was a handy trait to have when spotting prey or avoiding being prey was a full time job. At any rate, consistency from one frame to the next is essential. Unfortunately, temporal consistency requires more than simply smoothing edges; it requires filtering the image so that spurious elements are removed that is, true antialiasing. With true antialiasing, a consistent representation of the image can be obtained from one frame to the next, no matter how the image is rotated or shifted, or what it is bordered by. I'd love to show you true antialiasing in action, but I'm well and truly running out of space; I promise to return to the topic soon. True antialiasing requires that colors be settable as arbitrary mixes of the surrounding primitives in all directions. Pixel weighting does not make that possible. Therefore, except under special circumstances, pixel weighting is a dejagging rather than antialiasing tool, and is useful primarily for smoothing static images (where it surely does look good), rather than for smoothing dynamic images. Further Limitations of Pixel Weighting There are other problems with dynamic pixel weighting. Programming is a cumbersome process, for starters. Consider Listing Three. For Y-major lines, the weighting between the two pixels on each scan line has to be calculated; while that can certainly be done without floating-point calculations, I do not see how it can be done without either an integer divide or a table search. Either way, lines drawn with pixel weighting are going to be considerably slower than Bresenham's lines. X-major lines have their complications, too. Here the minor axis is vertical, so we must split the 100 percent brightness at each step between two scan lines. Unfortunately, the CEG/DAC is strictly a horizontally oriented device, so we are obliged to make sure that the line color precedes the mix sequence on each scan line, as shown in Figure 1. (The pixel establishing the line color actually displays in the previous pixel's color-, the line color doesn't show up until the first mix pixel, in the form of the specified mix.) There's another complication-, if any scan line has only one mix command, then that mix and the preceding color are interpreted as a special-case two pixel line mix, as described earlier, rather than a normal mix sequence, and the colors displayed for the pixels are quite different. These complications could have been handled as special cases in Listing Three; however, I decided that the code would be simpler and the operation of the CEG/ DAC would be clearer if I just drew all the mix pixels, then processed the buffer afterward to insert leading line color pixels and clean up one-mix sequences. If you think all this sounds involved and slow, well, it is. it's by no means unmanageable, and certainly much more efficient implementations are possible, but CEG drawing does, nonetheless, generally require additional coding and execution time. Moreover, I didn't have to worry about handling intersections with other lines and graphics objects in Listing Three; normally, such intersections have to be checked for and potentially patched up, because they can generate unintended results by disrupting existing mix sequences. In addition, there are potential problems with left-side clipping of pixel weighting sequences. There are, of course, workarounds for many of these limitations. If no rotation is performed and all moves are by an integral number of pixels, edge crawling largely vanishes. Careful construction of animation so that objects don't overlap can eliminate the complications of checking the bitmap for intersections. Also, many primitives, such as rectangle fills, don't require any antialiasing, and antialiased text can be predefined, then simply copied to the screen as needed. In fact, predefining antialiased images and avoiding troublesome situations such as rotated polygons, inter sections with other objects, and clip ping may be keys to high-performance CEG/DAC code. When such condition are unavoidable, you may want to consider EDP (on-the-fly palette loading), which is probably the best bet for high color-content dynamic drawing with the CEG/DAC. (Basic-8 mode is simpler and faster when only a few colors are required.) Consider this: EDP does not suffer from clipping problems. Neither must drawing that relies only on EDP concern itself with intersections; every pixel is independent. The only remaining problem lies in making available all the colors needed for drawing. Suppose that in 640 x 480 256-color mode, you choose to allocate 160 pixels at the left and right edges of the screen (about 25 percent of the width of the screen) to static images, composed of mostly solid colors. EDP requires five pixels to load a single palette location, so about 30 colors could be changed per scan line during the static edges. Additional colors could be set in the active portion of the display, with the EDP commands embedded in areas of solid color. Now, there would be 480 pixels in the active region across each scan line. 223 independent colors (the number available in Advanced-8 mode), with at least 30 changeable from line to line, could often serve quite nicely to draw whatever it is that those 480 pixels across are supposed to represent. No, it wouldn't be the same as drawing with 24 arbitrary bpp, but, properly structured.. it might not look a whole lot different; Listing Four, which uses only careful palette loading, antialiases just as well as the CEG hardware in Listing Three, and, with the help of EDP, would be considerably more flexible. (Not coincidentally, the photorealistic images in the Edsun demo have large blank borders.) Best of all, the only complications with EDP-based drawing would be figuring out which colors to change and where for maximum effect; the far greater complications of pixel weighting are avoided. Of course, reliance on EDP is not a technique that a general-purpose driver can use; it's necessary that the application be CEG/DAC-aware. Long ago, all graphics applications were hardware aware; now quasi-hardware-independence, through general interfaces such as Windows and X Window System, is the mainstream. I suspect that the truly mind-blowing CEG/DAC applications will be throwbacks to that earlier era. in the end, what I'm saying is that if you want to do spectacular animation on the CEG/DAC, you might do well to ignore pixel weighting altogether, at least for images that must be generated in realtime or might intersect, and focus on EDP. That was obviously not Edsun's intent, for they didn't make it possible to enable only EDP; that's a shame, because then we'd have 255 main colors to work with. Overall, I think the CEG/DAC is better suited to static images than dynamic; as the Edsun demo illustrates, the CEG/DAC is stunningly good at static displays, and as the examples in this column illustrate, there are significant complications and limitations associated with dynamic displays. One of the tricks is converting as much drawing as possible from dynamic to static; that's what predefining images and keeping them from intersecting is all about. Although the CEG/DAC is a powerful resource, in some respects it comes up short; it should be fascinating to watch as techniques evolve to work around its limitations. Book of the Month This month's book is The RenderMan Companion, by Steve Upstill (AddisonWesley, 1990). RenderMan is a comprehensive programming interface specification for 3-D graphics., implementations of the RenderMan interface have been the basis for stunning photorealistic imaging and special effects. (For background information on RenderMan, see Upstill's article "Photorealism in Computer Graphics," in DDJ, November 1988). Companion takes you on a wide-ranging tour of the RenderMan interface, with plenty of sample code and output; even if you never program RenderMan directly, this book provides worthwhile insight into the nature of 3-D rendering. At the very least, read the foreword, a brief history of computer graphics and the development of RenderMan; it provides a sense of the dizzying pace of progress in computer graphics, and of the people behind the wonders. Which brings a thought to mind. I don't know how many, if any, of the techniques discussed in Companion and in the various standard graphics references are patented, but I've never seen a mention of such. How is it, I ask all you software patent proponents, that all this invention, publishing, and sharing of knowledge for the public benefit happened without the necessary" incentive and protection of patents? Think about it, that's all I ask.