Hello Richard, I´m currently on vacation without my computer, so it´s kind of tricky to look at the code from an iPad. ;)
The change in essence is really good. I actually like the fact that pyglet got rid of the `_scale` attribute. It was kind of confusing to have both `scale` and `scale_x` affecting the scale in combination. But in the current PR, I think there is a small problem. As you override the `scale` property, you only call the pyglet scale setter. It nicely sets both `scale_x` and `scale_y`, then it calls `_update_position` which is the version from `cocos.Sprite`. But if we end up in the scenario where we also have a `transform_anchor_x` or `transform_anchor_y` then we call `get_local_transform()` which will **not** recompute the transformation matrix as the attribute `is_transform_dirty` has not been set to `True`. This would be set to True in the `CocosNode.scale` setter. In order to fix this, just setting both `is_transform_dirty` and `is_inverse_transform_dirty` to True in the `Sprite.scale` setter should do the trick. Now I´m wondering if it would not be best to actually imitate pyglet scale behavior for all `CocosNode`. We could also remove the `_scale` attribute and only leave a `scale` property which would do the same as for `pyglet.Sprite` plus setting the `is_transform_dirty` and `is_inverse_transform_dirty` flags. I´ll be back from vacation next week. I´ll have then more time and the proper tools to read code. I hope I didn´t misunderstand something. Dan Le dimanche 26 février 2017 23:30:27 UTC+1, Richard Jones a écrit : > > Hi Claudio, > > I've been away from cocos/pyglet for a while now, but I've jumped back > in over the weekend to play with some ideas I've had. Unfortunately, > I've run into some issues in the cocos codebase and, compounded, > they're making life a little painful. > > - I ran into an issue in the tiles code that's a single-line change to > fix (improve property lookup on map cells), and also I wanted to fix > compatibility with the current master pyglet sprites (pyglet dropped > the _scale attribute) > - In doing so, I merged upstream cocos from you, but ran into a > problem that the tiles code had been transformed from CRLF line > terminators to just LF (yay!). That meant my patch merge was tricky, > but doable, no problem. > - But now I'm looking to submit a PR for those changes, and another > file has also been transformed and I'm out of sync again, so the PR is > much broader than it should be. I'm going to reset my clone (not sure > how, merging your upstream hasn't completely resolved everything, I > might need to delete and re-clone). > > Looking at the cocos codebase there's a mix of CRLF and LF files in > there. Before I look at resetting my clone of the repos and redoing > the above patches, I wonder whether you'd be open to normalising the > CRLF/LF mix in the repository? > > > Richard > -- You received this message because you are subscribed to the Google Groups "cocos2d discuss" 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/cocos-discuss. For more options, visit https://groups.google.com/d/optout.
