Re: [AD] clipping, sub bitmaps

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Mon, 2009-08-17 at 11:36 +1000, Peter Wang wrote:
> 
> With sub-bitmaps it would be easy to allow you to change the
> sub-bitmap's offset and size.  On the other hand, if you create a
> sub-sub-bitmap then change the parent bitmap's offset, you might expect
> the sub-sub-bitmap to be shifted as well, and that *would* complicate
> things.  The same argument applies to top-level bitmaps and sub-bitmaps.
> 

We do not really have sub-sub-bitmaps right now. If you create a
sub-bitmap, this is what happens:


   if (parent->parent) {
      x += parent->xofs;
      y += parent->yofs;
      parent = parent->parent;
   }

So basically, the parent of a sub bitmap always is a real bitmap.

If we want to change this, we will need a function
"_al_find_bitmap_parent(bitmap)" which traverses all the parents to find
the real one (to be used wherever "bitmap->parent" is used right now).

Anyway, I think we have several different, related but independent
things floating around now:

- Allow negative sub-bitmap offsets and in general sub-bitmaps extending
to outside the parent.

- al_change_sub_bitmap(bitmap, x, y, w, h)

Very simple to implement.

- Allow sub-sub-...-bitmaps

The traversing function mentioned earlier would keep track of positions,
so a moved bitmap would automatically move all its descendants.

- al_set_bitmap_origin(bitmap, x, y)

This only affects drawing *into* the bitmap and causes everything to be
offset by x, y. (This is unlike the transformation you can set with the
primitives addon, as it is per-bitmap.) It would be the same effect as
drawing into a sub-bitmap with a negative offset - but without the need
to create a sub-bitmap.

- al_set_bitmap_offset(bitmap, x, y)

This only affects drawing the bitmap itself, and will subtract x, y from
the position to draw to (prior to rotation/scaling).


Myself, I think all 5 points make sense.

-- 
Elias Pschernig <elias@xxxxxxxxxx>