Cocos2d HTML5 V4

thomasjab · February 16, 2015, 9:34pm

cocos2d-js = cocos2d-html5 + cocos2d-x

ZippoLag · February 19, 2015, 4:19pm

Oh, I see…

Well, I surely hope that porting from v3.x to v4 is not a big pain. Porting v2.x to v3.x had some minor hiccups, but it was entirely possible, since the API hadn’t really changed that much (aside from the event manager).

But I wonder now: when you say “full rewrite”, do you mean re-implementation of the code or you are also changing the API completely?

I don’t know if things like this are what you are asking about, but if I may drop my dreamed-of feature list (trying to keep it short) it would look something like:

An .svg and a powerfull and flexible line-drawing API that’d let us both use vectorial files as assets (rather than having to have multiple .pngs for different resolutions) with good performance.
A high-level physics abstraction system that’d let us handle objects independently of how they are shown and what engine (box2d or chipmunk) is used below would be nice. A tool for defining collision areas for said objects would be nice too (althought this’d be more of a CocoStudio feature I guess).
Access to the interpolation functions that animations/actions use so that we can use them for animating any kind of values and not just limited to the available functions. Some use cases would be, adjusting volume smoothly, use moveTo-like behaviours on sprites that are currently managed by the physics engine, adjusting some global parameters of gameplay as time proggresses, etc.
A simple method (with good performance) to find out wheter a point in a sprite is transparent or not (for use with mouse clicks/hovers).
Adding a 4th state to buttons (they currently support active, disabled and pressed) to handled a “selected/hovered” state. It’s not required for touchscreen apps, but if you want to support keyboards/gamepads and/or mouse, they add a lot to the look and feel of menues.

All of this things are doable with the current engine, but they are bit cumbersome and it’d be nice if the engine took care of them without burdening the game developer.

Thanks a bunch!

PS: do let us know when there’s a repo that we can look at!

Ibon · February 20, 2015, 4:02pm

Well, I surely hope that porting from v3.x to v4 is not a big pain. Porting v2.x to v3.x had some minor hiccups, but it was entirely possible, since the API hadn’t really changed that much (aside from the event manager).

But I wonder now: when you say “full rewrite”, do you mean re-implementation of the code or you are also changing the API completely?

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.

An .svg and a powerfull and flexible line-drawing API that’d let us both use vectorial files as assets (rather than having to have multiple .pngs for different resolutions) with good performance.

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

A high-level physics abstraction system that’d let us handle objects independently of how they are shown and what engine (box2d or chipmunk) is used below would be nice. A tool for defining collision areas for said objects would be nice too (althought this’d be more of a CocoStudio feature I guess).

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

Access to the interpolation functions that animations/actions use so that we can use them for animating any kind of values and not just limited to the available functions. Some use cases would be, adjusting volume smoothly, use moveTo-like behaviours on sprites that are currently managed by the physics engine, adjusting some global parameters of gameplay as time proggresses, etc.

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

A simple method (with good performance) to find out wheter a point in a sprite is transparent or not (for use with mouse clicks/hovers).

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.

Adding a 4th state to buttons (they currently support active, disabled and pressed) to handled a “selected/hovered” state. It’s not required for touchscreen apps, but if you want to support keyboards/gamepads and/or mouse, they add a lot to the look and feel of menues.

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

PS: do let us know when there’s a repo that we can look at!

have a look at this: early pre-alpha code, currently writing wiki and pushing examples to github pages.

Ibon · February 20, 2015, 4:06pm

The Cocos2d-html5 V4 project, in its current state, is only web targeted, or targeted natively using native standalone wrappers like X-Walk, CocoonJS or Phonegap to name a few.
It is much like the Cocos2d-htm5 lite in V3.
Some features from this V4 project, will make it to the Cocos2d-x project, like the advanced layout capabilities for example.
We expect to have this V4 (as the rest of the Cocos2d suite) community driven so would love to get all the feedback possible in this early stages.

Hope this sheds some light on why V4 as is.

Ibon · February 20, 2015, 4:21pm

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 · February 20, 2015, 5:23pm

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).

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.

I love you (platonically).

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?

Awesome.

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 · February 20, 2015, 9:26pm

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 · February 24, 2015, 9:04am

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 · February 24, 2015, 9:05am

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

ibon

Ibon · February 24, 2015, 9:37am

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 · February 24, 2015, 2:24pm

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).

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

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 · February 24, 2015, 9:46pm

@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 · February 24, 2015, 10:14pm

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).

ZippoLag · February 25, 2015, 3:49am

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 · March 31, 2015, 7:15am

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 · March 31, 2015, 10:16am

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.

Nice.

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 · April 16, 2015, 1:51pm

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 · April 28, 2015, 8:05am

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

Ibon · April 28, 2015, 10:35am

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

stevetranby · April 29, 2015, 11:11pm

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.

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.