I’m attempting to upgrade from 3.13.1 to 3.17.1 and found that calling setContentSize() on a sprite scales the sprite. This does not happen on 3.13.1. Is this an intended change as I thought setScale was clearly separated from it.
Also notice it only scales the base sprite, child sprites are unaffected.
I’m not aware of this. Can you share your code, etc so we can test this out?
Strange, I use a lot of setContentSize() and never seen this. I’ve been using cocos2d-x since 3.2 I believe.
It’s definitely happening on most platforms, I’ve tested on Windows, Linux, and Android they all have the same behavior.
You can reproduce it in any project, simply:
auto sprite = Sprite::create("omg.png");
sprite->setContentSize(Size::ZERO); // or any size you wish
addChild(sprite);
In this case the sprite disappears because the size is zero. Other content sizes will stretch or shrink the image.
So it seems like it’s a pretty serious bug?
I’ll also add that this is definitly not my code issue as I was able to reproduce this from cocos2d-x test projects. Here is a screenshot from the game-controller-test project as I was playing around with it (THANK YOU FOR ADDING CONTROLLER SUPPORT)
with setContentSize
without setContentSize
This is weird because none of my 30 games are experiencing anything weird and they are using 3.17.1 having started with 2.2.6 some of them.
We can test and see if we can reproduce.
Can you show us your code not as a screenshot.
Show us 3.13.1 working as you expect so we can have test data.
You are manually setting the content size. What do you expect if you set something really big or zero?
You may have missed the message before the screenshot, you can reproduce this simply by adding a sprite to any scene and call setContentSize(). I provided example in that post, and if you setContentSize to zero the sprite disappears. You can literally just create a new project and paste the code in to your HelloWorld init scene. Here’s the code again:
auto sprite = Sprite::create("omg.png");
sprite->setContentSize(Size::ZERO);
sprite->setPosition(visibleSize/2); //centers the sprite
addChild(sprite);
I added the line that centers the sprite so you can more clearly see it
Yes, setContentSize scales sprite in 3.17.1.
Why do you use setContentSize on sprite?
And it doesn’t in previous versions? Is that what you are saying?
@slackmoehrle Yes it doesn’t stretch in 3.13.1
@dimon4eg I use it for 2 purposes:
this breaks both of these. You can argue the first point is more hack-ish but the second point is a legitimate use. I use it quite often, and it ends up stretching the base image.
I just checked CCSprite.h on 3.13.1 setStretchEnabled does not exist so this seem like it’s an intended change. At least it should be off by default as it is incompatible with earlier versions of cocos.
Did you try sprite->setStretchEnabled(false); ?
Does it work for you?
Yes.
So is this an intended change or bug?
This change has been in there since Cocos2d-x v3.14, released on Jan 3, 2017, so it’s not something recent. It may not be a good idea for stretch to be changed back to “false”, because it seems like this is the first reported issue with this behavior, and there have been many releases after it was introduced, so changing it back may affect all products released since v3.14.
The correct behavior should be dictated by the typical (ie, most common) use case for setContentSize(). The two options here are:
(1) Sprite scales to the content size
(2) Sprite canvas size changes without scaling texture
Perhaps there should have been a request for feedback regarding this change before it was introduced in v3.14, but given that it’s been in there for the past 2+ years, and many releases, along with the fact that there haven’t been any other posts regarding this implementation, it may be best to leave it as is.
ok thanks everyone!
While you guys are here anyone care to take a look at another bug I submitted on github regarding setWindowed and getVisibleSize? When I submit bugs on github I usually don’t get any responses. I can start another thread if there needs a discussion. Thanks
It’s always best to keep each unrelated topic in a different thread, so yes, do create a new thread for it.
Let’s start a GitHub issue about this and discuss it there too. I’ll start one.
This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.