Performance: in fairness

Here are my results (desktop only, always displaying sprites):

(typo on the GPU, ram is GDDR5 not DDR5)

Proof:

Chrome -

NWJS 32bit -

NWJS 64bit -

Godot -

Unity -

Built files: https://dl.dropboxusercontent.com/u/471 ... esults.zip

C2 HTML5 Bunnymark test: https://dl.dropboxusercontent.com/u/471 ... index.html

Direct X Diagnostics:

So in plain text:

C2 on NW.JS v244 - 3500 bunnies 50 or 55 fps (32 bit vs 64 bit)

C2 v244 on Chrome - 3500 bunnies 55 - 57 fps

Godot Engine v2.1.3 stable - 8470 bunnies 55 - 60 fps (heavier dips when spawning, settles back out to roughly 60 fps)

Unity Engine v5.6.0f3 - 16321 bunnies 56 - 58 fps

Also just out of curiosity, since Unity also offers WebGL exporting.

Would you mind providing performance stats for that as well?

Might be interesting to see how Unity's WebGL export performs, compared to C2's.

Good question! Here's my results:

Unity WebGL in Chrome

Bunnies: 5501

FPS: 57*

*That's not the constant FPS though, it would fluctuate between 54 and 65 quite a bit, with the occasional HTML5-usual jank, especially when spawning more.

Unity WebGL Build export: https://dl.dropboxusercontent.com/u/471 ... index.html

Out of further curiosity I gave Firefox a try with the Unity WebGL and got these results:

Unity WebGL in Firefox

Bunnies: 8331

FPS: 55 - 56

The same C2 bunnymark test in Firefox gave me some crazy (good) results:

Bunnies: 11370

FPS: 55 - 56

So, it seems that Firefox is the only browser / browser engine right now getting *close* to Unity speeds on my PC, which tells me that probably Firefox is falling back to DirectX / ANGLE, Unity is using "real" DirectX calls, and everything else is using OpenGL? (mega-guessing here <img src="{SMILIES_PATH}/icon_e_surprised.gif" alt=":o" title="Surprised"> )

Jayjay - awesome results! Fascinating that your Godot tests ran better than NWjs - the opposite of mine - were you using the latest version of NWjs v22? I found that v20/21 performed far worse on my lowly machine.

My Unity WebGL results:

render: 3500

no render: 9500

PS - how did you render html5 using dropbox?

I thought I was getting better results earlier.

C2 in chrome:

60fps till 800

60fps till 2900 with the "for each" disabled

godot:

60fps till about 800 as well.

I think what's being measured from this is the speed of events or gdscript.

Looking at the bunny mark here:

https://pixijs.github.io/bunny-mark/

I get 60fps up to 5900 with the chrome

and this:

http://www.goodboydigital.com/pixijs/bunnymark/

gives me 60fps up to 20,000. I guess js isn't actually that slow?

and this:

http://www.goodboydigital.com/pixijs/bunnymark/

gives me 60fps up to 20,000. I guess js isn't actually that slow?

Amazing! I get 40000 bunnies before a slowdown in Chrome...!!

Woah, that was a huge gap.

C2 in chrome on my iMac

Unity WebGL on my iMac

Pixi in chrome on mt iMac

5000 vs almost 200.000 both are webGL, it's not even a fair comparison? What makes one so much faster than the other... that's what I would like to know. But after all the C3 sales, maybe he can hire someone to optimize and bump those numbers up.

I think what's being measured from this is the speed of events or gdscript.

Maybe, but there seems to be something in C2 eating all the resources. Overhead, draw calls, who knows?

Impressive, I actually reached over 100 000 bunnies before I got a slowdown and that slowdown was only during spawning so could probably mantain 60fps with a lot more bunnies.

And now for the phone results. Nokia Lumia 830. Pixi does way better again.

C2

UnityWebGL - Not even working on phone.

Pixi

I don't know what it is, but there's something Pixi is doing that seems to be superfast. about 10x-20x faster than all other webGL I've seen.

It's free and opensource, so I hope C2/C3 can take advantage of it in the future

http://www.pixijs.com/faq

https://github.com/pixijs/pixi.js/blob/dev/README.md

You can't argue with Pixi's performance, simply amazing:

Would be very interested if C3 can take advantage of whatever magic is allowing this

Wtf

I gotta say pixi.js blew me away. The few long drops are when I change tabs (it seems to idle at 30fps), but when it's not creating bunnies, it runs at more than 50FPS and it's pretty stable.

