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)
(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.
[BACK] Back
Discuss this article in the forums
See Also: © 1999-2011 Gamedev.net. All rights reserved. Terms of Use Privacy Policy
|