ND2Dx benchmarks

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


I promised a few benchmarks of ND2Dx and here they are. The flash movie and the complete source code can be found at the end of this article.

There are 4 benchmarks, comparing ND2Dx and Starling. Basically, I keep adding sprites, bitmaps or movieclips while the frame rate is equal or above 60 frames per second.
I’m using Hi-ReS-Stats for the frame rate monitoring. And as it calculates the frame rate every second or so, items might/will be added while the frame rate is actually lower than 60. So you might have a frame rate dropping straight to 52 for example. This is not an extremely precise benchmark but it still gives you a good overview of what ND2Dx is capable of (in terms of performance).

It is important to note that I’m using a specific batching technique (in ND2Dx) for this purpose.
Also, I know I announced more than 17000 sprites on a previous post but this was compiling the flash into an AIR app (more than 14000 is not too bad either)

Sprite2D vs. Bitmap

Very basic benchmark where items (sprites and bitmaps) rotates.
In ND2Dx, the pivot point of every textured node is centered by default, while in Starling, the pivot point is at 0,0 (top left corner) by default. This is why you will see a difference in how objects rotate in the flash movie below. This has no impact on performance.

The results:
ND2Dx Sprite2D: +-14500 sprites
Starling MovieClip: +- 5000 sprites

It is also important to note that I’m using the ENTER_FRAME event in Starling to rotate each bitmap based on the elapsed time between frames (“passedTime” var in Starling event). This is how it is said to be done, but there is a far better way (performance wise) to animate an object. The event dispatching is taking lots of resources but it seems to be the only way to access that “elapsed time” value that I think is very important when you want to make games. I quickly tested it without using the ENTER_FRAME event and it gave far better results for Starling (around 11.000 I think) but without the “elapsed time” feature. I didn’t have time to make a proper benchmark for that but you now know that it more than doubles the perfs of Starling…

Sprite2D with animated texture vs. MovieClip

Same same but different: the texture is “animated”.

The results:
ND2Dx Sprite2D with animated texture: +- 11500 sprites
Starling MovieClip: +- 3300 sprites

Test it yourself

And don’t hesitate to post your results in the comments.

Get Adobe Flash player


And the complete source code as usual:
box_zipND2Dx Benchmark source code

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


  1. Scott Enders

    Oh wow, very impressive

    Image – A bit over 12,000
    Sprite2D – Over 30,000

    MovieClip – Just shy of 6,000
    Animated Sprite2D – Over 24,000

  2. I got very interesting results on a laptop with a cheap processor. I don’t know exactly the config but Starling actually was slightly better than ND2Dx… probably that the settings I’m using for the current batching in ND2Dx is quite GPU intensive as I send 1000 sprites on the GPU at once (so every batch contains 1000 sprites)

    I’m still working on the engine, I’ll make a couple more tests and probably add a Starling benchmark without using the ENTER_FRAME event which causes a big decrease in performance.

    thx for passing by 🙂

  3. Elliot Geno

    I’ve always heard ENTER_FRAME was faster too. Is this a rumor? What do you use as an alternative? setInterval();? Wouldn’t that produce skipped frames?

  4. @ Elliot Geno: in general, using events in flash is not the fastest solution at all (the concept is great, but it is not made for resources intensive computations). For example, Signals are more powerful in terms of performance (see my other benchmarks). As for Starling there is a much more powerful way of updating DisplayObjects: instead of using an ENTER_FRAME event in each single object you need to update, put all of those objects in a vector (or a linked list, it is even faster) and call their “update” function (you will need to create one, in ND2Dx, it is the “step” function) every frame. Of course you will need at least one listener to the ENTER_FRAME event in order to call the “update” function every frame.
    If the ENTER_FRAME solution in Starling takes so much resources, it’s because we need to listen to it for every single object we want to update on a frame basis. The more listeners you have, the more resources it will take to dispatch an event for each one of them. The problem is that the whole structure of Starling is implemented that way. Same for animated textures (MovieClip). And also, the only way (to my understanding) to get the elapsed time between frames is through listening to the ENTER_FRAME event (“elapsed time” is a very important thing to me :))

  5. Hi Thomas,

    I understand ND2Dx is a fork of the original ND2D. I’d be very interested to try it out.
    Do you have a github repo for your ND2Dx engine?

  6. @flexwiz: yes, it is a fork of the original ND2D (while there are huge changes, it still keeps the same kind of philosophy)
    and for the github: not yet :)… but I’ll definitely post it on github when I finish the final state machine I’m working on (integrated in ND2Dx).

  7. Brad

    ND2Dx Sprite2D: 46,980
    Starling Image: 10,140

    ND2Dx Sprite2D with animated texture: 25,910
    Starling MovieClip: 6,290

    Core i7-4820K @ 4.2 GHz
    Radeon 6870

  8. Greg

    Impressive, would certainly be interested when ND2Dx is available on github.

  9. Jake

    Substantially different for a 5 year old Mac Mini (in Firefox)
    It generally works in gpu applications, though these number make one wonder of it’s in a software mode.
    Intel core 2 Duo, 2.4ghz
    NVIDIA GeForce 320M 256mb
    Flash Version

    Sprite2D – 3390
    Animated Sprite2D – 2240

    Image – 5260
    MovieClip – 2880

    The Apple-Oranges result from Genome2D benchmark NPAPI, no Debugger.
    Genome2D: 24,600, Starling 10,600

  10. not sure but I think it’s in gpu mode because in one of my comment above, I tested it on a very basic laptop and I had similar results (starling being better than nd2dx)
    I suppose it has to do with the batching technique (which is quite gpu intensive in nd2dx, probably more than in starling I would suppose) and the probably old and/or low end gpu that you have. In the original nd2d, there was another batching technique in which calculations were more based on the cpu than the gpu (I have implemented it in nd2dx as well but haven’t tested it yet)

    as for the genome2d vs starling benchmark, the test doesn’t use the display list… instead, in genome2d, it uses a “direct gpu drawing” technique (http://blog.flash-core.com/?p=3132), and in starling it stores all the objects that need to be rendered in a vector and render them one after the other (thus removing the burden of the display list architecture and, probably more importantly in terms of performances, the need of the ENTER_FRAME event)

Leave a Comment