Replace invalid characters with HTML entities
— with — ’ with ’ + with + × with x ç with ç “ with “ ” with ” ‘ with ‘ • with • – with - µ with µ † with † Fix C++ θ with θ Yen symbol instead of times Fix broken apos Bullet again E-circumflex
This commit is contained in:
parent
9e52de9586
commit
500e7f5654
353 changed files with 5091 additions and 5091 deletions
38
42-05.html
38
42-05.html
|
|
@ -45,7 +45,7 @@
|
|||
; 1991 issue of Computer Graphics. Requires that the palette be set up so
|
||||
; that there are NumLevels intensity levels of the desired drawing color,
|
||||
; starting at color BaseColor (100% intensity) and followed by (NumLevels-1)
|
||||
; levels of evenly decreasing intensity, with color (BaseColor+NumLevels-1)
|
||||
; levels of evenly decreasing intensity, with color (BaseColor+NumLevels-1)
|
||||
; being 0% intensity of the desired drawing color (black). No clipping is
|
||||
; performed in DrawWuLine. Handles a maximum of 256 intensity levels per
|
||||
; antialiased color. This code is suitable for use at screen resolutions,
|
||||
|
|
@ -71,7 +71,7 @@ Y1 dw ? ;Y coordinate of line end point
|
|||
BaseColor dw ? ;color # of first color in block used for
|
||||
;antialiasing, the 100% intensity version of the
|
||||
;drawing color
|
||||
NumLevels dw ? ;size of color block, with BaseColor+NumLevels-1
|
||||
NumLevels dw ? ;size of color block, with BaseColor+NumLevels-1
|
||||
; being the 0% intensity version of the drawing color
|
||||
; (maximum NumLevels = 256)
|
||||
IntensityBits dw ? ;log base 2 of NumLevels; the # of bits used to
|
||||
|
|
@ -138,7 +138,7 @@ DeltaXSet:
|
|||
jns DoHorz ;yes, all set
|
||||
std ;no, draw right->left
|
||||
DoHorz:
|
||||
lea di,[bx+si] ;point DI to next pixel to draw
|
||||
lea di,[bx+si] ;point DI to next pixel to draw
|
||||
mov ax,ds
|
||||
mov es,ax ;point ES:DI to next pixel to draw
|
||||
mov al,byte ptr [bp].BaseColor ;color with which to draw
|
||||
|
|
@ -167,7 +167,7 @@ NotVert:
|
|||
;yes, is diagonal, special case
|
||||
mov al,byte ptr [bp].BaseColor ;color with which to draw
|
||||
DiagLoop:
|
||||
lea si,[si+SCREEN_WIDTH_IN_BYTES+bx]
|
||||
lea si,[si+SCREEN_WIDTH_IN_BYTES+bx]
|
||||
;advance to next pixel to draw by
|
||||
; incrementing Y and adding XDir to X
|
||||
mov [si],al ;draw the next pixel
|
||||
|
|
@ -228,14 +228,14 @@ NoXAdvance:
|
|||
; paired pixel.
|
||||
mov ah,dh ;msb of ErrorAcc
|
||||
shr ah,cl ;Weighting = ErrorAcc >> IntensityShift;
|
||||
add ah,al ;BaseColor + Weighting
|
||||
mov [si],ah ;DrawPixel(X, Y, BaseColor + Weighting);
|
||||
add ah,al ;BaseColor + Weighting
|
||||
mov [si],ah ;DrawPixel(X, Y, BaseColor + Weighting);
|
||||
mov ah,dh ;msb of ErrorAcc
|
||||
shr ah,cl ;Weighting = ErrorAcc >> IntensityShift;
|
||||
xor ah,ch ;Weighting ^ WeightingComplementMask
|
||||
add ah,al ;BaseColor + (Weighting ^ WeightingComplementMask)
|
||||
mov [si+bx],ah ;DrawPixel(X+XDir, Y,
|
||||
; BaseColor + (Weighting ^ WeightingComplementMask));
|
||||
add ah,al ;BaseColor + (Weighting ^ WeightingComplementMask)
|
||||
mov [si+bx],ah ;DrawPixel(X+XDir, Y,
|
||||
; BaseColor + (Weighting ^ WeightingComplementMask));
|
||||
dec di ;--DeltaY
|
||||
jnz YMajorLoop
|
||||
jmp Done ;we're done with this line
|
||||
|
|
@ -288,15 +288,15 @@ NoYAdvance:
|
|||
; paired pixel.
|
||||
mov ah,dh ;msb of ErrorAcc
|
||||
shr ah,cl ;Weighting = ErrorAcc >> IntensityShift;
|
||||
add ah,al ;BaseColor + Weighting
|
||||
mov [si],ah ;DrawPixel(X, Y, BaseColor + Weighting);
|
||||
add ah,al ;BaseColor + Weighting
|
||||
mov [si],ah ;DrawPixel(X, Y, BaseColor + Weighting);
|
||||
mov ah,dh ;msb of ErrorAcc
|
||||
shr ah,cl ;Weighting = ErrorAcc >> IntensityShift;
|
||||
xor ah,ch ;Weighting ^ WeightingComplementMask
|
||||
add ah,al ;BaseColor + (Weighting ^ WeightingComplementMask)
|
||||
mov [si+SCREEN_WIDTH_IN_BYTES],ah
|
||||
;DrawPixel(X, Y+SCREEN_WIDTH_IN_BYTES,
|
||||
; BaseColor + (Weighting ^ WeightingComplementMask));
|
||||
add ah,al ;BaseColor + (Weighting ^ WeightingComplementMask)
|
||||
mov [si+SCREEN_WIDTH_IN_BYTES],ah
|
||||
;DrawPixel(X, Y+SCREEN_WIDTH_IN_BYTES,
|
||||
; BaseColor + (Weighting ^ WeightingComplementMask));
|
||||
dec di ;--DeltaX
|
||||
jnz XMajorLoop
|
||||
|
||||
|
|
@ -311,13 +311,13 @@ _DrawWuLine endp
|
|||
</PRE>
|
||||
<!-- END CODE //-->
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading6"></A><FONT COLOR="#000077">Notes on Wu Antialiasing</FONT></H4>
|
||||
<P>Wu antialiasing can be applied to any curve for which it’s possible to calculate at each step the positions and intensities of two bracketing pixels, although the implementation will generally be nowhere near as efficient as it is for lines. However, Wu’s article in <I>Computer Graphics</I> does describe an efficient algorithm for drawing antialiased circles. Wu also describes a technique for antialiasing solids, such as filled circles and polygons. Wu’s approach biases the edges of filled objects outward. Although this is no good for adjacent polygons of the sort used in rendering, it’s certainly possible to design a more accurate polygon-antialiasing approach around Wu’s basic weighting technique. The results would not be quite so good as more sophisticated antialiasing techniques, but they would be much faster.</P>
|
||||
<TABLE WIDTH="100%"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="5%"><IMG SRC="images/i.jpg"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="95%"><SMALL><I>In general, the results obtained by Wu antialiasing are only so-so, by theoretical measures. Wu antialiasing amounts to a simple box filter placed over a fixed-point step approximation of a line, and that process introduces a good deal of deviation from the ideal. On the other hand, Wu notes that even a 10 percent error in intensity doesn’t lead to noticeable loss of image quality, and for Wu-antialiased lines up to 1K pixels in length, the error is under 10 percent. If it looks good, it is good—and it looks good.</I></SMALL>
|
||||
<P>Wu antialiasing can be applied to any curve for which it’s possible to calculate at each step the positions and intensities of two bracketing pixels, although the implementation will generally be nowhere near as efficient as it is for lines. However, Wu’s article in <I>Computer Graphics</I> does describe an efficient algorithm for drawing antialiased circles. Wu also describes a technique for antialiasing solids, such as filled circles and polygons. Wu’s approach biases the edges of filled objects outward. Although this is no good for adjacent polygons of the sort used in rendering, it’s certainly possible to design a more accurate polygon-antialiasing approach around Wu’s basic weighting technique. The results would not be quite so good as more sophisticated antialiasing techniques, but they would be much faster.</P>
|
||||
<TABLE WIDTH="100%"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="5%"><IMG SRC="images/i.jpg"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="95%"><SMALL><I>In general, the results obtained by Wu antialiasing are only so-so, by theoretical measures. Wu antialiasing amounts to a simple box filter placed over a fixed-point step approximation of a line, and that process introduces a good deal of deviation from the ideal. On the other hand, Wu notes that even a 10 percent error in intensity doesn’t lead to noticeable loss of image quality, and for Wu-antialiased lines up to 1K pixels in length, the error is under 10 percent. If it looks good, it is good—and it looks good.</I></SMALL>
|
||||
</TABLE>
|
||||
<P>With a 16-bit error accumulator, fixed-point inaccuracy becomes a problem for Wu-antialiased lines longer than 1K. For such lines, you should switch to using 32-bit error values, which would let you handle lines of any practical length.
|
||||
</P>
|
||||
<P>In the listings, I have chosen to truncate, rather than round, the error-adjust value. This increases the intensity error of the line but guarantees that fixed-point inaccuracy won’t cause the minor axis to advance past the endpoint. Overrunning the endpoint would result in the drawing of pixels outside the line’s bounding box, and potentially even in an attempt to access pixels off the edge of the bitmap.</P>
|
||||
<P>Finally, I should mention that, as published, Wu’s algorithm draws lines symmetrically, from both ends at once. I haven’t done this for a number of reasons, not least of which is that symmetric drawing is an inefficient way to draw lines that span banks on banked Super-VGAs. Banking aside, however, symmetric drawing is potentially faster, because it eliminates half of all calculations; in so doing, it cuts cumulative error in half, as well.</P>
|
||||
<P>In the listings, I have chosen to truncate, rather than round, the error-adjust value. This increases the intensity error of the line but guarantees that fixed-point inaccuracy won’t cause the minor axis to advance past the endpoint. Overrunning the endpoint would result in the drawing of pixels outside the line’s bounding box, and potentially even in an attempt to access pixels off the edge of the bitmap.</P>
|
||||
<P>Finally, I should mention that, as published, Wu’s algorithm draws lines symmetrically, from both ends at once. I haven’t done this for a number of reasons, not least of which is that symmetric drawing is an inefficient way to draw lines that span banks on banked Super-VGAs. Banking aside, however, symmetric drawing is potentially faster, because it eliminates half of all calculations; in so doing, it cuts cumulative error in half, as well.</P>
|
||||
<P>With or without symmetrical processing, Wu antialiasing beats fried, stewed chicken hands-down. Trust me on this one.</P><P><BR></P>
|
||||
<CENTER>
|
||||
<TABLE BORDER>
|
||||
|
|
|
|||
Loading…
Reference in a new issue