[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On June 21, 2010, Elias Pschernig wrote:
> On Mon, 2010-06-21 at 14:57 -0600, Thomas Fjellstrom wrote:
> > Ok so today I had a little fun fighting with a bug in my code. Turns
> > out I was assuming al_transform_transform's first arg was the
> > transform to transform, and the second was the transform to transform
> > by. Thats backwards.
> >
> > I was wondering if anyone else thinks that the current ordering is
> > backwards? And if not, maybe the documentation could be clarified a
> > little, or at leas the names of the args could be a little less vague.
>
> I would agree.
>
> al_rotate_transform(Ta, b)
> al_transform_transform(Rb, Ta)
> al_transform_coordinates(Ta, x, y)
>
> This has two problems. The first is probably what happened to you. If Rb
> is a transform which rotates around b, then it would make sense that the
> first and second line do exactly the same. Semantically, when
> al_rotate_transform(Ta, b) says "rotate transform Ta by b" you'd expect
> that "al_transform_transform(Rb, Ta)" says "transform transform Rb with
> Ta" and *not* "transform transform Ta with Rb".
>
> The second one is even more serious though. We agreed previously that
> the transformation order is reversed compared to OpenGL, so whatever
> appears earlier on in code is applied first. So in the above example you
> would assume:
>
> First rotate by b.
> Then apply Rb.
> Then apply Ta.
>
> However what really happens is this:
>
> First rotate by b.
> Then apply Ta.
> Then apply Rb.
>
> So two good reason to change it. The function
> al_transform_coordinates(Ta, x, y) of course is inconsistent. Maybe we
> can rename it to: al_apply_transform(Ta, x, y) so you would read it as
> "Apply transformation Ta to the vector x, y."
>
> > And I would REALLY like to see 3D transforms at least supported by the
> > HW primitives and blitting functions. Can't do a decent "dialog flip"
> > effect without perspective.
>
> I believe it is supported already - i.e. the full 4x4 matrix is passed
> on to the HW... I remember we talked about applying a starwars effect to
> text in #allegro :) We should mention it in the documentation though and
> have an example demonstrating it.
Would it be too much to ask for a function to rotate by the X and Y axes
instead of just Z? I'm aware it probably wouldn't work (and would take a
fair bit of work to make it work) with the software routines, but I don't
care too much about that. Who knows, maybe having the feature advertised
might get someone to implement it in the sw routines too.
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx