Backward compatible Core nodes: Node, Scene, Director, Sprite.
These nodes have improved functionality compared to the V3 ones.
For example, Node can redefine is draw method to augment its capabilities and transform a Node into a LayerColor,
or LayerGradient. Layer will be deprecated. These Node objects are backwards compatible with its V3 counterparts.
Still cc.Node, cc.Scene, etc. can be used.
Actions system.
Actions have been redesigned from the ground up.
They offer a comprehensive lifecycle notification mechanism and have a new chaining syntax.
This new Actions subsytem is backwards compatible with V3 and V2 Actions API. There’s an V3/V2 Actions test which
showcases and guarantees the compatibility.
Easing system.
Compatible with V2/V3 easing system. There’s an V2/V3 easing compatibility test.
In the new implementation, the Easing Action has been promoted to an Action attribute instead of an Action. The V3
concept of Actions applying indistinctly to Nodes or Actions was not clear.
Scheduler.
The scheduler has been integrated into the Actions system.
It is fully compatible with V3 scheduler system. There's an V3/V2 Scheduler test which showcases and guarantees the
compatibility.
Atlas.
We have a more advanced Atlas system than V3 has.
It supports Atlas deep-nesting operations (atlas containing other atlases).
It is the foundation for Sprite animations as well as SpriteFonts.
Atlas objects can be loaded from a TexturePacker tool JSON or Cocos2D output.
It is also able to read a Glypth Designer tool output to build a sprite font.
Atlas elements will automatically be available as SpriteFrame objects.
Rebuilt SpriteFrame object.
Now there’s no need to extract rotated frames into independent images. This was a costly operation that ruined
batching system.
SpriteFrames can create new Frames on-the-fly from their own extends.
Screen resolution independence
Cocos2d-HTML5 v4 allows to decouple the mapping between a pixel and an in-game measure unit. This is great for retina
display support and content conformation to every screen-resolution. See demo text/engine/units.html.
Texture packing.
The engine offers the possibility of building sprite packs on-the-fly from loaded images.
This will dramatically improve rendering capabilities.
Currently the packer is not dynamic, you can’t add/remove images at runtime, but it is expected it will.
It is optional to use, but very convenient nonetheless.
The packer is able to pack complete Atlas objects
Modular Loader objects.
The Loader has a extension-to-resourceType loader hierarchy.
New types of resources can be registered by supplying a new factory setting.
Currently there’re loaders for: image, text, json and plist.
Detachable renderer.
The new renderer integrated in Cocos2d-HTML5 V4 is completely decoupled from the Nodes' drawing logic.
It is straightforward to build a new Node type (overwrite the draw method and use the RenderingContext parameter it
receives).
It also maintains (if needed) internal webgl state, so it is safe to share the gl context with the external world.
The renderer is Canvas and WebGL capable and offers consistent rendering capabilities. Both canvas and WebGL renderers
can be leveraging by exposing the CanvasRenderingContext2D and WebGLContext respectively.
The renderer allows to define one time rendering vertical axis orientation, either 'bottom' default, where y=0 is
at the bottom and grows upwards, and 'up' where y=0 is on top and grows vertically (this is canvas' renderer default).
Path.
Cocos2d-HTML5 V4 has full path capabilities.
It allows to build complex path objects. Though polymorphically a path is treated as a Segment,
Internally the Path is a collection of Container Segments.
Each segment can be a line, bezier, cubic, cardinal spline, arc or rect.
This allows for complex path traversal using a PathAction, and will be foundation for complex path tracing in the renderer.
Modular input system.
Currently there’s support for touch, mouse and keyboard.
The keyboard recognizes complex keyboard sequences that can be defined by key name.
The input system has been redefined from the ground up, offering a more natural way of adding input capabilities to
nodes like the method addEventListener( “”, callback ): which is widely known.
Fast WebGL rendering.
A new Node type, FastSprite, has been added for delivering thousands of sprites to the screen.
FastSprites are limited version of Sprite. They are not supposed to have children, and are not supposed to have
input routing capabilities. They are suitable for example for Particles.
Transitions.
For managing scenes, there’s also transition support.
Though (not yet) all the transition types are available in V4, it is fully compatible with V3 Transitions.
Widgets: only a Button widget is available. Though there’s no Label widget available, a call to drawText in the
Rendering Content can be performed any time, offering a basic Label component that renders a Font object.
Centralized AssetManager.
Cocos2d-HTML5 V4 makes a distinction between Resources (data loaded) and Assets (data produced from assets).
For example, an Image object is a resource that is eventually turned into a (webgl enabled or not) Texture2D object
and a SpriteFrame on that texture. Or for example, a '.fnt' file is a text resource that is turned into a SpriteFont
object by combining a SpriteFrame, a Texture and the .fnt file contents.
If offers a name based cache system for all in-game resources: textures, sprite frames, animations, fonts, etc.
Typescript
The engine is originally written in Typescript, and later transpiled into JavaScript.