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

20
40-04.md
View file

@ -37,7 +37,7 @@ connect to its endpoints.
#### Performance Considerations {#Heading7}
How fast is Listing 40.1? When drawing triangles on a 20-MHz 386, it’s
How fast is Listing 40.1? When drawing triangles on a 20-MHz 386, it's
less than one-fifth the speed of the fast convex polygon fill code.
However, most of that time is spent drawing individual pixels; when
Listing 40.2 is replaced with the fast assembly line segment drawing
@ -46,10 +46,10 @@ about half as fast as the fast convex fill code. Even after conversion
to assembly in Listing 40.5, **DrawHorizontalLineSeg** still takes more
than half of the total execution time, and the remaining time is spread
out fairly evenly over the various subroutines in Listing 40.1.
Consequently, there’s no single place in which it’s possible to greatly
improve performance, and the maximum additional improvement that’s
Consequently, there's no single place in which it's possible to greatly
improve performance, and the maximum additional improvement that's
possible looks to be a good deal less than two times; for that reason,
and because of space limitations, I’m not going to convert the rest of
and because of space limitations, I'm not going to convert the rest of
the code to assembly. However, when filling a polygon with a great many
edges, and especially one with a great many active edges at one time,
relatively more time would be spent traversing the linked lists. In such
@ -60,7 +60,7 @@ list processing) could pay off reasonably well.
; Draws all pixels in the horizontal line segment passed in, from
; (LeftX,Y) to (RightX,Y), in the specified color in mode 13h, the
; VGA’s 320x200 256-color mode. No drawing will take place if
; VGA's 320x200 256-color mode. No drawing will take place if
; LeftX > RightX. Tested with TASM
; C near-callable as:
; void DrawHorizontalLineSeg(Y, LeftX, RightX, Color);
@ -81,9 +81,9 @@ list processing) could pay off reasonably well.
public _DrawHorizontalLineSeg
align 2
_DrawHorizontalLineSeg proc
push bp ;preserve caller’s stack frame
push bp ;preserve caller's stack frame
mov bp,sp ;point to our stack frame
push di ;preserve caller’s register variable
push di ;preserve caller's register variable
cld ;make string instructions inc pointers
mov ax,SCREEN_SEGMENT
mov es,ax ;point ES to display memory
@ -102,8 +102,8 @@ list processing) could pay off reasonably well.
adc cx,cx
rep stosb ;draw the odd byte, if any
DrawDone:
pop di ;restore caller’s register variable
pop bp ;restore caller’s stack frame
pop di ;restore caller's register variable
pop bp ;restore caller's stack frame
ret
_DrawHorizontalLineSeg endp
end
@ -112,7 +112,7 @@ The algorithm used to X-sort the AET is an interesting performance
consideration. Listing 40.1 uses a bubble sort, usually a poor choice
for performance. However, bubble sorts perform well when the data are
already almost sorted, and because of the X coherence of edges from one
scan line to the next, that’s generally the case with the AET. An
scan line to the next, that's generally the case with the AET. An
insertion sort might be somewhat faster, depending on the state of the
AET when any particular sort occurs, but a bubble sort will generally do
just fine.