Re: [AD] clipping line algorithm

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


OK, here's the situation as I see it (scroll down for new suggested solution):

In the best of all worlds, each bitmap would be either "linear", "planar", or "other". The distinction between these types lies in how you can draw single pixels:
 (1) A "linear" bitmap is one where _getpixel()/_putpixel() is possible.
(2) A "planar" bitmap is a mode-X screen, allowing mode-X-like (outportw) access like in draw_scanline_modex() in rotate.c. (3) A bitmap that is "other" can only be read/written through the vtable, that is, with getpixel()/putpixel().

An add-on like AllegroGL needs to define "other" type bitmaps, because _putpixel() does not work, and the direct mode-X-access certainly does not work. But Allegro currently assumes that only (1), (2), but not (3) are possible. In particular rotate.c:_parallelogram_map_standard, gsprite.c:draw_gouraud_sprite and c/cstretch.c:_al_stretch_blit assumes this.


One fix is to add a flag to bmp->id to mark the "other" bitmaps: BMP_ID_NONLINEAR_NONPLANAR. We would need new implementations of a couple of functions:

   int is_linear_bitmap(BITMAP *bmp)
   {
      return (bmp->id & (BMP_ID_PLANAR | BMP_ID_NONLINEAR_NONPLANAR)) ?
             TRUE : FALSE
   }

   int is_planar_bitmap(BITMAP *bmp)
   {
      return (bmp->id & BMP_ID_PLANAR) ? TRUE : FALSE;
   }

And rotate.c, gsprite.c and c/cstretch.c need modifications to take care of case (3).

It is of course invalid for a bitmap to have both BMP_ID_PLANAR and BMP_ID_NONLINEAR_NONPLANAR flags set at the same time. Only add-ons like AllegroGL need to set the BMP_ID_NONLINEAR_NONPLANAR flag.

I think that with this fix, any piece of code that currently assumes no bitmaps are of type (3) will still work fine with type (1) and (2) bitmaps. We can easily fix Allegro to allow case (3). Also, this solution does not imply any problems with flags saved on disk. What do you think?

Sven

Eric Botcazou wrote:
OK, after looking up the definition of
is_linear_bitmap() in include/allegro/inline/gfx.inl, I think I
understand the problem: any bitmaps that Allegro knows about are either
linear or planar, so there is only one flag for bmp->id that says which
of them holds (the flag is called BMP_ID_PLANAR).

This semantics sounds very DOS-ish. Moreover, the "linear" qualifier is used in a broad acceptation since banked SVGA modes are "linear" for Allegro. It really means "which can be accessed linearly within each scanline".

I commited the attached patch to clarify the meaning of "linear".

But an add-on may provide a bitmap type that is not planar (so it would not
be correct to set the flag) but does not support _putpixel (so it would not
be correct for is_linear_bitmap() to return true).

Yes, I think this could be the case for AllegroGL.

Bob, does the screen bitmap of AllegroGL support linear access within each scanline? If no, do you set BMP_ID_PLANAR for it?

Here's a suggestion to fix this: Introduce a new flag for bmp->id, say
BMP_ID_LINEAR. Allegro must set this flag if and only if it does not set
BMP_ID_PLANAR. Add-ons that create non-planar non-linear bitmaps must set
neither flag. Seems OK?

Unfortunately, I think this would break datafile compatibility, because bitmaps loaded from old datafiles would not satisfy is_linear_bitmap().





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