Brian S. Julin writes:
> Marcus wrote:
> >>The problem here is simple - the coordinate system in LibGGI ranges
> >>from (0,0) to (oo,oo). Negative starting coordinates happens to work
> >>when you use software clipping, but with hardware clipping and drawing
> >>the results are undefined.
> >>The reason this behaviour should not be changed is that for lines it
> >>isn't as simple as truncating negative values to zero. I do not
> >>intend to put a full software line-drawer into the matrox sublib
> >>for the sole purpose of supporting broken applications.
>
> Not to be a pain, but purely on principal, I think that either all targets
> should properly deal with negative coordinates, or the types on the
> functions should be changed to unsigned int.
I agree. This would be a largish change to the LibGGI API, and would
break backwards compatibility. I know some of my programs would
break, and would be time-consuming to fix, and that no doubt applies
to a lot of other people too.
> Otherwise, it strikes me that it is the Matrox hardware that is broken, and
> if we're going to be minimalistic for it's sake, we should restrict the
> coordinate system to (0,0) to (virt.x,virt.y) rather than to (oo,oo), so
> that if another card driver comes along for a card that's broken for
> off-screen points as well, we can make it's DrawLine as efficient as it
> can be just like the Matrox's.
Yes, exactly. It would be rather silly to only clip against two sides
of the screen.
Cheers,
__
\/ Andrew Apted <[EMAIL PROTECTED]>
