In fact, JSB is already supported in Creator, you can build native project with Cocos2d-x v3.10 or lower version ( v3.10 is recommended ).
In the roadmap, Integrated JSB debug solution means we will provided a debug solution with VSCode debugger for JSB, so that you can debug your JS logic the same way as web build. I believe it’s a great improvement on user experience. You can already try our VSCode debugger with current Cocos2d-JS project, creator project is not yet supported but we are working on it, refer to Use VSCode to debug cocos2d-x JSB programs
About spidermonkey version up, it will be a difficult decision for us, we have so many project rely on the bindings level API: SDKBOX, AnySDK, Cocos Runtime, and many user project. Upgrading spidermonkey means they need to upgrade their bindings code, every time it happens, we got lots of complains. So we became more conservative after v33 upgrade. I personally think we should first have a Abstract Binding Level, then upgrade won’t affect binding level API, but currently we don’t have resources for this task. In conclusion, I think the upgrade won’t happen very soon.
This mean that you are going to release a new version every month?.
Also, in the current beta 0.71 can we develop custom packages? because I’m testing the packages from the following repo https://github.com/cocos-creator/example-packages and I’m not able to making this work.
In the other thread you also mention that cocos creator will be open sourced? Do you have any estimated date when will be open to the community?
A question: The engine that is used internally by the Creator is, what I’m assuming, based on the current version of Cocos2d-html5 (3.10) correct?
Will it “replace” Cocos2d-html5 and be deeply integrated into Cocos Creator or will the updates of the engine also be merged back into Cocos2d-html5?
In other words, is Cocos2d-html5 3.10 “finished”?
I’m asking because quite a few projects (including ours) are deep in development using Cocos2d-html5. It would be nice if promised features like automatic sprite batching would make it into -html5.
There are some close sourced core modules, and I don’t think they would become open source.
Yes
No, they have different purposes, to support Entity Component architecture, we have build up a EC level on top of Cocos2d-html5, but we also modified tons of the details in Cocos2d-html5, basically we can’t simply merge from one to another. Most changes we made in Creator won’t and can not be merged back, but we have some common feature plan for them, like auto batching, better resource management.
In conclusion, Creator web engine and Cocos2d-html5 are already taken different paths, we will try our best to do things cleverly and cleanly, so that both side can take benefit from the improvements on base modules. But I also admit our priority is switched to Creator, and new features built on EC architecture aren’t like to be merged into Cocos2d-html5.
Also, Just curious to know whether the ultimate aim of this Cocos Creator to build something like Unity(if so, highly impressed as after that none can really beat cocos, if not then nevermind, haha) or something like Cocos Studio?
How does it even matters? There can be several internal things like code refactoring. Also, they have acquired fireball for this tool, so they might like to change code which is related to that because it’s now cocos creator and not fireball!!
I think going with spritebuilder would be better as it also includes physics editor inbuilt! What you think?
@pandamicro Do cocos creator have aims for including physics things!
I mean, can u please explain what’s Collider components and related events and callbacks in the roadmap?
Collider components and related events and callbacks is a simple rectangle or circle based collider for detecting simple collision.
Chipmunk physics extension will also be available in July, we have a user who is developing a Box2d extension for Cocos Creator, in case it interests someone, here is the repo:
Oh! Actually by physics things, I meant something like drawing physics bodies on the sprites itself in the cocos editor and attaching it that sprite, just like we’ve in Unity or SpriteBuilder.
By this,
Is that the same you meant or is it some other thing!
Because I think since we’e full access to cocos2dJS engine inside cocos creator we can obviously use Chipmunk physics code in the editor! So, thing coming in July would be GUI for physics?
That would be fun
Currently, collision for simlple rectangle/circle can be done using getBoundingBox in cocos2dJS,
then what exactly will it be for cocos creator, I mean we already have that, isn’t it?
I went through the github link, but couldn’t understand how exactly it can be tested/used currently
At least, circle and box collider shapes enough to me for now. (I know, polygonal shape entegration isn’t easy)
The important thing is designing simple collider shapes in the visual editor. Usually, I’m already use box and circle collider shapes instead of polygonal collider shape. (because of performance)
We can do other physics operations in the coding process. (bitmask, collision dedection…etc)
So, all of major game genres needs to designing physic shapes in the visual editor. (Platform, topdown, strategy, beat em up, shot em up…etc)
I had made 2 basic prototypes which had unusual physics bodies and they worked perfectly fine for me.
I had to do some modifications as sizing was issue that I initially faced main problem in…
Why do you find polygon shape integration difficult, I mean how do you do it?
But yes, if some visual physics editor would be integrated then it would be really good.
