We’re still not ready for assembly, though; what we need is a new perspective that lends itself to vastly better performance in C++. The Life program in the next section is three to seven times faster than Listing 17.4—and it’s still in C++.
How is this possible? Here are some hints:
--
-
- • After a few dozen generations, most of the cellmap consists of cells in the off state.
-
- • There are many possible cellmap representations other than one bit-per-pixel. -
- • Cells change state relatively infrequently. -
- • There are many possible cellmap representations other than one bit-per-pixel. -
-
+
- After a few dozen generations, most of the cellmap consists of cells in the off state. +
- There are many possible cellmap representations other than one bit-per-pixel. +
- Cells change state relatively infrequently. +
Bringing In the Right Brain
In the previous section, we saw how a C++ program could be sped up about eight times simply by rearranging the data and code in straightforward ways. Now we’re going to see how right-brain non-linear optimization can speed things up by another four times—and make the code simpler.
Now that’s Zen code optimization.
diff --git a/17-08.html b/17-08.html index f072c1a..a07036d 100644 --- a/17-08.html +++ b/17-08.html @@ -47,14 +47,14 @@The Challenge That Ate My Life
The most recent optimization challenge I laid my community of readers was to write the fastest possible Game of Life generation engine. By “engine” I meant that I didn’t care about time spent in input or output, only time consumed by the call to next-generation. The time spent updating the cellmap was what I wanted people to concentrate on.
Here are the rules I laid down for the challenge:
--
-
- • Readers could modify any code in Listing 17.5, except the main loop, as well as change the cell map representation any way they liked. However, the code had to produce exactly the same output as Listing 17.5 under all circumstances in order to be eligible to win.
-
- • Engine code had to be less than 400 lines long in total, excluding the video-related code shown in Listing 17.2. -
- • Submissions had to compile/assemble with Borland C++ (in either C++ or C mode, as desired) and/or TASM. -
- • All submissions had to handle cellmaps at least 200x200 in size. -
- • Assembly language could of course be used to speed up any part of the program. C rather than C++ was legal as well, so long as entered implementations produced the same results as Listing 17.5 and 17.2 together and were less than 400 lines long. -
- • All entries would be timed on the same 33 MHz 486 with a 256K external cache. -
- • Engine code had to be less than 400 lines long in total, excluding the video-related code shown in Listing 17.2. -
-
+
- Readers could modify any code in Listing 17.5, except the main loop, as well as change the cell map representation any way they liked. However, the code had to produce exactly the same output as Listing 17.5 under all circumstances in order to be eligible to win. +
- Engine code had to be less than 400 lines long in total, excluding the video-related code shown in Listing 17.2. +
- Submissions had to compile/assemble with Borland C++ (in either C++ or C mode, as desired) and/or TASM. +
- All submissions had to handle cellmaps at least 200x200 in size. +
- Assembly language could of course be used to speed up any part of the program. C rather than C++ was legal as well, so long as entered implementations produced the same results as Listing 17.5 and 17.2 together and were less than 400 lines long. +
- All entries would be timed on the same 33 MHz 486 with a 256K external cache. +
That was the challenge I put to the readers. Little did I realize the challenge it would lay on me: Entries poured in from the four corners of the globe. Some were plain, some were brilliant, some were, well, berserk. Many didn’t even work. But all had to be gone through, examined for adherence to the rules, read, compiled, linked, run, and judged. I learned a lot—about a lot of things, not the least of which was the process (or maybe the wisdom) of laying down challenges to readers.
Who won? What did I learn? To find out, read on.
How Do You Fit Polygons Together?
How, then, do you fit polygons together? Very carefully. First, the line-tracing algorithm must be adjusted so that it selects only those pixels that are truly inside the polygon. This basically requires shifting a standard line-drawing algorithm horizontally by one half-pixel toward the polygon’s interior. That leaves the issue of how to handle points that are exactly on the boundary, and points that lie at vertices, so that those points are drawn once and only once. To deal with that, we’re going to adopt the following rules:
--
-
- • Points located exactly on nonhorizontal edges are drawn only if the interior of the polygon is directly to the right (left edges are drawn, right edges aren’t).
-
-
Figure 38.3 The adjacent polygons problem. -- • Points located exactly on horizontal edges are drawn only if the interior of the polygon is directly below them (horizontal top edges are drawn, horizontal bottom edges aren’t). -
- • A vertex is drawn only if all lines ending at that point meet the above conditions (no right or bottom edges end at that point). -
- • Points located exactly on horizontal edges are drawn only if the interior of the polygon is directly below them (horizontal top edges are drawn, horizontal bottom edges aren’t). -
-
+
-
+ Points located exactly on nonhorizontal edges are drawn only if the interior of the polygon is directly to the right (left edges are drawn, right edges aren’t).
+
+
Figure 38.3 The adjacent polygons problem.
+ - Points located exactly on horizontal edges are drawn only if the interior of the polygon is directly below them (horizontal top edges are drawn, horizontal bottom edges aren’t). +
- A vertex is drawn only if all lines ending at that point meet the above conditions (no right or bottom edges end at that point). +
All edges of a polygon except those that are flat tops or flat bottoms will be considered either right edges or left edges, regardless of slope. The left edge is the one that starts with the leftmost line down from the top of the polygon.
These rules ensure that no pixel is drawn more than once when adjacent polygons are filled, and that if polygons cover the full 360-degree range around a pixel, then that pixel will be drawn once and only once—just what we need in order to be able to fit filled polygons together seamlessly.
diff --git a/39-01.html b/39-01.html index 68f7049..89c2e9c 100644 --- a/39-01.html +++ b/39-01.html @@ -51,11 +51,11 @@In addressing the topic of filling convex polygons in the previous 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.
Our original polygon filling code involved three major tasks, each performed by a separate function:
--
-
- • Tracing each polygon edge to generate a coordinate list (performed by the function ScanEdge);
-
- • Drawing the scanned-out horizontal lines that constitute the filled polygon (DrawHorizontalLineList ); and -
- • Characterizing the polygon and coordinating the tracing and drawing (FillConvexPolygon ). -
- • Drawing the scanned-out horizontal lines that constitute the filled polygon (DrawHorizontalLineList ); and -
-
+
- Tracing each polygon edge to generate a coordinate list (performed by the function ScanEdge); +
- Drawing the scanned-out horizontal lines that constitute the filled polygon (DrawHorizontalLineList ); and +
- Characterizing the polygon and coordinating the tracing and drawing (FillConvexPolygon ). +
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 minuscule), so we have our choice of where to begin optimizing.
Fast Drawing
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 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.
diff --git a/52-01.html b/52-01.html index 609a03c..c934cfb 100644 --- a/52-01.html +++ b/52-01.html @@ -48,13 +48,13 @@This Chapter’s Demo Program
Three-dimensional animation is a complicated business, and it takes an astonishing amount of functionality just to get off the launching pad: page flipping, polygon filling, clipping, transformations, list management, and so forth. I’ve been building toward a critical mass of animation functionality over the course of this book, and this chapter’s code builds on the code from no fewer than five previous chapters. The code that’s required in order to link this chapter’s animation demo program is the following:
--
-
- • Listing 50.1 from Chapter 50 (draw clipped line list);
-
- • Listings 47.1 and 47.6 from Chapter 47 (Mode X mode set, rectangle fill); -
- • Listing 49.6 from Chapter 49; -
- • Listing 39.4 from Chapter 39 (polygon edge scan); and -
- • The FillConvexPolygon( ) function from Listing 38.1 from Chapter 38. Note that the struct keywords in FillConvexPolygon( ) must be removed to reflect the switch to typedefs in the animation header file. -
- • Listings 47.1 and 47.6 from Chapter 47 (Mode X mode set, rectangle fill); -
-
+
- Listing 50.1 from Chapter 50 (draw clipped line list); +
- Listings 47.1 and 47.6 from Chapter 47 (Mode X mode set, rectangle fill); +
- Listing 49.6 from Chapter 49; +
- Listing 39.4 from Chapter 39 (polygon edge scan); and +
- The FillConvexPolygon( ) function from Listing 38.1 from Chapter 38. Note that the struct keywords in FillConvexPolygon( ) must be removed to reflect the switch to typedefs in the animation header file. +
As always, all required files are in this chapter’s subdirectory on the CD-ROM.
The Rendering Pipeline
Conceptually rendering from a BSP tree really is that simple, but the implementation is a bit more complicated. The full rendering pipeline, as coordinated by UpdateWorld(), is this:
--
-
- • Update the current location.
-
- • Transform all wall endpoints into viewspace (the world as seen from the current location with the current viewing angle). -
- • Clip all walls to the view pyramid. -
- • Project wall vertices to screen coordinates. -
- • Walk the walls back to front, and for each wall that lies at least partially in the view pyramid, perform backface culling (skip walls facing away from the viewer), and draw the wall if it’s not culled. -
- • Transform all wall endpoints into viewspace (the world as seen from the current location with the current viewing angle). -
-
+
- Update the current location. +
- Transform all wall endpoints into viewspace (the world as seen from the current location with the current viewing angle). +
- Clip all walls to the view pyramid. +
- Project wall vertices to screen coordinates. +
- Walk the walls back to front, and for each wall that lies at least partially in the view pyramid, perform backface culling (skip walls facing away from the viewer), and draw the wall if it’s not culled. +
Next, we’ll look at each part of the pipeline more closely. The pipeline is too complex for me to be able to discuss each part in complete detail. Some sources for further reading are Computer Graphics, by Foley and van Dam (ISBN 0-201-12110-7), and the DDJ Essential Books on Graphics Programming CD.
Moving the Viewer
The sample BSP program performs first-person rendering; that is, it renders the world as seen from your eyes as you move about. The rate of movement is controlled by key-handling code that’s not shown in Listing 62.1; however, the variables set by the key-handling code are used in UpdateViewPos() to bring the current location up to date.