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

Change bold code snippets to inline code blocks

Browse source
This commit is contained in:
James Gregory 2013-12-31 17:12:29 +11:00
commit 3c76d884ef
185 changed files with 1772 additions and 1772 deletions
Download patch file Download diff file Expand all files Collapse all files

10
39-02.md
View file

@ -11,7 +11,7 @@ pages: 727-730
---
At any rate, Listing 39.1 for this chapter shows a version of
**DrawHorizontalLineList** that uses memset to draw each scan line of
`DrawHorizontalLineList` that uses memset to draw each scan line of
the polygon in a single call. When linked to Chapter 38's test program,
Listing 39.1 increases pure drawing speed (disregarding edge tracing and
other nondrawing time) by more than an order of magnitude over Chapter
@ -37,7 +37,7 @@ Table: Table 39.1 Polygon fill performance.
All times are in seconds, as measured with Turbo Profiler on a 20-MHz
cached 386 with no math coprocessor installed. Note that time spent in
**main()** is not included. C code was compiled with Borland C++ with
`main()` is not included. C code was compiled with Borland C++ with
maximum optimization (-G -O -Z -r -a); assembly language code was
assembled with TASM. Percentages of combined times are rounded to the
nearest percent, so the sum of the three percentages does not always
@ -95,7 +95,7 @@ drawn, or if a faster or slower computer/VGA combination were used.
These factors notwithstanding, the test program does fill a variety of
polygons of varying complexity sized from large to small and in between,
and certainly the order of magnitude difference between Listing 39.1 and
the old version of **DrawHorizontalLineList** is a clear indication of
the old version of `DrawHorizontalLineList` is a clear indication of
which code is superior.
Anyway, Listing 39.1 has the desired effect of vastly improving drawing
@ -105,7 +105,7 @@ logical to optimize the tracing code next.
#### Fast Edge Tracing {#Heading5}
There's no secret as to why last chapter's **ScanEdge** was so slow: It
There's no secret as to why last chapter's `ScanEdge` was so slow: It
used floating point calculations. One secret of fast graphics is using
integer or fixed-point calculations, instead. (Sure, the floating point
code would run faster if a math coprocessor were installed, but it would
@ -124,7 +124,7 @@ integer-based test image to one produced by floating-point calculations,
two pixels out of the whole screen differed, leading me to suspect a bug
in the integer code. It turned out, however, that's in those two cases,
the floating point results were sufficiently imprecise to creep from
just under an integer value to just over it, so that the **ceil**
just under an integer value to just over it, so that the `ceil`
function returned a coordinate that was one too large.
> ![](images/i.jpg)