Hi Claudio,
The decision behind the pyglet behavior was to maintain backwards
compatibility. You can blame me for that :)
The important point was that the existing behaviour of scale did not
change. This is the reason why the scale property returns a single float.
If a user does something like "I want to triple the size for my sprite",
they should just use `scale` as usual. If the user wants to use `scale_x`
and `scale_y`, they must also check those parameters to retrieve the
result. As you said, the limitation is that you cannot use both `scale`
and `scale_x/y` at the same time. They overwrite each other. You must use
only `scale`, or only `scale_x/y`.
The new behavior has not be included in any release yet, and is not yet
documented. I think it's fine to consider changes, as long as we don't
break the usage of `scale`. I like your suggestion. To summerize, the
behavior would be:
- The `scale` attribute will become a "base scale" value.
- The `scale_x` and `scale_y` attributes will interpolate from `scale`,
if it is != 1.
I think this matches the cocos behavior, correct?
On Sunday, April 9, 2017 at 10:44:47 PM UTC+9, claudio canepa wrote:
>
> While working in cocos's compatibilty with pyglet repo, some differences
> in Sprite scaling between cocos and pyglet has been spotted.
>
> Let's compare the pyglet semantic with the cocos semantic:
>
> pyglet:
> for applications that never set scale_x nor scale_y, scale tells how much
> shrink or grow the sprite image to display; 1.0 is full size, 1.20 is 20%
> bigger, 0.7 is 30% smaller. scale_x and scale_y will have the same value as
> scale.
>
> for applications that want to display sprites that scale different in
> horizontal and vertical, scale_x and scale_y controls the shrink/grow in
> each axis.
>
> Reading scale will give a nonsensical number if scale_x != scale_y.
>
> Setting scale will set scale_x and scale_y at the same value, erasing any
> differential scaling for horizontal and vertical. So, if at some point in
> time it is desired to grow the sprite size, both scale_x and scale_y should
> be multiplied by the grow factor.
>
> cocos:
> (scale_x, scale_y) controls the ratio width/height ('taller',
> 'fatier',...) by shrinking/growing in the respective axis
>
> scale aplies a resize factor over the change done by (scale_x, scale_y)
>
>
> How it looks to explain some use cases
>
> "I want to triple the size for my sprite"
>
> + pyglet: do scale_x *= 3; scale_y *= 3, because changing scale will alter
> aspect ratio in the generic case
> + cocos: do scale *= 3
>
> "I want to grow by 200% and then shrink to initial size a sprite
>
> pyglet:
> scale_x0, scale_y0 = scale_x, scale_y
> with t-t0, interpolate in (0, (scale_x0, scale_y0)), (duration/2,
> (3*scale_x0, 3*scale_y0)),
> (duration, (scale_x0, scale_y0))
> (scale_x, scale_y) = scale_x0, scale_y0
>
> cocos:
> scale0 = scale
> with t-to, interpolate in (0, scale0), (duration/2, 3*scale0), (duration,
> scale0)
> scale = scale0
>
> The oocos way looks more convenient to me: easier to explain, no special
> cases, simpler user code.
>
> So:
> - what pyglet users think ?
> - pyglets devs are willing to consider to change to the cocos semantics ?
>
>
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
