Re: [AD] clipping, sub bitmaps

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Sun, Aug 16, 2009 at 10:16 AM, Elias
Pschernig<elias.pschernig@xxxxxxxxxx> wrote:
> I think we can add this, it shouldn't make the code more complicated.
>
> About the moving the origin, I assume you mean something like:
>
> al_change_sub_bitmap_dimensions(bitmap, x, y, w, h)
>
I'm actually speaking of two different approaches to accomplish the
same basic thing. I don't know at all how the bitmaps and graphic
system works, so their implementations may be related (or not).

The first thing is just support for sub-bitmaps whose origin is
located off of the parent bitmap.

> I see how this could be quite useful - and wouldn't require any code
> changes at other places. Are you going to create the patch to add it?
>
No, I don't have the time at the moment to learn how it works.

If nobody is able to do it now (but people agree that it is sensible),
then I think the auto-clipping should be removed and either allow for
buggy behavior or return NULL to indicate failure. That way backward
compatibility won't be a problem.

> Also, since we are changing things like this, myself I often want
> something like:
>
> al_set_bitmap_offset(bitmap, x, y)
>
This is more like what I mean about moving the origin. If you combine
that with clipping, then you have (imo) more natural sub bitmaps.
(Creating a sub-bitmap sounds like there's a lot of overhead.) I've
wanted this feature many times, and right now as I build a GUI. I want
each component to draw itself to (0,0)-(w,h) without having to worry
about where to position itself. Passing x,y offsets is tedious. So I'd
like to be able to do this:

al_set_target_bitmap(bitmap);
al_set_bitmap_origin(32, 32);
al_set_clipping_rectangle(32,32, 100,100);

// inside some function:
al_draw_rectangle(0,0,99,99, black, 1);

First, I'm moving the origin based on the top, left corner of the
target bitmap. So future drawing operations will be made to x+32,
y+32.

Next, I set the clipping rectangle. As written above, the clipping is
assumed to be relative to the top-left of the bitmap, but it probably
would be more consistent to make it relative to the current origin.

So now the function doesn't have to know to what or where it is
drawing. It can assume it is always drawing based off of (0,0). Thus
the target bitmap could be anything ... a real bitmap (double
buffering), a sub bitmap (drawing to the parent) or even directly to
the back buffer (which is what I would want to do with OpenGL on my
laptop).

--
Matthew Leverton