Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

24
58-05.md
View file

@ -48,7 +48,7 @@ language texture mapper. All it took was some help from my friends, a
good, stiff jolt of right-brain thinking, and some solid left-brain
polishing—plus the knowledge that such a speedup was possible. Treat
every optimization task as if John Miles has just written to inform you
that he’s made it faster than your wildest dreams, and you’ll be amazed
that he's made it faster than your wildest dreams, and you'll be amazed
at what you can do!
### Texture Mapping Notes {#Heading8}
@ -68,13 +68,13 @@ as follows:
MOV BL,[ESI] ;cycle 3 U-pipe
ADD EDX,EBP ;cycle 3 V-pipe
However, I don’t see any way to eliminate this last AGI, which happens
However, I don't see any way to eliminate this last AGI, which happens
about half the time; even with it, the Pentium execution time for
Listing 58.4 is 5.5 cycles. That’s 61 nanoseconds—a highly respectable
Listing 58.4 is 5.5 cycles. That's 61 nanoseconds—a highly respectable
16 million texture-mapped pixels per second—on a 90 MHz Pentium.
The type of texture mapping discussed in both this and earlier chapters
doesn’t do perspective correction when mapping textures. Why that is and
doesn't do perspective correction when mapping textures. Why that is and
how to handle perspective correction is a topic for a whole separate
book, but be aware that the textures on some large polygons (not the
polygon edges themselves) drawn with the code in this chapter will
@ -82,22 +82,22 @@ appear to be unnaturally bowed, although small polygons should look
fine.
Finally, we never did get rid of the last jump in the texture mapper,
yet John Miles claimed no jumps at all. How did he do it? I’m not sure,
but I’d guess that he used a two-entry look-up table, based on the Y
yet John Miles claimed no jumps at all. How did he do it? I'm not sure,
but I'd guess that he used a two-entry look-up table, based on the Y
carry, to decide how much to advance the source pointer in Y. However, I
couldn’t come up with any implementation of this approach that didn’t
couldn't come up with any implementation of this approach that didn't
take 0.5 to 1 cycle more than the test-and-jump approach, so either I
didn’t come up with an adequately efficient implementation of the table,
didn't come up with an adequately efficient implementation of the table,
John saved a cycle somewhere else, or perhaps John implemented his code
in a 32-bit segment, but used the less-efficient table in his fervor to
get rid of the final jump. The knowledge that I apparently came up with
a different solution than John highlights that the technical aspects of
John’s implementation were, in truth, totally irrelevant to my
optimization efforts; the only actual effect John’s code had on me was
John's implementation were, in truth, totally irrelevant to my
optimization efforts; the only actual effect John's code had on me was
to make me *believe* a texture mapper could run that fast.
Believe it! And while you’re at it, give both halves of your brain equal
time—and watch out for aliens in short skirts, 60’s bouffant hairdos,
Believe it! And while you're at it, give both halves of your brain equal
time—and watch out for aliens in short skirts, 60's bouffant hairdos,
and an undue interest in either half.
------------------------ --------------------------------- --------------------