🚀 go-pugleaf

In article <Bz9Fr7.5uy@phage.cshl.org> boutell@isis.cshl.org (Tom Boutell) writes:
>Well, I now suspect the problem is that the clipping support can only be
>used for bitmaps (specifically the "clipped bitmaps" set of primitives).
>I also infer from this it probably can't be used for compiled bitmaps.
>
>Decent clipping is important to getting the look of this game right,
>but line-drawing, even with the speed of this library and the simplicity
>of the images, was proving too expensive a technique anyway, so I'll
>probably bite the bullet and move to bitmaps. Hope clipping works for
>compiled 'maps, but even if it doesn't I suppose I can use the
>uncompiled 'maps when I know I'm in an edge situation this is probably
>the best approach.

  I *really* doubt it works for compiled bitmaps - how do you clip code? :)
Maybe there should be a new type of compiled bitmap that does clipping
automatically, but I bet that wouldn't have much of a speed advantage over
regular bitmaps - and they'd be about 8 times as large. 
  Don't give up on lines, though.  They're pretty easy to write a clipping
routine, though it's been a while since I tried.  There are quite a few
books with algorithms for clipping lines in them.  It also looks as if
the XLib line drawing algorithm could be sped a bit, but I'm not sure.

>
>XLIB is still an amazing thing to have around. One pet peeve, though:
>the color and basepage arguments aren't always in a consistent order.
>That gets really annoying when trying to move mentally from one
>function to another.

  Yeah.  That annoys me, too.  But it's a pretty small drawback to the power
of this amazing little package.

							-Kludge