Re: [AD] sub bitmap patch

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> I don't believe so, as it will crash as well if you set the clipping
> values to garbage. That is well outlined in the docs. If you mess with
> the clipping values, it's at your own risk.

Ok, but with your patch, passing valid clipping values for a "special"
sub-bitmap (0, 0, bmp->w/2, bmp->h/2 for instance) leads to a SIGSEGV with
any regular drawing routine.

> You just have to pay attention not to draw outside the clipping rectangle,
> as you HAD to do before.

Even with regular drawing routines ?

> And this would have to not be restricted to sub bitmaps: try creating
> a 64x64 (normal) bitmap, make its clipping values to 0, 0, 128, 128,
> and then blit a 128x128 sprite on it. It should crash.

No, set_clip() does the intersection with the actual bitmap rectangle.
That's what I call "hard clipping": each bitmap would get a "hard clipping"
rectangle that can't be modified. For plain bitmaps, it would simply be the
bitmap rectangle, and for sub-bitmaps the intersection of the sub-bitmap
rectangle and its parent's hard clipping rectangle, and so on recursively.

> So you'd have to do that for all bitmaps, and that'll slow down some
> drawing routines.

No drawing routine will be touched, only the bitmap manipulation routines,
set_clip() and the BITMAP structure.

> For many types of bitmap, there are restrictions on direct use.
> That is just another one. And it's a pretty innocuous one, as this
> didn't even work in a consistent way before.

I don't think it's a innocuous one, since you can't even access the first
pixel of the first line ! However, it's of course inevitable.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/