Remove extra heading ids and aligns
This commit is contained in:
James Gregory
parent
e19ac9ffe9
commit
f44993cec5
5 changed files with 16 additions and 16 deletions
|
|
@ -195,7 +195,7 @@ to the memory architectures, the 8-bit bus cycle-eater is replaced by a
|
|||
new form of the wait state cycle-eater: wait states on accesses to
|
||||
normal system memory.
|
||||
|
||||
#### System Wait States {#Heading6 align="center"}
|
||||
#### System Wait States
|
||||
|
||||
The 286 and 386 were designed to lose relatively little performance to
|
||||
the prefetch queue cycle-eater...*when used with zero-wait-state
|
||||
|
|
@ -342,7 +342,7 @@ Of course, those are exactly the rules that apply to 8088 optimization
|
|||
as well. Isn't it convenient that the same general rules apply across
|
||||
the board?
|
||||
|
||||
#### Data Alignment {#Heading7 align="center"}
|
||||
#### Data Alignment
|
||||
|
||||
Thanks to its 16-bit bus, the 286 can access word-sized memory variables
|
||||
just as fast as byte-sized variables. There's a catch, however: That's
|
||||
|
|
@ -534,7 +534,7 @@ that consistently provides a reasonable return for bytes and effort
|
|||
expended, although sometimes it also pays to word-align tight
|
||||
time-critical loops.
|
||||
|
||||
#### Alignment and the 386 {#Heading9 align="center"}
|
||||
#### Alignment and the 386
|
||||
|
||||
So far we've only discussed alignment as it pertains to the 286. What,
|
||||
you may well ask, of the 386?
|
||||
|
|
@ -555,7 +555,7 @@ performance would dictate doubleword alignment of subroutines, that
|
|||
takes 3 bytes, a high price to pay for an optimization that improves
|
||||
performance *only* on the post 286 processors.
|
||||
|
||||
#### Alignment and the Stack {#Heading10 align="center"}
|
||||
#### Alignment and the Stack
|
||||
|
||||
One side-effect of the data alignment cycle-eater of the 286 and 386 is
|
||||
that you should *never* allow the stack pointer to become odd. (You can
|
||||
|
|
@ -580,7 +580,7 @@ slowly than it normally would. The same goes for decrementing twice; use
|
|||
> 
|
||||
> Keep the stack pointer aligned at all times.
|
||||
|
||||
#### The DRAM Refresh Cycle-Eater: Still an Act of God {#Heading11 align="center"}
|
||||
#### The DRAM Refresh Cycle-Eater: Still an Act of God
|
||||
|
||||
The DRAM refresh cycle-eater is the cycle-eater that's least changed
|
||||
from its 8088 form on the 286 and 386. In the AT, DRAM refresh uses a
|
||||
|
|
@ -606,7 +606,7 @@ an act of God, and there's not a blessed thing you can do about it.
|
|||
Happily, the internal caches of the 486 and Pentium make DRAM refresh
|
||||
largely a performance non-issue on those processors.
|
||||
|
||||
#### The Display Adapter Cycle-Eater {#Heading12 align="center"}
|
||||
#### The Display Adapter Cycle-Eater
|
||||
|
||||
Finally we come to the last of the cycle-eaters, the display adapter
|
||||
cycle-eater. There are two ways of looking at this cycle-eater on
|
||||
|
|
@ -782,7 +782,7 @@ unless you play some unorthodox tricks with the segment registers.
|
|||
> as Windows, so I'd recommend against using them. If you want 4-gigabyte
|
||||
> segments, use a 32-bit environment such as Win32.
|
||||
|
||||
#### Optimization Rules: The More Things Change... {#Heading15 align="center"}
|
||||
#### Optimization Rules: The More Things Change...
|
||||
|
||||
Let's see what we've learned about 286/386 optimization. Mostly what
|
||||
we've learned is that our familiar PC cycle-eaters still apply, although
|
||||
|
|
@ -805,7 +805,7 @@ that's the data alignment cycle-eater. From the data alignment
|
|||
cycle-eater we get a new rule: Word-align your word-sized variables, and
|
||||
start your subroutines at even addresses.
|
||||
|
||||
#### Detailed Optimization {#Heading16 align="center"}
|
||||
#### Detailed Optimization
|
||||
|
||||
While the major 8088 optimization rules hold true on computers built
|
||||
around the 286 and 386, many of the instruction-specific optimizations
|
||||
|
|
|
|||
|
|
@ -712,7 +712,7 @@ at the maximum possible rate of once per frame even on a 1985-vintage
|
|||
8-MHz AT. In this case, faster performance would result only in a longer
|
||||
wait for the page to flip.
|
||||
|
||||
#### Write Mode 3 {#Heading5 align="center"}
|
||||
#### Write Mode 3
|
||||
|
||||
It's possible to update the bitmap very efficiently on the VGA, because
|
||||
the VGA can draw up to 8 pixels at once, and because the VGA provides a
|
||||
|
|
@ -819,7 +819,7 @@ coincidentally, the sample application draws only single-color objects
|
|||
within the animation area; this allows write mode 3 to be used for all
|
||||
drawing, in keeping with our desire for speedy screen updates.
|
||||
|
||||
#### Drawing Text {#Heading6 align="center"}
|
||||
#### Drawing Text
|
||||
|
||||
We'll need text in the sample application; is that also a good use for
|
||||
write mode 3? Sometimes it is, but not in this particular case.
|
||||
|
|
@ -870,7 +870,7 @@ are 10 ways to do it, each with unique strengths and weaknesses. Your
|
|||
mission, should you decide to accept it, is to figure out which one is
|
||||
best for your particular application.
|
||||
|
||||
#### Page Flipping {#Heading7 align="center"}
|
||||
#### Page Flipping
|
||||
|
||||
Now that we know how to update the screen reasonably quickly, it's time
|
||||
to get on to the fun stuff. Page flipping answers the second requirement
|
||||
|
|
@ -913,7 +913,7 @@ so on *ad infinitum.*
|
|||
|
||||
|
||||
|
||||
#### Knowing When to Flip {#Heading8 align="center"}
|
||||
#### Knowing When to Flip
|
||||
|
||||
There's a hitch, though, and that hitch is knowing exactly when it is
|
||||
that the page has flipped. The page doesn't flip the instant that you
|
||||
|
|
|
|||
|
|
@ -671,7 +671,7 @@ logic to produce more interesting and less predictable
|
|||
internal-animation effects, such as jumping, ducking, running, and the
|
||||
like.
|
||||
|
||||
#### Dirty-Rectangle Management {#Heading6 align="center"}
|
||||
#### Dirty-Rectangle Management
|
||||
|
||||
As mentioned above, dirty-rectangle animation makes it possible to
|
||||
access display memory a minimum number of times. The previous chapter's
|
||||
|
|
|
|||
|
|
@ -965,7 +965,7 @@ There are other sorts of shading components, including transparency and
|
|||
atmospheric effects, but the ambient and diffuse-shading components are
|
||||
all we're going to deal with in X-Sharp.
|
||||
|
||||
#### Ambient Shading {#Heading5 align="center"}
|
||||
#### Ambient Shading
|
||||
|
||||
The basic model for both ambient and diffuse shading is a simple one.
|
||||
Each surface has a reflectivity between 0 and 1, where 0 means all light
|
||||
|
|
@ -988,7 +988,7 @@ available palette of colors; I'll do that in the next chapter. Ambient
|
|||
shading isn't the whole shading picture, though. In fact, scenes tend to
|
||||
look pretty bland without diffuse shading.
|
||||
|
||||
#### Diffuse Shading {#Heading6 align="center"}
|
||||
#### Diffuse Shading
|
||||
|
||||
Diffuse shading is more complicated than ambient shading, because the
|
||||
effective intensity of directed light falling on a surface depends on
|
||||
|
|
|
|||
|
|
@ -265,7 +265,7 @@ even human figures). Just map the desired texture onto the underlying
|
|||
polygonal framework of an object, and let double-DDA texture mapping do
|
||||
the rest.
|
||||
|
||||
#### Fast Texture Mapping {#Heading7 align="center"}
|
||||
#### Fast Texture Mapping
|
||||
|
||||
Of course, there's a problem with mapping a texture across many
|
||||
polygons: Texture mapping is slow. If you run DEMO1 and move the ball up
|
||||
|
|
|
|||
Loading…
Reference in a new issue