I’ll work on adding C++ support for Cocos Creator.
This thread will be my “personal blog” about it.
1st impressions:
- Cocos Creator is NOT 100% compatible with cocos2d-x.
- It uses a component based model to build scenes
- it supports JavaScript scripts
- it has its own “nodes” (prefabs)
- project files are saved in a “.fire” (json format)
- We recently added Lua support, which means that from cocos2d-x + lua you can run “.fire” files with certain limitations.
So, my plan is:
- Generate an intermediate file out from the .fire files. Most probably an python script. This script will do all the hard work. Basically converting the component-based scene (cocos creator) into a node-based scene (cocos2d-x)
- Not all prefabs / components will be converted. Raise a warning when that happens
- Learn from the Lua support files, since they already triggered those limitations. Unfortunately they are not generating an intermediate file. Instead they are parsing the .fire files in runtime.
Basically I start prefab by prefab and see what can be converted and what not.
##Labels
It is composed of a Node + Label Component.
It is not easy for me to differentiate a Node from a Component.
As far as I know, the Nodes have an _id, but Components, don’t.
Also, Nodes can have Components, but Components can’t have Components.
Node have a container with all its Components:
{
"__type__": "cc.Node",
"_name": "Label",
"_components": [
{
"__id__": 7
},
{
"__id__": 8
}
],
}
But Components don’t have id. Instead, what they have is node which is a reference to the Node that contains them.
eg:
{
"__type__": "cc.Label",
"_name": "",
"_objFlags": 0,
"node": {
"__id__": 6
},
Some properties start with N$ which I have no idea what’s the meaning of that. eg:
"_N$file": null,
"_N$string": "This is another label",
"_N$horizontalAlign": 1,
"_N$verticalAlign": 1,
"_N$overflow": 0
Besides that, Label seems pretty straightforward to support.
##Sprites
Similar to Labels: Node + Component.
The Component has the type cc.Sprite:
{
"__type__": "cc.Sprite",
...
"_spriteFrame": {
"__uuid__": "4f39fc84-eaed-4f05-95ff-f636066e8de8"
},
...
}
And the frame is defined in a “meta” file which is also another JSON file.
It has the following format:
"grossini_dance_08": {
"ver": "1.0.3",
"uuid": "4f39fc84-eaed-4f05-95ff-f636066e8de8",
"rawTextureUuid": "4e2edada-a2d6-4635-afdf-c426810de768",
"trimType": "auto",
"trimThreshold": 1,
"rotated": false,
"offsetX": 0,
"offsetY": -1,
"trimX": 17,
"trimY": 7,
"width": 51,
"height": 109,
"rawWidth": 85,
"rawHeight": 121,
"borderTop": 0,
"borderBottom": 0,
"borderLeft": 0,
"borderRight": 0,
"subMetas": {}
}
And the filenames are the ones that associate them. eg:
$ ls -l
-rw-r--r-- 1 riq staff 6745 Sep 15 18:35 MainScene.fire
-rw-r--r-- 1 riq staff 146 Sep 15 18:35 MainScene.fire.meta
-rwxr-xr-x 1 riq staff 758 Sep 15 18:34 grossini_dance_08.png
-rw-r--r-- 1 riq staff 690 Sep 15 18:34 grossini_dance_08.png.meta
So the file “grossini_dance_08.png” has its frame definition in “grossini_dance_08.png.meta”.
So, supporting sprites seems straightforward, like a Label.
UPDATE: The file “library/uuid-to-mtime.json” has the mapping between UUID and file.
##Splash Sprite
Not sure what’s the purpose of this Node, but it seems almost identical to Sprite. I’ll as the CocosCreator team.
##Particle System
Similar structure: Node + Component.
The ParticleSystem has a “file” that describes the particle.
"__type__": "cc.ParticleSystem",
"_file": {
"__uuid__": "b2687ac4-099e-403c-a192-ff477686f4f5"
},
and in “library/uuid-to-mtime.json” it is described as:
"b2687ac4-099e-403c-a192-ff477686f4f5": {
"asset": 1471599381000,
"meta": 1471599381000,
"relativePath": "particle/atom.plist"
},
but I couldn’t find atom.plist anywhere.
So, once this missing-atom.plist-file is solved, it should be straight forward to support it.
##Tiled Maps
Node + Component. Seems pretty straightforward to support it.
? This is a bit ridiculous cocos team can’t just generate .csb files from cocos creator and it’d be done.