ND2Dx: a few optimizations and a couple of examples

0 Flares Twitter 0 Facebook 0 Google+ 0 Pin It Share 0 Email -- Filament.io 0 Flares ×

Hello

It’s been a month since my last post, I have a big thing going on at the moment that has nothing to do with computers, so…

Anyways, I still am working on ND2Dx as well as the game IDE. Here are a couple of changes/optimizations that I made recently in ND2Dx, as well as a couple of examples:

The RenderSupport system

Rendering goes through a rather simple system that allows me to add batching wherever I want to in the hierarchy of my scene. In order to do that, I had to build a RenderSupport system that will contain all the data and the logic to render nodes. Each RenderSupport has it’s own way of processing the rendering.

This system has also imposed itself due to the use of components for rendering.

The reason why I write about this now is that I had to make a couple of changes so that everything fits together in a nice and flexible way. Now you can either have one RenderSupport object for the entire world, or just for a specific scene or even just for a specific node, mixing them inside the hierarchy without any problem (hopefully ;))

MainRenderSupport

Is the main and by default RenderSupport object. What it does is simply take the Material object of a Mesh2DRendererComponent and call its render method (as a remainder, an object needs a Material to be rendered)

Texture2DMaterialBatchRenderSupport

Big name, but what we have here is a RenderSupport object that batches objects in a single drawcall. This one only accepts objects that are using Texture2DMaterials (hence its name). Its size is constrained by the number of shader constants we can send on the gpu per drawcall (17 at the moment)

Texture2DMaterialCloudRenderSupport

Like the “batch” one but is called “cloud” (remain from ND2D). This one is limited by the size of the vertexbuffer we send every frame to the gpu. So this one really depends on the system you’re running it on. On my system (quite old, still under Vista… I know…) I can go up to 10.000 sprites per drawcall. This one seems to be the most efficient batching technique on desktops with “normal” gpus (not the one that is shipped with the motherboard). I haven’t compared the two of them on my IPad2 though.

ScissorRectangle or ScrollRect

ND2Dx now fully supports ScrollRect (Scissor rectangle) inside every node. You can even mix nodes that have ScrollRects inside other nodes with different ScrollRects (see the examples for a better understanding)

MouseEvents and Mouse propagation

Also something I had to redo as it didn’t really fit my needs. Now you can listen to mouse events on every node as long as they (and their parents) have enabled it.
The property “mouseEnabled” enables or disables mouse inputs on the node. While “mouseChildren” specifies whether children should be checked for mouse inputs. So you can have a node with mouse disabled but its children will be able to listen to mouse events.

Mouse events propagate through node’s parents. You can prevent that of course if you need to (either permanently or for each event).

The different mouse events you can currently listen to: MOUSE_MOVE, MOUSE_OVER, MOUSE_OUT, MOUSE_DOWN, MOUSE_UP, MOUSE_CLICK and last but not least RELEASE_OUTSIDE (happens when you press the mouse button on a node and release it outside of that node)

Examples

And now the examples: multiple RenderSupport, CloudRenderSupport, BatchRenderSupport, ParticleSystem, MouseEvents, multiple ScrollRect, animated textures, particles with animated textures :

Get Adobe Flash player

 

Github has been updated as well with the new changes.

0 Flares Twitter 0 Facebook 0 Google+ 0 Pin It Share 0 Email -- Filament.io 0 Flares ×

2 Comments

  1. Francis Bourre

    Really nice work, congratulations !

  2. simon

    I love it 😉

Leave a Comment

*