| Re: [AD] 3d transformations |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sun, 29 Jul 2012 10:14:01 +1000
Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On Sat, 28 Jul 2012 18:11:45 +0200, Elias Pschernig
> <elias.pschernig@xxxxxxxxxx> wrote:
> >
> > 2) The new projection transformation, which is per display. It is
> > therefore completely ignored when drawing to memory bitmaps (there
> > is no display involved) and it also cannot be changed while drawing
> > is held.
>
> Would it help things if we named them to emphasize
> "display" and "projection" and not "transform"?
>
> ALLEGRO_TRANSFORM *
> al_get_display_projection(ALLEGRO_DISPLAY *display)
>
> void al_set_display_projection(ALLEGRO_DISPLAY *display,
> ALLEGRO_TRANSFORM *t)
>
Yes, I think it would make sense. But after talking to SiegeLord in IRC
I'm not sure anymore it is a good idea now. Both having a single
transformation only, and having two transformations but have both stored
in the target bitmap would be alternate ideas.
Two transformations can be useful e.g. in a shader (you can't use the
combined matrix for much as the projection loses a lot of information)
- but nothing stops you from just setting your own shader variable with
the pre-projection matrix, so it's not a strong argument.
And having it per-target-bitmap means the OpenGL/DirectX driver would
take care of storing and re-storing the proper transformation for you
when calling al_set_target_bitmap.
Then finally there's the issue with held drawing not working with
non-affine transformations since it wouldn't preserve the w coordinate,
which would be an argument for the current way where the projection
matrix is not actually used while drawing is held. But there is a bug
with it, in ex_projection it can be seen how the transformation gets
messed up in the first frame when glyphs are being cached - haven't
investigated that yet but I suppose the ttf drawer isn't preserving the
projection matrix somehow.