Re: [cc65] tgi_sprite and friends

From: Oliver Schmidt <ol.sc1web.de>
Date: 2012-11-09 16:35:59
Hi,

>> 1. Recently we moved towards having the TGI kernel handle all clipping
>> resulting i.e. in not drawing a character at all if it doesn't fully
>> fit on the screen. Is the same approach reasonable for bitmaps. Or are
>> partially rendered bitmaps so "necessary" that we need to deviate from
>> the general approach here?
>
> Partially rendered bitmaps are quite useful and do fit nicely into the current
> concept. If a line ends outside the visible screen, the kernel won't decide
> not to draw it at all, but to draw just the visible part. The same is true for
> ellipses, bars and whatever. For strings, clipping occurs on character level,
> simply because the the actual outline of a character isn't known to the
> kernel.
>
> Regarding images, while I would prefer to have the kernel clip them, I don't
> think it is a viable option. Different platforms might need different image
> formats for effective drawing, and the kernel would need knowledge of all of
> them to do clipping.

Hm, with "general approach" above I wasn't referring to clipping in
general from the perspective of the user of the TGI API. Rather I was
referring to having the kernel do all the clipping - as stated in the
first sentence.

But - as we both agree upon - the kernel can't do real clipping for
bitmaps. So the options are from my perspective:

- "Real" clipping done in the driver - this deviates in the sense that
it's the only primitive with clipping done in the driver.

- "All-Or-Nothing" clipping done in the kernel - this deviates in the
sense that it's the only primitive not partially clipped.

So from my perspective it doesn't fit nicely - neither one way or the other...

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri Nov 9 16:37:07 2012

This archive was generated by hypermail 2.1.8 : 2012-11-09 16:37:11 CET