Native Desktop Exporter for Construct 3

Honestly, it seems like we are seeing a recurring theme here: the 'major' C2 devs (people like Aurel and sqiddster who have made large, polished games that took a ton of time and work, and are being deployed as commercial projects) are saying that they won't be using C2 for future large projects. Not because of issues with the editor, or even performance in general, but because of two things that Scirra cannot realistically do anything about:

1. Depending on a browser engine (basically, chromium) for export, which could very well break and not be fixed, given that HTML5 games are hardly a priority for Google. 2. Console export. Aurel has as much as admitted he's been approached with high$ offers for Penelope on consoles, and had to turn them down.

Most other users are making comments about performance. I don't think that is a serious issue.

C2, unhampered by faulty exporters, as already extremely fast on PC, and will continue to improve, as it has done for the past 4 years. ASM.JS, SIMD.JS, better support for parallelism...all of these are coming and will benefit C2/3 tremendously. But honestly, most performance issue fall into 3 categories: Poor design, unrealistic expectations, or blaming C2 for faults in the given browser/exporter in use.

So performance will improve...but we will still be using browser engines. And we may never be able to export to consoles this generation.

I think this is a time to adjust our expectations and understand where Construct fits among the available ecosystems. The only reason we have this amazing software, which doesn't cost a mint, is because of all the open source components it is built upon (chromium being one, in that's it's our sole option for desktop export).

Ultimately, this means that the direction Scirra takes, and the perception of Construct, good or bad, is ultimately in the hands of Google, Mozilla, and Microsoft. Three massive organizations who may or may not care about their engines mucking up all our work.

That's the state of things, good and bad.

Even after 4 years, we are still on the cutting edge. Sometimes the cutting edge makes you bleed.

So...on a less serious notes, I took a look at Pixi.JS. Holy smokes...it is fast. Take a look at this:

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

I get 2200 bunnies on my (not very powerful) android device before it goes <60fps, and on desktop I get ~25,000 before it goes <60fps. Wow. <img src="{SMILIES_PATH}/icon_eek.gif" alt=":shock:" title="Shocked">

Yeah, Pixi is really awesome..

Because this, the famous Phaser Framework http://phaser.io/

uses Pixi for the rendering.

So...on a less serious notes, I took a look at Pixi.JS. Holy smokes...it is fast. Take a look at this:

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

I get 2200 bunnies on my (not very powerful) android device before it goes <60fps, and on desktop I get ~50,000 before it goes <60fps. Wow. <img src="{SMILIES_PATH}/icon_eek.gif" alt=":shock:" title="Shocked">

Well, it had to be done: https://dl.dropboxusercontent.com/u/132 ... index.html <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

I tried to keep the behaviour similar but there's a good chance they used something custom and optimized - if anyone wants to improve this as much as possible do go ahead:

[attachment=0:3niqzi4a]DevilMark.capx[/attachment:3niqzi4a]

Results so far are not as impressive as Pixi's - I can get about 12000 DevilMarks before dropping under 30 fps...

Edit: Export updated to TiAm's first improved version

Actually, let me adjust the numbers:

On pixi.js I get ~25,000 bunnies in chrome before <60fps. This is going fullscreen in the current chrome stable.

With Somebody's DevilMark (Love it ) I get ~15,000 devils onscreen before slowdown in an NW 10.5 export.

With a node-webkit 10.5 export of my own modification to devilmark (Clear Background = Off, Pixel Rounding = Off, Devil size to 32x32, fps readout to separate layer to avoid z-sort overhead) I get...

~22,000 devils onscreen before slowdown.

However, the cpu usage is quite different, with devilmark using ~28% cpu, and bunnymark using ~15%.

Anyway, I don't think these are exactly comparable tests, but...

Here's my mod of the test:

https://www.dropbox.com/s/qg2mp4c07ka38 ... .capx?dl=0

Here's my mod of the test:

https://www.dropbox.com/s/qg2mp4c07ka38 ... .capx?dl=0

Cool, updated the export. Guess our task now is to optimize events or behaviours until it works the same as theirs and performs as good or better <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Every tick text to fps is going to eat a little cpu.

Every tick text to fps is going to eat a little cpu.

Well, they even have a neat little graph so it probably evens out...

So...on a less serious notes, I took a look at Pixi.JS. Holy smokes...it is fast. Take a look at this:

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

I get 2200 bunnies on my (not very powerful) android device before it goes <60fps, and on desktop I get ~50,000 before it goes <60fps. Wow. <img src="{SMILIES_PATH}/icon_eek.gif" alt=":shock:" title="Shocked">

not really a fair comparison, the picking system in C2 has a very real overhead, while this engine is doing very little besides Iterating many objects that are part of an array. The picking system makes development in construct simpler in a lot of cases and changes workflow greatly from other engines. Animating sprites and doing nothing else is a benchmark but it doesn't really mean anything. You could push some vertices/faces/attributes buffer onto the GPU and animate millions of sprites on a normal machine without a hiccup, but it isn't something that can be used in a game engine, unless you write all the logic for the GPU and control things cleverly through uniforms.

Game engines are extremely complicated and writing "fast" code for modern architecture requires a lot of skill and talent. It'll always be this way, as computers get faster people will say "well this game designed by 1000s of people with a million dollar budget can run on my computer, so why can't I have a million sprites at once in my engine not built for this use case?". People are complaining about something which isn't really an issue, it's just a fact. A native exporter wouldn't really give you the magical improvements you expect. There are tons of ways to get native games out there, and construct 2 isn't the best one, thats a given. It is however the best html5 engine right now, and i feel a native exporter would make construct 3 a jack of all trades but master of none, unless scirra took on a huge big risk hiring extra employees, and raising the price of C3 significantly. At that point they'd be competing with unity and would be fighting a loosing battle against an established product which people will have a subjective bias towards being "better" than C3 even if C3 was objectively a better product.

Every tick text to fps is going to eat a little cpu.

Not for spritefonts.

> Here's my mod of the test:

>

> https://www.dropbox.com/s/qg2mp4c07ka38 ... .capx?dl=0

>

Cool, updated the export. Guess our task now is to optimize events or behaviours until it works the same as theirs and performs as good or better <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

New version w/ event based logic(much closer behavior to actual bunny test):

https://www.dropbox.com/s/ajkt6byja99ud ... .capx?dl=0

Here's an export to test in the browser of your choice:

http://unknownenterprises.altervista.or ... index.html

With this one I top out closer to 15k sprite before <60fps in node-webkit, 12.5k in chrome stable. Event system overhead I imagine.

QuaziGNRLnose

Actually, I think this shows that C2's renderer is already pretty damn good. Maybe it could be better, but, as you say, it's competitive to a blazing fast renderer that isn't having to deal with the overhead of a real game engine.

18K in Chrome DevilMark 96K in Chrome Pixi.js

[quote:3reda6i8]At that point they'd be competing with unity

They already are. Pretty sure C2 is high on list of popular game making engines. The issue isn't performance, you are right. It keeps getting tossed around as if that's what people are asking for. It's about being able to export without 3rd party reliance. Period.

I think that C3 must bring some real features that are not in C2 for people to buy it

Most people who bought C2 are hobbyists who don't make a lot of $ out of it, so every little expense counts

how about putting some 3d features in c3? i think many people would consider the upgrade