C++ support for Cocos Creator

ricardo · September 16, 2016, 10:12pm

Sorry, I didn’t get that. What do you mean by “live node hierarchy” ? You mean exporting directly from Cocos Creator (without parsing the .fire files)?
If so, yes, that’s was my original proposal: Cocos Creator should have plugins and 3rd party extension could browse the scene graph (and other objects) and do whatever they want with that data… like creating a exporter to whatever they want, or even transforming the scene graph.

But right now it is more important to have the C++ exporter than to have a polished API for 3rd party developers.
So, the easiest way for me is to parse the .fire files.

Rearding parsing JavaScript snippets… well, that seems hard.[quote=“piotrros, post:21, topic:32143”]
So… If I have cocos studio project…
[/quote]
Probably you should keep using it.[quote=“ShunLin, post:23, topic:32143”]
YuLei is working on automating the workflow. I will ask him to sync up information here.
[/quote]

great!

pococogames · September 17, 2016, 12:02am

@ricardo I didn’t work on Js side until today. But I have an idea. Why you don’t export all of scene as a c++ class format.(with parsing on Cocos Creator)

1-We open Cocos Creator and designing scene.
2-File->Export->Cocos2d-x Scene Path

So after we have two files;
sampleScene.h
sampleScene.cpp

And you may use js binding feature of Cocos2d-x for physics or another companents on Cocos Creator.

So I think c++ developers just want to level design, physics editing, managing project and assets…etc

C++ workflow isn’t just like Js workflow. We working more slow then high level sides because of compile times.

ricardo · September 17, 2016, 12:24am

that’s an interesting option. thanks.

stevetranby · September 17, 2016, 4:23am

@ricardo yeah I was a bit cryptic since that was a very stream of consciousness. Hope this reply clarifies it a bit.

Live Node Hierarchy - Create a Scene, add some Nodes with children in code using Scene::create, Node::create, and node->addChild. Take the scene or any node in the hierarchy and be able to export a .fire (or equiv) file based on the properties of the runtime node itself along with its children. Node::ExportAsFireball(node, "filename.fire"); or whatever. Similar to TMX writer, etc.

Similar to @pcocogames my thoughts on having CocosCreator export more c++ friendly files is not difficult and should be fairly straightforward. Either directly to a known loadable format (.csb) or by writing out c++ directly.

I was thinking less about Javascript->C++ per se and more that you could write “scripts” in the editor as small snippet in the chosen language and for c++ it would just combine all the snippets into the “event” functions (onLoad, etc) into a single generated .cpp/.hpp file set.

walzer · September 18, 2016, 9:26am

Aha, brilliant. You absolutely can ask Shun to get the script!

ryukbk · September 20, 2016, 1:57pm

Interesting plan, but does it mean a Cocos2d-x C++ project keeps its current directory structure and will not be unified with what Cocos Creator uses? I had a hard time due to the situation of Cocos Studio and Cocos Creator, if switching to the project structure of Cocos Creator is not necessary it’s cool, but if the current Cocos2d-x structure is deprecated in favor of Cocos Creator in future, sooner is better as we don’t want to go back and forth.

Since it looks like a one-way C++ exporter for Cocos Creator, if you add your own event handler code in C++ to exported C++ scenes, you have to port such modification each time you modify your Cocos Creator project and export it to C++, is it correct?

ricardo · September 21, 2016, 3:23am

quick update:
In this repo I’m putting my tests: https://github.com/ricardoquesada/CreatorTest
this is the script: https://github.com/ricardoquesada/CreatorTest/blob/master/parser.py

for the moment it does almost nothing, but it has the structure which is important. Now it is time to do some boring stuff and import the properties and print them correctly.

Yes. This is just an exporter. It will generate the needed files to load a CocosCreator scene in cocos2d-x.

ricardo · September 22, 2016, 4:31am

daily update

parsing the sprite frame data
parsing the texture data
parsing the uuid-to-mtime data (not sure if this is needed yet)
guess Node class base on components

The output, for the moment, is not useful yet, but it will be soon. From a very basic .fire scene, the output right now is this:

Scene
--Canvas
--TiledMap
--ParticleSystem
--Sprite('grossini_dance_08')
--Sprite('grossini_dance_08')
--Label('This is a label')
--Label('This is another label')

I’ll add the c++ output in the near future. So far, I think I’m parsing all the needed info to support the “built-in renderer” nodes.

ricardo · September 27, 2016, 1:21am

daily update

script generates compilable c++ code. It only supports the Renederer built-in nodes for the moment.
Tomorrow I’ll add support for Canvas and put the resources in the correct place
and on Wednesday start with the UI built-in nodes.

Script is here: https://github.com/ricardoquesada/CreatorTest/blob/master/parser.py
Autogenerated code (just a test), here: https://github.com/ricardoquesada/cocos2d-x/blob/creator_cpp_support/tests/cpp-tests/Classes/CreatorTest/CreatorTest.cpp

