Cocos2d HTML5 V4

[Ibon]

I’d personally would think that feature parity with cocos2d-x at a high-level makes sense? I don’t think I’d develop anything more than a prototype or micro games (e.g. for jams) if it’s limited to web browsers, but I may be in the minority. If you’re looking for priority of features then maybe asking for games published using cocos2d-js on the web and figure out what features were used most. As you mention the core features (Scene,Node,Sprite,Actions,Animation,Input,Audio) should probably be mostly working in the first release?

These features, and few more are already available in current V4 project. Where it makes sense, we’ll go with full backwards compatibility as well as introducing new features or API where suitable.
For example, the v4 actions are a full rewrite, but also 100% compatible with V3 (and V2) actions by using a thin compatibility layer on top of v4 code. this is transparent for the v3 user, and the v4 will benefit from a more robust syntax and serialization capabilities for example.

So a roadmap would be excellent to know where things stand, what’s actually functional now, estimated delivery, how you plan to support native platforms, if at all (webview wrapper, JSB, etc).

As is answered to @emmyc, the current V4 is much like V3 lite, which focuses only on web development. It does not mean we are not considering native wrapping, but now we have a different approach. While JSB constrains the web API to that of Cocos2d-x, we plan to introduce advanced features currently not present in cocos2d-x. Native wrappers like cocoonJS, X-Walk or phonegap could bring in all the expected performance.
Some html5 v4 features will make it to cocos2d-x too, so they could be used in V3.
but the current idea behind v4 is freedom, and we can evolve v4 rendering and features much faster than if we have to stick 100% to the cocos2d-x contract.
So currently, V4 is for web, but we expect not in the medium term.

Also are you planning to develop this in public (ie: with associated fork/branch/separate github repo)? Are you pulling ideas from other web engines like Phaser, Construct2, or BabylonJS? I guess I am curious about your target requirements? Is Canvas still supported, or will WebGL can be required? What mobile/tablet/desktop browsers and versions are supported?

