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

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


On 2009-09-07, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> 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.

True.  I guess I would have made each tile a separate bitmap or
sub-bitmap.

> 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.

Can you explain more?  I wasn't aware of this feature, whatever it is.

> 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).

I might have asked this already. If the transformation includes a
rotation, will al_draw_bitmap() rotate the source image?

That probably would mean the font addons could draw rotated text
without any extra work.

> 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).

Peter




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