Yes, your code applies the cocos style. Sorry for the noise, I skipped the scale_z = _scale * _scale_z, so the calcs below looked as it was missing on _scale. I blame the late night, but anyway sorry.
Looks good to me. On Mon, Apr 10, 2017 at 3:41 AM, Benjamin Moran <[email protected]> wrote: > Hi Claudio, > > The changes I have made function exactly as you describe (like the > CocosNode description). > The direct link to the changed sprite.py is here (in my personal fork): > https://bitbucket.org/HigashiNoKaze/pyglet/src/ > 738617edac87a5e313414b790db412763983524e/pyglet/sprite.py? > fileviewer=file-view-default > > > On Monday, April 10, 2017 at 3:13:43 PM UTC+9, claudio canepa wrote: > >> >> >> On Sun, Apr 9, 2017 at 11:12 PM, Benjamin Moran <[email protected]> >> wrote: >> >>> Hi Claudio, >>> >>> [snip] >> >>> >>> 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? >>> >>> Mmm. "Interpolate" does not sound as the cocos behavior; cocos simply >> scales x axis by _scale * _scale_x and y axis by _scale * _scale_y. >> >> The CocosNode description for the relevant members says >> >> #: a float, alters the scale of this node and its children. >> #: Default: 1.0 >> self._scale = 1.0 >> >> #: a float, alters the horizontal scale of this node and its >> children. >> #: total scale along x axis is _scale_x * _scale >> #: Default: 1.0 >> self._scale_x = 1.0 >> >> #: a float, alters the vertical scale of this node and its >> children. >> #: total scale along y axis is _scale_y * _scale >> #: Default: 1.0 >> self._scale_y = 1.0 >> >> """ >> >> I would say that image.width * scale_x and image.height * scale_y gives >> the "resized base image" we want to use, which is furter resized by _scale >> >> - scale usage is backward compatible with latest pyglet released >> >> - Sprites that do not need to change the width / height ratio provided >> in the image don't need to fiddle with scale_x or scale_y, resize only >> needs to change the scalar '_scale' >> >> - A Sprite that wants to adjust the width / height ratio at creation >> time sets the appropiate scale_x and scale_y; if the ratio does not changes >> after creation then it does not need to further touch scale_x nor scale_y. >> Changing _scale along time will resize the initial displayed image, >> preserving the ratio defined at creation. >> >> - for special effects when dinamic changes in the ratio are desired, >> scale_x and scale_y are available. >> >> To see it in code, the relevant part would be _update_position in >> cocos.sprite.Sprite, at https://github.com/los-cocos/c >> ocos/blob/master/cocos/sprite.py#L326 >> >> BTW, your next mail says you pushed a variation based in your >> interpretation to your repo; I could't find there. Maybe it wasn't pushed ? >> >> -- > 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. > -- 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.
