Edit: if you want to see the current state of the source code of ND2Dx, I invite you to check the game tutorials I’m currently writing using ND2Dx: part1 & part2. My intent with those tutorials is to show how to make a game and explore the inner workings of ND2Dx.
It’s not yet stable and still under development. A couple of features are missing but the point of this framework is to limit those “base” features to a minimum and allow adding them easily via a simple technique named: component entity system.
Component Entity System
For those who don’t know, a component entity system is kind of like a plugin system where you have one common object (the entity) in which you add components that will enhance that object. The idea is to have a very flexible system where you can add, remove and mix components together without having to create extended objects of our common one (our base entity) and hard code those features you want in it. This allows for very simple re-usability and clean code.
In ND2D, our common object (or entity) is Node2D. It is a very basic object that acts like a DisplayObjectContainer in flash. It has transformation properties (x, y, scaleX, scaleY), color properties (alpha, tint), can contain components and as said before, acts as a container for other Node2D objects.
It is a very basic approach that allows for endless hierarchy.
So how ND2Dx works ?
Very easy 🙂
The base of all is Node2D. It’s an object that will do all you need it to do in order to show things on screen, or not. It doesn’t have any information of what to show and how (except for transformation and color, that has to be set in that object in order to update its children more easily), yet. It’s just a container that can contain itself as well as components.
In order to show something, you will need to add a MeshRendererComponent (concept taken from Unity) that can contain a Material and a Mesh2D object. The Material object holds the texture and shader data. The Mesh2D object holds the vertices that will make the triangles required to show something on screen.
Biggest changes from original ND2D
- Component entity system: it allows to have only a base object that don’t need to be extended (it can but it’s not necessary to add new features)
- Mesh2D object: the mesh data is completely separated from anything and can be reused for different objects with different transformations (less memory usage)
- MaterialBase: uses Mesh2D and can now also be used by different objects. A couple of changes were also made to allow for more flexible batching.
- Texture2D: can now have subtextures (atlas). No need for TextureSheetBase, TextureAtlas, … anymore.
- RenderSupportBase: now the drawNode function only take one parameter: a RenderSupportBase object that will handle the rendering of the objects. This object can be extended to allow for different kind of batching (simple batch, cloud batching, custom mesh batching) and also allows for batching without having to use specific Node2D extended objects.
- AnimatedTexture & AnimatedTextureComponent: replaces TextureAnimation and all related objects. The material doesn’t need to handle animations anymore. This is all handled by the component.
When a framework targets game development, performances are very critical. I had a couple of doubts when I started to add the component system to ND2D. Adding such a system will undoubtedly add function calls and sending of variables here and there that will increase the cost in performance of the overall system. But I was really surprised when I ran my first benchmarks. I then added a couple of different batching techniques to the framework and got pretty impressive results compared to Starling.
This is a cloud batching technique taken from the original ND2D framework and adapted to the new ND2Dx. It is of course not suited for all uses but for most of them. On top of that, I removed the original restriction of the cloud batching allowing now the children of each node to be rendered and batched all together. Sprites are not animated.
ND2Dx: more than 17000 sprites
Starling: +- 9000 sprites
For animated sprites, I have:
ND2Dx: more than 11700 sprites
Starling: more than 3900 sprites
Those tests are not real case scenarios but they already show that ND2Dx is faster than Starling by a large margin.
Of course, every batching technique has its pros and cons. The cloud batching involved here only allows for batching quads with a specific set of attributes (no alpha and tint) but the RenderSupport system allows for more specific batching system handling different needs. A cloud batch with alpha and tint has already been developed but needs more tweaking in order to achieve the best results. I can already say that it’s a lit bit slower than the current one but still is faster than Starling.
The complete source code will be available soon.