Peter Yu: Thanks.
You will need to do some cosmetic changes in your code, like remove the
CC prefix from the classes.
However, if you are overriding the
draw method, then you will need to update the code a bit. The new API for
draw is not defined yet, but it won’t be backwards compatible.
Nick Verigakis wrote:
I like the idea of static layers, but I’m not sure about unordered and batched layers. From what I understand batched layers are going to do the exact thing that sprite batch nodes do without any added convenience
yes. static layers will replace sprite batch nodes.
In this article http://realtimecollisiondetection.net/blog/?p=86#comment-3601 there is a very nice method for sorting rendering commands based on a key that encodes their rendering state. Using a system like that every command that is added to the CommandQueue would be a key-value pair. So when a Node sends a rendering command it would have to create a 64-bit key that encodes the following information in the following order:
Interesting article. Thanks.
In the new renderer we will try to add the standard 3d best practices, because we want the renderer to be scalable to a 3d game. But in 2d games, some of the 3d best practices are not applicable.
For example, most 2d games use Z=0 for all its nodes, but the z order of the scene graph is super important. And 90% of the objects are semi-translucent. So doing auto-batching is not trivial for 2d games. And that’s why we added some “hints” to the layer.
Some other suggestions:
• The rendering back-end (or in fact any other object in the engine) should not make OpenGL calls directly. Instead a GraphicsDevice object could be used that maps all OpenGL functions (and it’s implementation could be replaced for DirectX functions).
We were planning to do something like that. The new renderer should be easy to port to other DirectX, and other GPUs.
• The rendering back-end should not do the sorting of the rendering commands. This should be handled by a front-end that also handles culling. In this way the back-end will try to send as many graphics calls as possible to the GPU.
• The rendering front-end could be responsible for creating texture atlases for nodes that use the same texture (auto-batching). If a node changes it’s texture or it’s blend settings it should be removed from the atlas (I’m not sure if this is expensive though).
thanks. We started to evaluate that, but we haven’t found a way to auto-generate texture atlas without performance issues.
Our current plan is to have a function that creates a texture atlas from the nodes of the graph (or sub-graph).