Re: [AD] Re: Line clipping bug found

[Elias Pschernig <elias@xxxxxxxxxx>]

On Thu, 2004-01-08 at 17:14, Doug Eleveld wrote:
> Sorry, I dont know how to 'reply' to keep everything
> in the same'thread...

Your mail program has to add an In-Reply-To: header. Normally it should
do that if you hit the 'Reply' button on a message. If it's not
supported, don't worry about it.

> This new clipping behaviour breaks (at least my) guis
> which rely on drawing a line several times with
> different clipping areas to simulate layered windows. 
> I dont know it it would break other often used
> patterns.
> 
> The problem does not lie with the cohen-southerland
> line clipping.  Its the line-end transformations done
> change the line in the sense that the slope gets
> changed.  Its not the same line anymore.
> 

So, the optimal solution would be to clip the lines in a way so the
gradient doesn't get changed. It surely must be possible.

> My personal approach, which I thought allegro actually
> did, was to use cohen-southerland to clip trivial
> lines, and then use what I call split-bresenham for
> the drawing the lines.  This means once we get a line
> that might have visible pixels, have a bresenham loop
> without a putpixel that runs until we reach the edge
> of the clipping area, and then another bresenham loop
> with a putpixel that runs until the other edge of the
> clipping area gets reached.  This way you can use an
> unclipped putpixel for speed and your only loss is the
> first bresenham loop.  But that has no putpixel in it
> so it should be quite fast.
> 
> I have implemented this method for my own GFX lib (not
> released yet) and it shouldn't be too much to do it
> for allegro too.  Although I am an occasional allegro
> user, and certianly not an allegro expert.

> This approach might be faster than using a clipped
> pixel function in the inner loop, but I am not sure. 
> I was under the impression that (previous WIP versions
> of) allegro actually did this but looking at the
> recent sources maybe I am wrong.

No, previous versions just used do_line (...putpixel), and did clipping
on a per-pixel basis. So your approach would be a better idea. I'm not
sure if the current one is faster for lines not bigger than the screen
dimensions. For something like line(-1000000,0,...) the current one
probably is the fastest though - that's why the change was made.

-- 
Elias Pschernig <elias@xxxxxxxxxx>