RE: [AD] sub bitmap patch

["Vincent Penquerc'h" <Vincent.Penquerch@xxxxxxxxxx>]

Title: RE: [AD] sub bitmap patch

> 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.

Yes, hence add_clip. set_clip won't do in this case.
And this won't break older code, as older code doing that would crash
already.

> > You just have to pay attention not to draw outside the
> clipping rectangle,
> > as you HAD to do before.
>
> Even with regular drawing routines ?

Regular drawing routines respect the clipping values. Whether or not
they're set to the normal bitmap size or to another one. I was thinking
only of direct access to the *line array.

> > 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.

Hmm, you're right. Strange then, that I have had crash with dodgy
clipping values ...
Well, apologies for saying this wrong thing.

> > 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.

I meant this not knowing that set_clip was doing a safety check against
width and height, and I was not thinking of modifying the drawing
routines, just the fact of adding your idea of "hard" clipping. So
forget it :)

> > 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.

I say that in the context on the current code, which would crash if one
would do the same thing. Oh well, I'm just arguing for the sake of it now,
but I don't mind if you delay it :)

--
Vincent Penquerc'h