Re: [AD] Meaning of the texture coordinates for the primitives addon

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Mon, 2009-09-07 at 09:28 +1000, Peter Wang wrote:
> 
> My thinking is that, like texture mapping, the user knows which pixels
> on the destination bitmap he wants to cover, but doesn't particularly
> care which source pixels map to which destination pixels.  So the source
> bitmap could be any size, and the size could change, but as long as the
> whole source bitmap is used it's fine.
> 

Depends a lot on what it is used for I think. Basically, if my source
bitmap contains something like all the 32x32 pixel tiles and sprites for
my retro-style game, I'd keep it all in pixels. If I'd (ab-)use the A5
primitive functions to somehow manipulate textures to be projected onto
3D faces, normalized coordinates would make more sense.

> > So, I still think we should use pixels everywhere, but allow the user to
> > easily change it (with al_use_transform).
> 
> Well, my objection is still that routines which are meant to work with
> either convention will need to explicitly set the transform and restore
> it afterwards.  Probably that won't be done, and those routines will
> just not work when someone tries to use it with a different transform.
> It's certainly not the first part of the API with that problem, and I
> don't know how important it is.
> 

Hm, yes, I agree. I actually didn't know about al_use_transform for a
long time - it just suddenly was there :) So, yes, we need to clarify
what kind of state exactly it is.

I'd say it is quite similar to the clipping rectangle. Like each
(target-) bitmap has a clipping rectangle right now which affects all
drawing operations into it - there also would be a coordinate
transformation.

And speaking of al_set_clipping_rectangle, the online docs currently
start with this:

/* XXX this seems like it belongs in bitmap_new.c */

And looking at the code, there actually seems to be little justification
to not simply make the clipping rectangle a bitmap property. The only
place right now where this is not the case already is in
al_set_target_bitmap - which resets it to cover the whole bitmap, which
is a somewhat questionable feature anyway.

So, without thinking much about it, I'd say we should:

1. Have the clipping rectangle be a bitmap property (changing the target
bitmap would retain it, unlike now).

2. In addition to a clipping rectangle, also give each bitmap another
property, a coordinate transformation (i.e. al_use_transform now would
officially be supposed to work like it already does with OpenGL - except
additionally changing the target bitmap would retain the transform).

3. Also use the source bitmap's transform for the source coordinates, in
case of al_draw_bitmap_region, al_draw_scaled/rotated_bitmap and
al_draw_prim (i.e. whenever coordinates inside the source bitmap are
specified).

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>