Re: [AD] offscreen sub bitmaps revisited

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Mon, 2010-06-21 at 13:11 -0500, Matthew Leverton wrote:
> On Mon, Jun 21, 2010 at 12:14 PM, Elias Pschernig
> <elias.pschernig@xxxxxxxxxx> wrote:
> > Yes, I think we agreed on it already in that thread (and on other things
> > like moving sub bitmaps and so on :P). For OpenGL it makes no
> > difference, the actual vertex positions will be the same in both of your
> > examples.
> >
> I'd implement it myself, but I'm not familiar enough with the
> display/bitmap system. Previously I changed Allegro to accept negative
> values, and it sort of worked, but there were lots of weird side
> effects.

What kind of side effects?

Basically, for drawing *into* sub-bitmaps, it should work without any
change, since as your example shows, we already support drawing to -32.
You could even have the active transformation shift everything 32 pixels
left. The sub-bitmap offset would do just the same. In fact from
prim_opengl.c:

   /* For sub bitmaps. */
   if(al_is_sub_bitmap(target)) {
      int xofs, yofs;
      al_get_opengl_texture_position(target, &xofs, &yofs);
      glMatrixMode(GL_MODELVIEW);
      glPushMatrix();
      glLoadIdentity();
      glTranslatef(target->xofs, target->yofs, 0);
      glMultMatrixf((float*)al_get_current_transform()->m);
   }

So, a negative offset there will already work completely 100%.

(I wonder what the xofs and yofs variable in that code are for, btw.)

The other possible problem is when not draw into the sub-bitmap but
drawing the bitmap itself. At least with OpenGL, the code looks like
this in ogl_bitmap.c:

static void ogl_draw_bitmap(ALLEGRO_BITMAP *bitmap,
   ALLEGRO_COLOR tint, float x, float y,
   int flags)
{
   ogl_draw_bitmap_region(bitmap, tint, 0, 0, bitmap->w, bitmap->h, x, y, flags);
}

And since al_draw_bitmap_region already support coordinates outside the
bitmap, this again will already work 100%.

So as far as I can see, the patch would be very small - basically just
remove the clipping at the beginning of al_create_sub_bitmap. If it
causes any problems likely those are underlying bugs elsewhere which we
should fix anyway :P

> If it doesn't make it into version 5, can we at least return NULL when
> the origin is outside the parent bitmap? We won't have to be concerned
> with breaking backward compatibility that way.

Yes, sounds good to me. If you want I can remove the check in
al_create_sub_bitmap, test it under X11, and commit... leaving all the
things I break for others to fix worked great in my last commit after
all :)

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>