RE: [AD] new blit

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


> -----Original Message-----
> From: alleg-developers-admin@xxxxxxxxxx [mailto:alleg-
> developers-admin@xxxxxxxxxx] On Behalf Of Evert Glebbeek
> Sent: Friday, February 04, 2005 4:01 PM
> To: alleg-developers@xxxxxxxxxx
> Subject: [AD] new blit
> 
> The attached patch against current new_api_branch moves the existing
> blitting functions over to the new api. In other words, what it does
is to
> add
> 
> void al_blit(int flags, BITMAP *source, BITMAP *dest, int dest_x, int
> dest_y)
> void al_blit_region(int flags, BITMAP *source, int source_x, int
source_y,
> int source_w, int source_h, BITMAP *dest, int dest_x, int dest_y)
> void al_blit_scaled(int flags, BITMAP *source, int source_x, int
source_y,
> int source_w, int source_h, BITMAP *dest, int dest_x, int dest_y, int
> dest_w, int dest_h)


Nice :)

> What about draw_sprite? I
> know it uses different coed from masked_blit(), though it could really
be
> considered a special case from that. What is the difference exactly?

draw_sprite can masked-blit 8-bpp bitmaps into bitmaps of any other
color depth. I'm not sure how useful that is, or anyone cares about that
feature.



> I have a small problem though, I'm not sure I understand everything in
the
> draft about clipping rectangles... as I read that, I had the
impression
> that it's more complicated than it needs to be, or am I missing
something?

Yeah. I had started an implementation on the side, and then realized it
would make it O(N^3) at best and be horribly slow.

I think we should just stick to the current Allegro behavior of
destination clip rectangles. This has the additional benefit of mapping
nicely to glScissor().






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