🚀 go-pugleaf

In article <cf=bNLK00Vp=MOqlUB@andrew.cmu.edu> Court Demas <court+@CMU.EDU> writes:
> [quoted article deleted ....]
>
>I actually fooled around with this a bit, and I think it might be
>possible.  At least horizontal clipping seems fairly easy - you have a
>set on instructions n-bytes long broken into sections of each scanline. 
>Just compute the top line and jump into the correct section, and then
>check at the end of each line to see if you should cut out (could get a
>little hairy though if you wanna do it really fast (self-modifying code,
>blech)).  Clipping vertically would take a bit more work but it's
>basically the same concept.  Has anybody else played with this?
>
I've had some thoughts on this too.  Clipping could be done either horizontally
or vertically since compiled bitmaps (at least ones that use stosb instead of 
the more optimized stosw & stosd) need not draw across scanlines thanks to
their structure.  At the end of each line (vertical or horizontal) could be
instructions like "dec cx" followed by "jcxz @@End" where a "ret" was at @@End.
An array is kept as above with the entry points for each line.  When it is 
time to draw the sprite, the entry point for the first line is determined, and
cx is initialized for the number of lines to draw.  Bingo, clipping for
left and right or top and bottom (depending on how the compiled bitmap is 
structured.)  

Now what I haven't figured out is how to clip a compiled bitmap say top and
left or top and right........  Hmmmmm...... this one's probably not possible,
or would slow the code down so much that you'd lose the advantages of 
compiling it.

>
>Maybe implementing the "enhanced" bresenham's (or whatever it's called)
>would make it faster - precomputing the length of the spans and such. 
>Tricky to implement though (I think Abrash wrote something about this).
>

Run slice algorithm in Dr. Dobbs Journal, November and December 1992 issues.
Interesting stuff. 

>-court

Michael Duffy
The man with no .sig