Normal quotes

39-01.md

@@ -9,21 +9,21 @@ Chapter 39\
 ### Filling Polygons in a Hurry {#Heading2}
 
 In the previous chapter, we explored the surprisingly intricate process
-of filling convex polygons. Now we’re going to fill them an order of
+of filling convex polygons. Now we're going to fill them an order of
 magnitude or so faster.
 
-Two thoughts may occur to some of you at this point: “Oh, no, he’s not
-going to get into assembly language and device-dependent code, is he?”
-and, “Why bother with polygon filling—or, indeed, any drawing
-primitives—anyway? Isn’t that what GUIs and third-party libraries are
-for?”
+Two thoughts may occur to some of you at this point: "Oh, no, he's not
+going to get into assembly language and device-dependent code, is he?"
+and, "Why bother with polygon filling—or, indeed, any drawing
+primitives—anyway? Isn't that what GUIs and third-party libraries are
+for?"
 
-To which I answer, “Well, yes, I am,” and, “If you have to ask, you’ve
-missed the magic of microcomputer programming.” Actually, both questions
-ask the same thing, and that is: “Why should I, as a programmer, have
-any idea how my program actually works?”
+To which I answer, "Well, yes, I am," and, "If you have to ask, you've
+missed the magic of microcomputer programming." Actually, both questions
+ask the same thing, and that is: "Why should I, as a programmer, have
+any idea how my program actually works?"
 
-Put that way, it sounds a little different, doesn’t it?
+Put that way, it sounds a little different, doesn't it?
 
 GUIs, reusable code, portable code written entirely in high-level
 languages, and object-oriented programming are all the rage now, and
@@ -38,10 +38,10 @@ create quickly and reliably programs that will be easy for new users to
 pick up, so software becomes easier to both produce and learn. This is,
 without question, a Good Thing.
 
-The “black box” approach does not, however, necessarily cause the
+The "black box" approach does not, however, necessarily cause the
 software itself to become faster, smaller, or more innovative; quite the
-opposite, I suspect. I’ll reserve judgement on whether that is a good
-thing or not, but I’ll make a prediction: In the short run, the
+opposite, I suspect. I'll reserve judgement on whether that is a good
+thing or not, but I'll make a prediction: In the short run, the
 aforementioned techniques will lead to noticeably larger, slower
 programs, as programmers understand less and less of what the key parts
 of their programs do and rely increasingly on general-purpose code
@@ -60,13 +60,13 @@ in various ways components written by other people, and will cease to be
 the all-inclusively creative, mindbendingly complex pursuit it is today.
 (Using legally certified black boxes is, by the way, one direction in
 which the patent lawyers are leading us; legal considerations may be the
-final nail in the coffin of homegrown code.) For now, though, it’s still
+final nail in the coffin of homegrown code.) For now, though, it's still
 within your power, as a PC programmer, to understand and even control
 every single thing that happens on a computer if you so desire, to
 realize any vision you may have. Take advantage of this unique window of
 opportunity to create some magic!
 
-Neither does it hurt to understand what’s involved in drawing, say, a
+Neither does it hurt to understand what's involved in drawing, say, a
 filled polygon, even if you are using a GUI. You will better understand
 the performance implications of the available GUI functions, and you
 will be able to fill in any gaps in the functions provided. You may even
@@ -76,13 +76,13 @@ screen; for instance, you can do this under Windows by using the WinG
 library available from Microsoft. You will also be able to understand
 why various quirks exist, and will be able to put them to good use. For
 example, the X Window System follows the polygon drawing rules described
-in the previous chapter (although it’s not obvious from the X Window
-System documentation); if you understood the previous chapter’s
-discussion, you’re in good shape to use polygons under X.
+in the previous chapter (although it's not obvious from the X Window
+System documentation); if you understood the previous chapter's
+discussion, you're in good shape to use polygons under X.
 
 In short, even though doing so runs counter to current trends, it helps
-to understand how things work, especially when they’re very visible
-parts of the software you develop. That said, let’s learn more about
+to understand how things work, especially when they're very visible
+parts of the software you develop. That said, let's learn more about
 filling convex polygons.
 
 ### Fast Convex Polygon Filling {#Heading3}
@@ -92,8 +92,8 @@ chapter, the implementation we came up with met all of our functional
 requirements. In particular, it met stringent rules that guaranteed that
 polygons would never overlap or have gaps at shared edges, an important
 consideration when building polygon-based images. Unfortunately, the
-implementation was also slow as molasses. In this chapter we’ll work up
-polygon-filling code that’s fast enough to be truly usable.
+implementation was also slow as molasses. In this chapter we'll work up
+polygon-filling code that's fast enough to be truly usable.
 
 Our original polygon filling code involved three major tasks, each
 performed by a separate function:
@@ -105,7 +105,7 @@ performed by a separate function:
 -   Characterizing the polygon and coordinating the tracing and drawing
     (**FillConvexPolygon** ).
 
-The amount of time that the previous chapter’s sample program spent in
+The amount of time that the previous chapter's sample program spent in
 each of these areas is shown in Table 39.1. As you can see, half the
 time was spent drawing and the other half was spent tracing the polygon
 edges (the time spent in **FillConvexPolygon** was relatively
@@ -113,30 +113,30 @@ minuscule), so we have our choice of where to begin optimizing.
 
 #### Fast Drawing {#Heading4}
 
-Let’s start with drawing, which is easily sped up. The previous
-chapter’s code used a double-nested loop that called a draw-pixel
-function to plot each pixel in the polygon individually. That’s a
+Let's start with drawing, which is easily sped up. The previous
+chapter's code used a double-nested loop that called a draw-pixel
+function to plot each pixel in the polygon individually. That's a
 ridiculous approach in a graphics mode that offers linearly mapped
-memory, as does VGA mode 13H, the mode in which we’re working. At the
+memory, as does VGA mode 13H, the mode in which we're working. At the
 very least, we could point a far pointer to the left edge of each
 polygon scan line, then draw each pixel in that scan line in quick
 succession, using something along the lines of **\*ScrPtr++ =
 FillColor;** inside a loop.
 
 However, it seems silly to use a loop when the x86 has an instruction,
-**REP STOS**, that’s uniquely suited to filling linear memory buffers.
-There’s no way to use **REP STOS** directly in C code, but it’s a good
+**REP STOS**, that's uniquely suited to filling linear memory buffers.
+There's no way to use **REP STOS** directly in C code, but it's a good
 bet that the **memset** library function uses **REP STOS**, so you could
 greatly enhance performance by using **memset** to draw each scan line
 of the polygon in a single shot. That, however, is easier said than
 done. The **memset** function linked in from the library is tied to the
 memory model in use; in small (which includes Tiny, Small, or Medium)
-data models **memset** accepts only near pointers, so it can’t be used
+data models **memset** accepts only near pointers, so it can't be used
 to access screen memory. Consequently, a large (which includes Compact,
 Large, or Huge) data model must be used to allow **memset** to draw to
 display memory—a clear case of the tail wagging the dog. This is an
 excellent example of why, although it is possible to use C to do
-virtually anything, it’s sometimes much simpler just to use a little
+virtually anything, it's sometimes much simpler just to use a little
 assembly code and be done with it.
 
   ------------------------ --------------------------------- --------------------