Normal quotes

43-06.md

@@ -9,16 +9,16 @@ top and bottom parts of the image, as the CRT controller scans out first
 unchanged bytes and then changed bytes. Basically, shear will
 occasionally occur unless the CPU and CRT proceed at exactly the same
 rate, which is most unlikely. Shear is more noticeable when there are
-fewer but larger images, since it’s more apparent when a larger screen
-area is sheared, and because it’s easier to spot one out of three large
+fewer but larger images, since it's more apparent when a larger screen
+area is sheared, and because it's easier to spot one out of three large
 images momentarily shearing than one out of twenty small images.
 
-Image shear isn’t terrible—I’ve written and sold several games in which
-images occasionally shear, and I’ve never heard anyone complain—but
+Image shear isn't terrible—I've written and sold several games in which
+images occasionally shear, and I've never heard anyone complain—but
 neither is it ideal. One solution is page flipping, in which drawing is
 done to a non-displayed page of display memory while another page of
 display memory is shown on the screen. (We saw page flipping back in
-Chapter 23, we’ll see it again in the next chapter, and we’ll use it
+Chapter 23, we'll see it again in the next chapter, and we'll use it
 heavily starting in Chapter 47.) When the drawing is finished, the
 newly-drawn part of display memory is made the displayed page, so that
 the new screen becomes visible all at once, with no shearing or flicker.
@@ -33,18 +33,18 @@ few drawbacks to page flipping, however.
 
 Page flipping requires two display memory buffers, one to draw in and
 one to display at any given time. Unfortunately, in mode 12H there just
-isn’t enough memory for two buffers, so page flipping is not an option
+isn't enough memory for two buffers, so page flipping is not an option
 in that mode.
 
 Also, page flipping requires that you keep the contents of both buffers
 up to date, which can require a good deal of extra drawing.
 
-Finally, page flipping requires that you wait until you’re sure the page
+Finally, page flipping requires that you wait until you're sure the page
 has flipped before you start drawing to the other page. Otherwise, you
-could end up modifying a page while it’s still being displayed,
+could end up modifying a page while it's still being displayed,
 defeating the whole purpose of page flipping. Waiting for pages to flip
-takes time and can slow overall performance significantly. What’s more,
-it’s sometimes difficult to be sure when the page has flipped, since not
+takes time and can slow overall performance significantly. What's more,
+it's sometimes difficult to be sure when the page has flipped, since not
 all VGA clones implement the display adapter status bits and page flip
 timing identically.
 
@@ -57,11 +57,11 @@ to implement and perhaps a bit less reliable on some computers.
 
 Bit-plane animation is neat stuff. Heck, good animation of *any* sort is
 fun, and the PC is as good a place as any (well, almost any) to make
-people’s jaws drop. (Certainly it’s the place to go if you want to make
-a *lot* of jaws drop.) Don’t let anyone tell you that you can’t do good
+people's jaws drop. (Certainly it's the place to go if you want to make
+a *lot* of jaws drop.) Don't let anyone tell you that you can't do good
 animation on the PC. You can—*if* you stretch your mind to find ways to
 bring the full power of the VGA to bear on your applications. Bit-plane
-animation isn’t for every task; neither are page flipping,
+animation isn't for every task; neither are page flipping,
 exclusive-ORing, pixel panning, or any of the many other animation
 techniques you have available. One or more tricks from that grab-bag
 should give you what you need, though, and the bigger your grab-bag, the