@ricardo
Will calling setContentSize() on a sprite in non-9-slice mode resize the sprite? At present this does not happen, but I do think it should - not doing so is unexpected behaviour.
How is PolygonInfo handled when switching between modes? Ideally we should be able to switch between the following modes without loss in data:
Quad
Polygon (falls back to Quad if no PolygonInfo has been provided - manually or in the sprite frame)
NineSlice
The default mode could depend on what initialisation function is used
I think it’s really very rare case - switching back and forward to scale9 mode (earlier it wasn’t possible at all). So in my opinion it would be better to keep things simple and not overcomplicate implementation.
Hey ricardo, I meant to say that, whether the C++ Api put in cocos creator will belong to v4.0 because as were the initial talks that cocos creator follow entity based model. Where I also remember that it isn’t supported well in current cocos2d-x versions. So, I was wondering if there would be shift in the C++ Apis.
Also, there was work going on Cocos2d-x v4.0 since ~1.5-2 years which has no updates as of now. So, I thought, it would come as a surprise gift
I agree that setCenterRectNormalized() works better, however as we already have setNormalizedPosition() there would be a conflict in naming conventions.
@ricardo Do you have scope to change the setNormalizedPosition() function name?
I think the idea offered by @pococogames about exporting all of scene as a C++ code does not take into account the ability of online asset updating. For now we can update csb-files via downloading them from server and use new assents in runtime.
yep, we need that. It will make the API consistent.
Normal sprites (quads) and Mesh sprites (polygons), both of them, are using polygons internally.
So this new 9-slice behavior keeps using polygons internally. It just creates a 9-quad polygon (a 18-triangle polygon). So internally nothing changes.[quote=“MikhailSh, post:52, topic:32143”]
IMHO it may be better to name it setCenterRectNormalized just because it will work better with autocomplete and easier to search.
[/quote]
yep. probably I’ll need to update setNormalizedPosition as well as @almax27 suggested.
correct. v3.x doesn’t have a true ECS. And it won’t be possible to support all the Creator features in c++. So only a subset of its features will be supported.
yep. we postponed the v4.0 development to focus on v3.x. But we started working again on v4.0… no code yet… just requirement gathering.
correct. For the moment I’m only supporting exporting to C++. Once it is finished I’ll try to support csb files as well.
// stretch by 2 the sprite content size (doesn't affect its children)
sprite->setContentSize( sprite->getContentSize() * 2);
// stretch by 2 the sprite content size (doesn't affect its children)
sprite->setCenterRectNormalized(Rect(0.4, 0.4, 0.2, 0.2));
Some examples with and without the setCenterRectNormalized().
Top row using centerRect. Bottom row, doesn’t.
(you can also use setCenterRect() in pixels coordinates)
And here is a little video showing one possible effect that you can get by changing setCenterRect in runtime… not sure if this effect is that useful, but it looks nice:
I tested the slice-9 support in Create-C++ and, after fixing and adding some code, it works pretty well.
I still need a few bugs… but so far, so good.
The setContentSize() feature fixed a major bug… yeah!. I love when a bug is fixed “automatically” :).
Here are some screenshots so that you can compare Creator vs. cocos2d-x c++:
Added support for Tiled sprites. But instead of adding the “tiled” functionality inside the Sprite class, I created a helper function that will create the needed polygon for it. This helper function will probably be part of the “creator support” lib.
I didn’t add it inside Sprite because I didn’t want to “bloat” the Sprite class.
Rewrote Scale9Sprite. It is a subclass on Sprite (instead of Node), so it was pretty straight forward the implementation. I still need to fix a few bugs, but so far it is passing more than 20 tests out of the 28.
By doing this, I’ll be able to reuse most of the Cocos Creator UI classes for Creator.
Continued fixing slice 9 bugs. The good thing is that having slice9sprite as a subclass of sprite, it is a great test case for Sprite.
I spent they entire day fixing a bug when flipping a slice9 sprite before changing its content size.
I could have fixed easily by just iterating all over the vertices and flipping them, but that was expensive. I’m flipping it while calculating its triangles. More efficient.
I noticed that the old Slice9 sprite was flipping it by just doing scale =* -1. That’s a bug (fixed i the new implementation).
Pull request here: https://github.com/cocos2d/cocos2d-x/pull/16770
So, I have this bug when trying to emulate Slice9Sprite: it calculates the “centerRect” using the untrimmed size of the sprite as a reference. And I think that’s correct.
On the other hand, Cocos Creator uses the trimmed size as a reference. And that means that Scale9Sprite and the sprite used by Creator are incompatible.
But I didn’t realize that until I was half way converting my code from “trimmed” to “untrimmed”.
So, I reverted my changes, and what I’m going to do is to create an “adaptor” in Scale9Sprite.
so:
Sprite::setCenterRect() will use the trimmed size as reference (used by Creator).
Scale9Sprite::setCapInsets() will continue to use the untrimmed size as a reference, and internally it will change its value and call setCenterRect.
It was a kind of frustrating day today… not very productive.