Absolutely. This project is open source as all the others. And we expect the community to take active part on it defining the product feature set and why not, the roadmap.
We are currently working on the core functionality, and after GDC we’ll start adding game-engine features, so all requirements other engines already implement are welcome proposals.
About rendering, the idea is to have a plug-able rendering system. Canvas, WebGL and DOM (where makes sense) enabled. By plugable i mean that all the rendering code is decoupled from the nodes, and interfaced to a very high level canvas-and-webgl-shared API.
We are not currently targeting any special requirements, just working in making it super fast if webgl is available ( i consider the bunnymark meaningless though: http://labs.hyperandroid.com/less-bunnymarks-more-features ) . fast does not only mean pushing 50k sprites, but aiding developers in creating new type of nodes by offering a high-level yet powerful drawing API.

The project in its current form can be located here: https://github.com/hyperandroid/Cocos2d-html5

all types of feedback are welcome.

[ZippoLag]

Nope, full rewrite means new code for the same features. Some the V3 features won’t make it to V4 in their current state, like the widgets, for example LabelTTF which currently is a bit of a mess. Will there be LabelTTF support ?there already is actually, but with some changes that could leverage its usage.This is an open source project, and we expect this forum and the community to be the feature driver into V4.

Nice! Can I dream about having rich-type formatted text of some form? (hypertext, markdown, anything along those lines would be awesome, even if only for bold and italics).

There’s no easy solution to this. Spriting vectors on-the-fly can be a pain. but definitely worth paying attention to.

I know there are a few libraries that do svg to canvas rendering. What I thought that would be “simplest and most performant” for our case is that maybe we could have a kind of sprite with an image buffer, we draw the svg once there, and use it around as a raster image with approppiate resolution.

Abstraction is the idea behind V4. Still not into this kind of stuff but they are very high in the required feature set.

This is already done. V4 actions act on whatever the object you’d like to. There’s a PropertyAction which does exactly this: https://github.com/hyperandroid/Cocos2d-html5/wiki/Actions#propertyaction

I love you (platonically).

This is actually very straightforward. The engines V3 and V4 already can give you a screen point translated into local space coordinates. if you have the mask in an array, a lookup should be trivial. We could add some utility methods, not to the Node implementation, but as a helper to check for this.

Hm, the only method I’ve found is quite cumbersome and time consuming, it’s discussed in this thread: How to get single pixel of Sprite with cocos2dJS and CocosBuilder?

Already available. And there’s also 9patch support for buttons: https://github.com/hyperandroid/Cocos2d-html5/blob/develop/src/widget/Button.ts#L85

Awesome.

have a look at this: early pre-alpha code, currently writing wiki and pushing examples to github pages. https://github.com/hyperandroid/Cocos2d-html5

I’ll keep my eyes on it! I’m most lacking free time lately, but I’ll be sure to contribute if I can

Thanks a lot! Keep us posted!

Edit/Extra:

• The readme says “Typescript The engine is originally written in Typescript, and later transpiled into JavaScript.”, is there any advantage in particular behind this? The end users of the engine (game developers) will just download the JS source, right? I’m guessing the TS source will also be available in case one would like to use that instead?
• You talked about rendering methods in another comment, is the idea that all graphic features will work independently of the rendering used? (there are currently a couple of things that only work in webGL mode, but canvas has much better performance wherever I’ve tested it, so that’s bothersome).
• I’ve seen many people struggling with handling screen rotation, we currently have to choose wheter we want our game to be portrait or landscape, but it’d be nice if there was a way to easily make a switch so that the game could be played with the UI adjusting properly whenever you rotate the screen (not sure if this isn’t simplified already in v3, though, I haven’t checked in a while, sorry).

[stevetranby]

Thank you for responding, it all sounds like you’re on a very solid path forward, so that’s great. And reading through the docs and source it looks like it’s much closer to what I was hoping it would be and can definitely see aspects that are desired for cocos2d-x in the future. It’ll be interesting to watch and hopefully help through the development process. And thanks for posting the repo, I’ll definitely play around with it.

[Ibon]

Edit/Extra:

The readme says “Typescript The engine is originally written in Typescript, and later transpiled into JavaScript.”, is there any advantage in particular behind this? The end users of the engine (game developers) will just download the JS source, right? I’m guessing the TS source will also be available in case one would like to use that instead?

Yes, that’s the idea. Developers could have whatever they’d rather work with.
IMO there are many advantages. There’s even a wiki page devoted to why ts ^^: https://github.com/hyperandroid/Cocos2d-html5/wiki/Typescript

You talked about rendering methods in another comment, is the idea that all graphic features will work independently of the rendering used? (there are currently a couple of things that only work in webGL mode, but canvas has much better performance wherever I’ve tested it, so that’s bothersome).

In V4 Canvas performance is on average slower than GL.
There’s also limitations in each renderer. For example, canvas can’t do efficient tinting while it is almost free to have arbitrary color tint on GL. WebGL has problems when filling arbitrary self-cutting paths, but that’s something not very common, so we are not very concerned.
Renderers will offer consistent capabilities where possible. But you’ll be able to access each rendering context on your own, so capabilities not implemented in the common renderer can be added on your own (and then contributed back to the project so we all will be very happy).
Another thing in V4 rendering is that node specialization is gone. Now each node has full rendering control on their draw method, so a sprite can draw a path, a regular node a moving pattern in the background and 10 sprites on top, etc.

I’ve seen many people struggling with handling screen rotation, we currently have to choose wheter we want our game to be portrait or landscape, but it’d be nice if there was a way to easily make a switch so that the game could be played with the UI adjusting properly whenever you rotate the screen (not sure if this isn’t simplified already in v3, though, I haven’t checked in a while, sorry).

In V4 there’s something we called liquid layouts. in a non intrusive manner an external-to-nodes layout system calculates sizes and positions of Nodes based on a JSON object. For example, a chunk of layout demo:

var layout= {
            type: "grid",
            columns: 5,
            insets: ["5%", "5%", "5%", "5%"],
            gap: ["20px", "5%"],
            elements: [
                {
                    type:"element",
                    name: "f0",
                    insets: ["5%", "5%", "5%", "5%"]
                },
                "f1","f2","f3","f4"
            ],
            preferredHeight: "20%"
}

the only strange part is the elements. Which tells the system to layout the Node with name “f0” as the first column, and apply a size constraint to it of 5% on each margin. And have the Nodes names f1…f4 take over the whole column space defined by the layout.
It also tells to have a 20px horizontal gap among columns, and, should there be more than one row of elements, a 5% vertical gap.
the % values are calculated from the layout call:

  var l= cc.plugin.layout.BaseLayout.parse(layout);
  l.layout(0,0,800,600);

so you should have two layouts, one for landscape, another for portrait, and apply when the orientation changes. See this for code hints: https://github.com/hyperandroid/Cocos2d-html5/blob/develop/src/test/engine/layout2.html
We are confident this layout mechanism will bring nice capabilities, like laying out your in-game shop, and things that otherwise would require tons of code.

• ibon

[Ibon]

You are very welcome.
Feel free to contribute back anytime (in fact, we encourage you to do it

• ibon

[Ibon]

Nice! Can I dream about having rich-type formatted text of some form? (hypertext, markdown, anything along those lines would be awesome, even if only for bold and italics).

While in webgl we can draw text using SDF, and shadow, glow, perfect scaling etc. will come to the table, styling with different fonts, styles, is something that, either is happening to an off-screen buffer (or frame buffer, whatever) or I don’t see a simple solution for it. The labelTTF does pretty much this, drawing to a texture, and definitely stylling capabilities could be added on top. (note to self) I guess we should have a Trello or something where a public commitment of features could be contributed.

I know there are a few libraries that do svg to canvas rendering. What I thought that would be “simplest and most performant” for our case is that maybe we could have a kind of sprite with an image buffer, we draw the svg once there, and use it around as a raster image with approppiate resolution.

Well, the current V4 implementation has pathi capabilities. Complex ones i mean. But parsing an SVG is not so straightforward. parsing the paths is one things, but parsing the attributes, etc. is a heavy weight operation. I can’t give a conclusive answer on this.

Hm, the only method I’ve found is quite cumbersome and time consuming, it’s discussed in this thread: How to get single pixel of Sprite with cocos2dJS and CocosBuilder?

Have worked on a solution for this, and it is transparently integrated in V4.

[ZippoLag]

In V4 Canvas performance is on average slower than GL.

Really? Even on Firefox? (I’ve found in v3 that canvas works great everywhere, while GL works ok in Chrome but horribly slow in Firefox).

I guess we should have a Trello or something where a public commitment of features could be contributed

There’s already this one: https://trello.com/b/1s2ERKt9/voting-cocos2d-x-wish-list
Althought it’s not really advertised in the forums, and one can only vote, not suggest new items. I don’t know if this is doable in Trello directly without making too much of a mess with permissions. But maybe we could have a “submit feature form” somewhere in this site and have ideas popped in by the community, then regularly go through them and have them add to a coolbox/backlog board in Trello and then have then voted. I think I described it in an unnecessairly complicated way, but just look at how the Brackets team does it for an example: https://trello.com/b/LCDud1Nd/brackets

Well, the current V4 implementation has pathi capabilities. Complex ones i mean. But parsing an SVG is not so straightforward. parsing the paths is one things, but parsing the attributes, etc. is a heavy weight operation. I can’t give a conclusive answer on this.

There are a few projects that do this, like CanVG and FabricJS. I don’t think it’d merit merging them whole into cocos, but maybe the parser and the methods to render into a texture could be imported.

[Ibon]

@ZippoLag @stevetranby
We have just pushed preliminary github pages here: http://hyperandroid.github.io/Cocos2d-html5/
where you can find the JS documentation and some examples.

If there’s some project feature you’d like to see as working demo, please let us know.

• ibon

[stevetranby]

The demos work well. I think I’ll test it out by working to finish my jsbreakouts.org cocos2d-js port. I have a tile-based, custom collision version and I plan to make a physics-based 3.x version (should be quick) and then I’ll do the same with your html v4 so I can determine things that would be great to add.

The work in progress is here (once I add the other versions I’ll push up each version to my fork).

stevetranby/cocos2d-js-breakouts

[ZippoLag]

It’d be nice to have a link with quick access to the source of each example in their sections.

BTW, have you thought about implementing a sort of JSFiddle-like environment so that people can directly mess with the example’s code without having to download or open a single file? I think it’s the kind of thing that works well for attracting new users.

Extra/edit: what are you using for generating the API docs? JSDoc? Or the same that’s used throughout cocos2d-x? (Doxygen)

I’ve had some issues trying to add jsdoc to my projects because the parser runs into cocos2d’s doxygen format and ends up messing some things up. So I currently simply don’t document my code in that fashion at all (lol), but I’d like to be able to. Maybe I could just find a better way to make the jsdoc parser ignore cocos’ files, I don’t know…

[stevetranby]

For example, canvas can’t do efficient tinting while it is almost free to have arbitrary color tint on GL

Interesting. Just looked at the test8.html. I know we tint a lot of sprites in our c++ game, and I wonder if others require or appreciate that feature? Is there a possible solution? Or is tinting a feature that will always be not recommended or disabled in the canvas renderer?

I’ve finally started writing to the engine. It was not difficult to get started, but when I found time I mostly spent it reading through the engine/tests source.

p.s. I’m now interested in testing local multiplayer and network multiplayer testing using two directors. It’s an interesting core change that I know is planned for inclusion in native v4 as well.

[Ibon]

Interesting. Just looked at the test8.html. I know we tint a lot of sprites in our c++ game, and I wonder if others require or appreciate that feature? Is there a possible solution? Or is tinting a feature that will always be not recommended or disabled in the canvas renderer?

For a canvas renderer, tinting means: grab pixels, manipulate and build a new image out of modified pixels, definitely something not suitable for realtime. That’s why tint in canvas is currently disabled.
There are helpers for image tinting though.

I’ve finally started writing to the engine. It was not difficult to get started, but when I found time I mostly spent it reading through the engine/tests source.

Nice.

p.s. I’m now interested in testing local multiplayer and network multiplayer testing using two directors. It’s an interesting core change that I know is planned for inclusion in native v4 as well.

This is something that makes sense on desktop/web for usecases like the one you describe. V4 either native or not, focuses in a redesign from the ground up, mainly ditching the global-accessible unique-instance core components architecture which prevents the engine from having decoupled modules.
E.g. In v4 html5, there will still exist cc.director, but will point to the first created director. it will be deprecated but available for backwards compatibility code.

Let us know what you think about the v4 core and features.

Thanks.

[ZippoLag]

Back to suggessting ideas, I’ve got an addition to my physics comment:

It’d be nice if some wrapper for multithreading/web sockets implemented by default on the physics engines so that all that complexity is hidden from the gamedevs (and hopefully resulting in greater performance).

My reasoning is probably over-simplified (I’ve seen a few examples of this being done, but I don’t have any working example of chipmunk/box2d with webworkers & cocos2d-js ye), but I’m guessing that the messaging system between threads could be black-boxed simply by turning the variables of a physics sprite’s body into properties with getters/setters that handle the messaging with the webworker running the physics engine.

Of course, most of the time it’d be the engine pushing notifications/changes to the sprite’s body, but if the user’s code accesses this properties too often the overhead of this mechanism could prove to be too big?

I don’t know, maybe my whole approach is wrong and I’m just talking nonsense, if so, I’m sorry! '^^

[metalim]

V4 either native or not, focuses in a redesign from the ground up, mainly ditching the global-accessible unique-instance core components architecture which prevents the engine from having decoupled modules.

Does that mean it will be possible to (finally!) use cocos2d-x on multiple canvases, to apply different CSS transformations to them?

[Ibon]

Yes.
Each director has a Canvas, and each one could be in different css3-transformed divs.

[stevetranby]

Visual Studio Code (I call it VSCode, myself) is a new free developer tool. It’s a code editor, but a very smart one. It’s cross-platform, built with TypeScript and Electron, and runs on Windows, Mac, and Linux.

Visual Studio Code - Code Editing. Redefined

Looks like a useful tool for cocos2d-html v4 development
It also uses Electron (formerly atom-shell) and TypeScript, so I’ll definitely be testing it out.

[metalim]

Will there be any kind of module dependency system, to include and compile only used cocos files?
I think of browserify.

[metalim]

Feature request: make it possible to have nodes position relative to parent’s content center, that is: be independent of their parent’s content size.
Reasoning: it is often much easier to position nodes relative to center of their parent, for example treating screen center as position 0,0, instead of recalculating all node positions on resolution change/window resize.

[stevetranby]

position relative to parent’s content center

It’s an interesting request. I’ve often had a similar thought because it seems 3D modelers usually use that method, right? Create a cube and its center is at 0,0,0. Then attach a cube to that cube and it’s center would be at parent’s center? Hmmm, I wonder if the new Sprite3D already works this way?

I’m sure there are reasons in 2D where the current setup is desired, but examples would be interesting to show where it is better to account for parent’s content size and position from the bottom left corner of bounding box. With pixel art it seems easier to just set a character’s layers to 0,0 since they’re all the same MxN size and we want to layer them exactly one on top of the other to get perfect alignment, but then we have to also set the anchor points to 0,0.