Re: [AD] fix for using transformations without a display and make blending mode a per-display state

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Fri, 2010-03-05 at 23:35 -0500, Pavel Sountsov wrote:
> Elias Pschernig wrote:
> > On Thu, 2010-03-04 at 19:59 -0500, Pavel Sountsov wrote:
> >> Considering that transformations are still ignored when memory bitmaps 
> >> are drawn (check out ex_transform), that was on purpose. The whole 
> >> memory-transformation side was/in part still is unimplemented and I hope 
> >> I mentioned that in the commit. It's next on my TODO list, though. 
> >> Involves lots of re-arrangement in the memblit.c code :(.
> >>
> > 
> > I wonder if we should move that draw_parallelogram macro thing into the
> > primitives addon, it basically seems to be duplicated code with the only
> > difference that your version already supports transformations.
> > 
> 
> Wouldn't that make the memory bitmaps be dependent on the primitives 
> addon?

Yes, no big problem there. We moved drawing rectangles out of core, why
not bitmaps. Well, just if it makes things easier to implement - I don't
really know if it does. But basically the primitives code can do just
the same thing already and doesn't use some rather obscure code which
might go back as far as Allegro 1.0 (!).

> The draw_parallelogram function actually in principle supports 
> transformations, since it just needs the 3 corners of the parallelogram, 
> which can be obtained by transforming the bitmap rectangle corners in a 
> function immediately before it. This is in fact, as far as I remember, 
> what happens for rotated/scaled bitmaps. See rotate.c for that code.

Hm, I see. So as long as our transformations are strictly 3x3 matrices
only it should work.

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>