I went ahead and made the changes I was talking about in my personal fork
here:
https://bitbucket.org/HigashiNoKaze/pyglet
It's probably easier to show in code what I was suggesting. I think this
now matches the cocos behavior, and does not break backwards compatibility
with pyglet applications. Please let me know your throughts on these
changes.
On Monday, April 10, 2017 at 11:12:58 AM UTC+9, Benjamin Moran wrote:
>
> 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.
