Re: [cc65] tgi_sprite and friends

Hi!

On Fri, Nov 09, 2012 at 11:40:53AM +0100, Oliver Schmidt wrote:
> 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.

> 2. I imagine that most targets have a graphics screen buffer layout
> that allows bitmaps to be drawn much faster on some locations than
> others, especially the X offset being a multiple of a certain value
> (usually 8). Am I right in presuming that we don't want to pose such
> limitations on "our function"?

Yes.

> 3. Somewhat related is the size of the bitmap. Is it reasonable to
> pose constraints on the bitmap size saying i.e. the horizonal size
> must be multiple of a certain value (usually 8)?

No, I wouldn't impose such a limit.

> 4. I presume we don't want the function to be obligated to be capable
> of more than an opaque copy - right? Any fancy masking stuff would be
> a proprietary extension - wouldn't it?

While xor would be nice, other drawing primitives don't have it, too. So
anything else beyond a simple "put" shouldn't be a standard operation.

> 5. What about coordinates? Is the coordinate supplied used as upper
> left corner - most likely yes...

I suppose yes.

> 5. What about the TGI cursor. Is it moved by the function?  I'd say
> most likely not...
   
It might be set to the upper left corner before drawing the image. But tgi_bar
doesn't do that either ...

> 6. Do we want to go with the proposed ellipsis parameter (...)? If
> yes: Five fixed parameters seem clear (bitmap pointer, x, y, width,
> height). Any more? If saved as C source file then sp65 delivers beside
> "width" and "height" a "colors" meta information. From the perspective
> of "our function" being a companion to sp65 it might make sense to
> have the colors as fixed parameter - as it's "always avaliable".

We might as well make colours, the size and maybe a format specifier part of a
structure that does also contain the image data. Something like

    struct image_data {
        unsigned char format;
        unsigned char colors;
        unsigned width;
        unsigned height;
        unsigned char data[];
    };

(colors might be unnecessary if part of the format spec).

The advantages are

  - there are less parameters to pass to the function
  - a possible get... function might also use such a structure.

For sp65, this would just be some other output format.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.