Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

32
36-02.md
View file

@ -9,15 +9,15 @@ dimension), while maintaining an integer error term indicating how close
the line is to advancing an extra pixel along the major axis, as
illustrated by Figure 36.2.
Consider this: When you’re called upon to draw a line with an
Consider this: When you're called upon to draw a line with an
X-dimension of 35 and a Y-dimension of 10, you have a great deal of
information available, some of which is ignored by standard Bresenham’s.
information available, some of which is ignored by standard Bresenham's.
In particular, because the slope is between 1/3 and 1/4, you know that
every single run—a *run* being a set of pixels at the same minor-axis
coordinate—must be either three or four pixels long. No other length is
possible, as shown in Figure 36.3 (apart from the first and last runs,
which are special cases that I’ll discuss shortly). Therefore, for this
line, there’s no need to perform an error-term calculation and test for
which are special cases that I'll discuss shortly). Therefore, for this
line, there's no need to perform an error-term calculation and test for
each pixel. Instead, we can just perform one test per run, to see
whether the run is three or four pixels long, thereby eliminating about
70 percent of the calculations in drawing this line.
@ -26,13 +26,13 @@ Take a moment to let the idea behind run-length slice drawing soak in.
Periodic decisions must be made to control pixel placement. The key to
speed is to make those decisions as infrequently and as quickly as
possible. Of course, it will work to make a decision at each
pixel—that’s standard Bresenham’s. However, most of those per-pixel
pixel—that's standard Bresenham's. However, most of those per-pixel
decisions are redundant, and in fact we have enough information before
we begin drawing to know which are the redundant decisions. Run-length
slice drawing is exactly equivalent to standard Bresenham’s, but it
pares the decision-making process down to a minimum. It’s somewhat
slice drawing is exactly equivalent to standard Bresenham's, but it
pares the decision-making process down to a minimum. It's somewhat
analogous to the difference between finding the greatest common divisor
of two numbers using Euclid’s algorithm and finding it by trying every
of two numbers using Euclid's algorithm and finding it by trying every
possible divisor. Both approaches produce the desired result, but that
which takes maximum advantage of the available information and minimizes
redundant work is preferable.
@ -66,29 +66,29 @@ to add an extra pixel to a run. The fraction indicates what portion of
an extra pixel we advance along X (the major axis) during each run. If
we keep a running sum of the fractional parts, we have a measure of how
close we are to needing an extra pixel; when the fractional sum reaches
1, it’s time to add an extra pixel to the current run. Then, we can
1, it's time to add an extra pixel to the current run. Then, we can
subtract 1 from the running sum (because we just advanced one pixel),
and continue on.
![](images/36-04.jpg)\
**Figure 36.4**  *How the error term determines run length.*
Practically speaking, however, we can’t work with fractions because
Practically speaking, however, we can't work with fractions because
floating-point arithmetic is slow and fixed-point arithmetic is
imprecise. Therefore, we take a cue from standard Bresenham’s and scale
imprecise. Therefore, we take a cue from standard Bresenham's and scale
all the error-term calculations up so that we can work with integers.
The fractional X (major axis) advance per one-pixel Y (minor axis)
advance is the fractional portion of **XDelta/YDelta**. This value is
exactly equivalent **to (XDelta % YDelta)/YDelta**. We’ll scale this up
exactly equivalent **to (XDelta % YDelta)/YDelta**. We'll scale this up
by multiplying it by **YDelta\*2**, so that the amount by which we
adjust the error term up for each one-pixel minor-axis advance is
**(XDelta % YDelta)\*2**.
We’ll similarly scale up the one pixel by which we adjust the error term
We'll similarly scale up the one pixel by which we adjust the error term
down after it turns over, so our downward error-term adjustment is
**YDelta\*2**. Therefore, before drawing each run, we’ll add **(XDelta %
**YDelta\*2**. Therefore, before drawing each run, we'll add **(XDelta %
YDelta)\*2** to the error term. If the error term runs over (reaches one
full pixel), we’ll lengthen the run by 1, and subtract **YDelta\*2**
full pixel), we'll lengthen the run by 1, and subtract **YDelta\*2**
from the error term. (All values are multiplied by 2 so that the initial
error term, which involves a 0.5 term, can be scaled up to an integer,
as discussed next.)
@ -113,7 +113,7 @@ the time. On a 486, this amounts to something on the order of 150
nanoseconds of overhead per pixel, exclusive of the time required to
actually write the pixel to display memory.
That’s good.
That's good.
------------------------ --------------------------------- --------------------
[Previous](36-01.html) [Table of Contents](index.html) [Next](36-03.html)