ricardo · September 28, 2016, 6:18am

daily update

Add design resolution
Sprite Frames are being generated.
outputs a .cpp / .h file per .fire file
each .cpp file has two functions: XXX_setup() and XXX_create().

Example of generated file is here:

github.com

ricardoquesada/cocos2d-x/blob/6e362e7cc7f68dc216b569a7f7f90aaa110c0e4a/tests/cpp-tests/Classes/CreatorTest/CreatorTest.cpp#L28


FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
****************************************************************************/


#include "CreatorTest.h"
#include "../testResource.h"


////// AUTOGENERATED:BEGIN //////


USING_NS_CC;


bool MainScene_init()
{
   auto director = Director::getInstance();
   auto glview = director->getOpenGLView();
   glview->setDesignResolutionSize(960, 640, ResolutionPolicy::FIXED_HEIGHT);
   auto sf_grossini_dance_08 = SpriteFrame::create("grossini_dance_08.png", Rect(17, 7, 51, 109), false, Vec2(0, -1), Size(85, 121));
   SpriteFrameCache::getInstance()->addSpriteFrame(sf_grossini_dance_08, "grossini_dance_08");

ricardo · October 5, 2016, 4:57am

daily update

many bug fixes for the Renderer nodes… still a few things to fix regarding positioning… for some reason the positions are not the same as in Cocos Creator. It has to do with the Design resolution. Will fix it tomorrow.

This is a scene renderer in C++ which was created in cocos creator:

ricardo · October 6, 2016, 4:51am

daily update:

Well, apparently the issue with the positioning the sprites has to do with some scaling that Cocos Creator does with the canvas, but I haven’t figured out yet how to do it.
Instead, I was able to add better support for label and sprites.

For labels it supports:

system fonts
ttf fonts
bmfonts
different alignments
colors
line height
multiline

For sprites it supports:

all transformations: rotations, scale, skew, etc.
colors
.png and atlas

Sprites:

Labels:

kwellman · October 6, 2016, 5:32pm

Do your plans include being able to export animations created in cocos creator to C++?

ricardo · October 6, 2016, 5:56pm

quick update
I’ve just fixed the canvas design resolution thing, but that didn’t fix the sprite positioning issue. I think it has to do wit the sprite scales. I’ll ask the Lua guys how they fixed it.

yes, it is in the plan. I don’t know how they work yet, but it is in the plan.

ricardo · October 8, 2016, 7:36am

daily update:
I started with UI support. This is not trivial.
Mostly because the API are different: for example, in cocos2d-x you create an EditBox with a scale9sprite, but not in Creator. So I need to figure out how to convert them.
The script has parses most of the UI components, but it doesn’t generate valid c++ for these UI elements. I have to figure out the Scale9Sprite first.

ricardo · October 18, 2016, 12:40pm

What happened since my last update.

Basically I got stuck because most of the Cocos Creator UI built-in nodes require “Slice 9” features.
In theory I could our class Scale9Sprite, but it is not compatible.
So, what I did was to add Slice 9 features into Sprite. (feature almost finished)

catch_up · October 18, 2016, 5:14pm

Hey ricardo. Seems like, we’ll have evolved version of cocos2d-x(C++) Api support in Cocos Creator. So, I am just curious to know if this Cocos2d-x (C++) will be v4.0?

Your efforts are helpful. Thanks for progress

ricardo · October 19, 2016, 3:11am

Sorry, I didn’t understand the question. Do you mean if this feature will be part of v4.0?
Hopefully it will be part of 3.14 or 3.15

ricardo · October 19, 2016, 3:18am

daily update:
Finished Slice 9 support for Sprite.
It was tricky to implement it correctly, but it was worth the effort.

I’m still not satisfied with the API.
Right now it works like this:
a)

// in normalized coordinates. it will enable the "slice 9" feature
sprite->setCenterRect(0.4, 0.4, 0.2, 0.2);

// and the you scale the image using setContentSize().
sprite->setContentSize( sprite->getContentSize() * 2);

But I think it is better to just use the scale API. eg:
b)

sprite->setCenterRect(0.4, 0.4, 0.2, 0.2);
sprite->setScale(2);

a) is “compatible” with Scale9Sprite, but b) is more natural. You don’t have learn how to use it. Just scale it
thoughts?

Working example here: https://github.com/ricardoquesada/cocos2d-x/blob/sprite_scale9/tests/cpp-tests/Classes/SpriteTest/SpriteTest.cpp#L5316

dabingnn · October 19, 2016, 3:30am

Hi, Riq
In JS version, we use these APIs:

setInsetLeft/setInsetRight/setInsetTop/setInsetBottom is used to specify the sliced 9 grids.
setContentSize is used to specify the content size of sprite.

This is used because it is more natural in editor.
The sliced grid is set in pixels, and the content size only consider the size of sprite. Which will be independent with Scale.