AFAIK C2 has a similar WebGL batching engine to Pixi. I think the main performance difference when you get in to the tens of thousands is just hand-written dedicated JavaScript vs. the event engine overhead. C2's engine also does a lot more work: for example it makes the assumption you will be using collisions so it shares the rendering vertex data with the collision engine so it doesn't have to be re-computed, but this adds a bit of extra overhead. So we could probably make some similar optimisations if we entirely removed the collision engine, but then it's not a very useful game engine any more!

Benchmarks are only useful to a point - I mean if you can hit 5000 moving on-screen sprites at 60 FPS, how many games are going to need more than that? A good way to think about the overhead is the per-sprite time. 20000 sprites 60 FPS means it can render 1.2 million sprites per second, or about 833 nanoseconds per sprite. If that's improved to 30000 sprites 60 FPS, it means the overhead per sprite has reduced to 555 ns, saving about 278 ns per sprite. This is very much microbenchmarking, and improvements like this can take a long time, and yet bring no meaningful performance improvement to real-world games.

You can't argue with Pixi's performance, simply amazing:

Would be very interested if C3 can take advantage of whatever magic is allowing this

Yeah, If C2/C3 could implement whatever voodoo, witchdoctor, hocus pocus they are using for Html5/webGL performance, Construct would slap all other 2D engine competition on the fingers big time. :p

Right now Construct is pretty much on par with most html5/webGL solutions i've seen out there I think, but pixi.....is just ..... mindblowing.

I mean if you can hit 5000 moving on-screen sprites at 60 FPS, how many games are going to need more than that?

It's ok on desktop, but html5 for those of us who develop for mobile.... we need some of this kind of optimizations. I think Ashley is assuming that everyone doing mobile games want to do flappy bird clones with max 100 sprites on screen for decent performance.

This is pretty much what a midrange phone can handle.

Mobile test:

-PixiJS: 3800 bunnies at 29 - 30fps on Chrome browser LG G4 (6000 at 26fps)

-C2: 630 bunnies at 26 - 32fps on same device as above

-Unity WebGL: does load after warning, does not scale to fit, does not recognize touch, 11fps in portrait with starting bunny count

PixiJS Bunnymark desktop:

Firefox 76200 bunnies at 50fps

Chrome 75400 bunnies at 44fps

Allowing Unity native to hit as low as 30fps I get 28761 bunnies, so it seems PixiJS has some great optimizations either in sprite batching or in the code behind it (I haven't tried optimizing the Unity version at all from the OP's git account)

If you test C2 please make sure you replace the "For each" condition with "Every tick", otherwise it's needlessly inefficient. The github hosting the examples still has the unnecessarily slow "for each" version.

So I looked in to Pixi's code to see how they're rendering those bunnies, and it turns out they use a similar rendering technique to the particles object. So I made a similar test in C2 using the Particles object instead, and you can get similar performance gains.

Testing on a HTC 10:

Sprites: https://www.scirra.com/labs/c2bunnymark/ - ~5500 30 FPS

Particles: https://www.scirra.com/labs/c2bunnyparticles/ ~31000 30 FPS

Particles are super fast, over 5x faster at rendering! It's magic! Well, not really - particles are a really limited case so we made special optimisations to render them faster, much as Pixi's bunnymark does. They're too limited to work for general purpose sprites. Also like bunnymark, particles don't process collisions at all, so that overhead is removed. So this idea that we can magically make everything faster by rendering sprites like particles isn't really feasible.

Ashley Yeah it looks a bit better now. I got 740 bunnies 30fps on the same phone, with the old C2 test i got 300 30fps. Although I could wish for a bit more as Pixi's bunnymark was close at 8000 bunnies 30fps. Although my phone is quite weak. 2 year old midrange phone. (Nokia Lumia 830)

Would be curious to see if there's any difference in C3 vs C2.

C2 bunnymark - Updated. 740 bunnies 30fps

C2 bunnyparticles - 2000 bunnies 30fps

Pixi Bunnymark - 8000 bunnies 30fps (I know pixi is cheating a bit by rendering at windowsize/2) If you look closely it's pixellated. not 1:1 pixel density.

Setting the render scale in runtime for lower/midrange phones would be nice, and maybe some other tweaks, so we don't have to design the game for low and phones, and scale up, for powerful phones. Some mobile specific tweaks would be nice. Maybe a windowsize/2 option would be good for mobiles, as they have really high pixel density, and you don't really see it.

I'm currently recreating my game and all assets optimized for 640-360, upscaling to 1280x720, to save some memory and a bit performance boost for low-mid range phones.

I hope you will get some time at a later point to investigate some further improvements to get a bit closer to the pixi score. (Maybe just mobile specific tweaks) I think it's quite important for us doing mobile games, as we could lose a whole segment of users, and bad reviews if we can't get good enough performance on midrange phones. Keep it up!