Normal quotes

70-09.md

@@ -9,7 +9,7 @@ Doom, a welcome change from the claustrophobic feel of Quake.
 
 Another likely change in Quake 2 is a shift from interpreted Quake-C
 code for game logic to compiled DLLs. Part of the incentive here is
-performance—interpretation isn’t cheap—and part is debugging, because
+performance—interpretation isn't cheap—and part is debugging, because
 the standard debugger can be used with DLLs. The drawback, of course, is
 portability; Quake-C program files are completely portable to any
 platform Quake runs on, with no modification or recompilation, but DLLs
@@ -17,10 +17,10 @@ compiled for Win32 require a real porting effort to run anywhere else.
 Our thinking here is that there are almost no non-console platforms
 other than the PC that matter that much anymore, and for those few that
 do (notably the Mac and Linux), the DLLs can be ported along with the
-core engine code. It just doesn’t make sense for easy portability to
+core engine code. It just doesn't make sense for easy portability to
 tiny markets to impose a significant development and performance cost on
 the one huge market. Consoles will always require serious porting effort
-anyway, so going to Win32-specific DLLs for the PC version won’t make
+anyway, so going to Win32-specific DLLs for the PC version won't make
 much difference in the ease of doing console ports.
 
 Finally, Internet support will improve in Quake 2. Some of the
@@ -32,7 +32,7 @@ letting the browser take care of most of the UI makes it possible to
 eliminate menuing and such from the Quake 2 engine. Think of being able
 to browse hundreds of Quake servers from a single Web page (much as you
 can today with QSpy, but with the advantage of a standard, familiar
-interface and easy extensibility), and I think you’ll see why John
+interface and easy extensibility), and I think you'll see why John
 considers this the game interface of the future.
 
 By the way, Quake 2 is currently being developed as a native Win32 app
@@ -40,8 +40,8 @@ only; no DOS version is planned.
 
 ### Looking Forward {#Heading21}
 
-In my address to the Computer Game Developer’s Conference in 1996, I
-said that it wasn’t a bad time to start up a game company aimed at
+In my address to the Computer Game Developer's Conference in 1996, I
+said that it wasn't a bad time to start up a game company aimed at
 hardware-only rasterization, and trying to make a game that leapfrogged
 the competition. It looks like I was probably a year early, because
 hardware took longer to ship than I expected, although there was a good
@@ -49,37 +49,37 @@ living to be made writing games that hardware vendors could bundle with
 their boards. Now, though, it clearly is time. By Christmas 1997, there
 will be several million fast accelerators out there, and by Christmas
 1998, there will be tens of millions. At the same time, vastly more
-people are getting access to the Internet, and it’s from the convergence
+people are getting access to the Internet, and it's from the convergence
 of these two trends that I think the technology for the next generation
 of breakthrough real-time games will emerge.
 
-John is already working on id’s next graphics engine, code-named Trinity
+John is already working on id's next graphics engine, code-named Trinity
 and targeted around Christmas of 1998. Trinity is not only a
 hardware-only engine, its baseline system is a Pentium Pro 200-plus with
 MMX, 32 MB, and an accelerator capable of at least 50 megapixels and 300
 K triangles per second with alpha blending and z-buffering. The goals of
-Trinity are quite different from those of Quake. Quake’s primary
+Trinity are quite different from those of Quake. Quake's primary
 technical goals were to do high-quality, well-lit, complex indoor scenes
 with 6 degrees of freedom, and to support client-server Internet play.
-That was a good start, but only that. Trinity’s goals are to have much
+That was a good start, but only that. Trinity's goals are to have much
 less-constrained, better-connected worlds than Quake. Imagine seeing
 through open landscape from one server to the next, and seeing the
-action on adjacent servers in detail, in real time, and you’ll have an
+action on adjacent servers in detail, in real time, and you'll have an
 idea of where things are heading in the near future.
 
 A huge graphics challenge for the next generation of games is level of
-detail (LOD) management. If we’re to have larger, more open worlds,
+detail (LOD) management. If we're to have larger, more open worlds,
 there will inevitably be more geometry visible at one time. At the same
-time, the push for greater detail that’s been in progress for the past
+time, the push for greater detail that's been in progress for the past
 four years or so will continue; people will start expecting to see real
 cracks and bumps when they get close to a wall, not just a picture of
 cracks and bumps painted on a flat wall. Without LOD, these two trends
-are in direct opposition; there’s no way you can make the world larger
+are in direct opposition; there's no way you can make the world larger
 and make all its surfaces more detailed at the same time, without
 bringing the renderer to its knees.
 
 The solution is to draw nearer surfaces with more detail than farther
-surfaces. In itself, that’s not so hard, but doing it without popping
+surfaces. In itself, that's not so hard, but doing it without popping
 and snapping being visible as you move about is quite a challenge. John
 has implemented fractal landscapes with constantly adjustable level of
 detail, and has made it so new vertices appear as needed and gradually
@@ -97,7 +97,7 @@ more detailed when viewed up close, so LOD for moving polygon models
 will definitely be needed.
 
 One interesting side effect of morphing vertices as part of LOD is that
-Gouraud shading doesn’t work very well with this approach. The problem
+Gouraud shading doesn't work very well with this approach. The problem
 is that adding a new vertex causes a major shift in Gouraud shading,
 which is, after all, based on lighting at vertices. Consequently,
 two-pass alpha lighting and surface caching seem to be much better
@@ -107,12 +107,12 @@ Some people worry that the widespread use of hardware acceleration will
 mean that 3-D programs will all look the same, and that there will no
 longer be much challenge in 3-D programming. I hope that this brief
 discussion of the tightly interconnected, highly detailed worlds toward
-which we’re rapidly heading will help you realize that both the
+which we're rapidly heading will help you realize that both the
 challenge and the potential of 3-D programming are in fact greater than
-they’ve ever been. The trick is that rather than getting stuck in the
-rut of established techniques, you must constantly strive to “do better
-with less, in a different way”; keep learning and changing and trying
-new approaches—and working your rear end off—and odds are you’ll be part
+they've ever been. The trick is that rather than getting stuck in the
+rut of established techniques, you must constantly strive to "do better
+with less, in a different way"; keep learning and changing and trying
+new approaches—and working your rear end off—and odds are you'll be part
 of the wave of the future.
 
   ------------------------ --------------------------------- -------------------------