Further ruminations of the Edsun CEG/DAC

 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)
 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.
 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
 Feature:   illustration
 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?


 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

 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

 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

 [BACK] Back

Discuss this article in the forums

Date this article was posted to GameDev.net: 7/16/1999
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Michael Abrash's Articles

© 1999-2011 Gamedev.net. All rights reserved. Terms of Use Privacy Policy
Comments? Questions? Feedback? Click here!