On 03.06.2012 01:47, Christopher Night wrote:
On Sat, Jun 2, 2012 at 1:50 PM, DR0ID <dr0id@xxxxxxxxxx>
wrote:
On 02.06.2012 16:46, Christopher Night
wrote:
On Fri, Jun 1, 2012 at 2:29 PM,
DR0ID <dr0id@xxxxxxxxxx>
wrote:
On 01.06.2012 15:29, Sagie Maoz wrote:
2. Setting a sprite's
anchor points for handling in movement,
animation, collision etc.
5. New visual attributes for sprites:
- Rotation angle
- Scale
2.
the sprites anchor point should be just an offset,
not limited to 'topleft', 'midtop', 'topright',...
and the other rect attributes
I want to be able to specify "center" or
"midbottom" for the sprite anchor without knowing
the image's dimensions. And I want that anchor
point to remain in the appropriate place even if
the image is rotated, scaled, or flipped. I'm not
sure that an offset would accomplish this, but if
so, then that's okay.
-Christopher
Hi
I agree, what I suggested is that both things should be
possible: a general offset and/or specifying 'center' or
'midbottom' or....
I'm not sure right now how the math to maintain the point at
the appropriate place. Maybe this needs some more
specification for the different transformations (rotation,
flip, scale).
Well the desired behavior is pretty straightforward to me.
Say I specify a sprite's anchor as "midbottom", and the
sprite's image has a single orange pixel at its mid-bottom.
Then if I ask to draw the sprite at (200, 100), then that
orange pixel should wind up at (200, 100) no matter how the
sprite is transformed (maybe one pixel off because of
rounding). The math shouldn't be too hard to work out from
that.
-Christopher
Hi once again
In the mean time, I have implemented such a system that leaves the
anchor where it is, but I run into a problem: the order of applying
the transformations. It's not exactly the same if you first flip and
then rotate or the other way around, first rotate and then flip. To
see better what I'm talking about: http://imagebin.org/215001
What is more useful?
As for now my implementation does first rotate and then flip,
because that looks like the behavior I would want if I write a
platformer or similar game. I then have thought about how many cases
a flip and rotation would be used on the same sprite at the same
time and I think there are not that man occasions. But maybe I'm
wrong.
As for scaling it does not matter when it occurs, although I use
rotozoom (which has an annoying black border when rotate by a
multiple of 90 degrees, which looks like the entire image is shifted
by 1 or 2 pixels for whatever reason, bug! bug!, also not sure how
transparency is handled by it).
~DR0ID
|