dont you think it would be prudent to remove the "export to xbox one" claim in Construct 3 advertising until plugins and everything else is in place and xbox UWP performance is validated and any limitations can be stated in a caveat against an export to xbox claim?

A lot of platforms would need to have some small fine print then

UWP doesn't have full access to the hardware, so native or not that's a big let-down. I think the Edge browser also has some issues with HTML5 games still.

Your experience sounds an awful lot like the exporting option to a certain Nintendo product in C2 ....

The games I wrote in Blitz Basic 3D (a DirectX 7 engine from 2001) are still working on my Windows 10 PC. Most of the Construct 2 games I made in 2014 don't work properly anymore in any of the current versions of web browsers

Technically, Construct 3 could probably be modified to include the free/open source "Superpowers" HTML5 collaborative editor (yes, it also is a 2D/3D game engine, but that module can be swapped out for the C3 engine).

That might actually be a great idea if it can be done!

Anyone who ever got their hands on the WiiU + dev kit had learned quickly that C2 games weren't going to run well on it (especially anything non-turn-based/action oriented)

If you think Construct 2 can't handle graphically intensive games, then as ever, rendering is bottlenecked on the GPU. So if you switch tool because of that, the hardware isn't going to be any faster, and the performance won't be any better.

I think some people switching tools have hardware-bottlenecked games and are eventually going to realise it was never C2's fault. I do see a lot of games bottlenecked on the GPU, and everyone knee-jerk blames C2, HTML5, Chrome, or anyone or anything else. I don't know why it's so hard for people to believe they've fully utilised the hardware? The engine is designed to let you do just that. I'm happy to be proven wrong, please send me your projects and all that, but it usually only confirms the point. I imagine some people will wander from tool to tool always thinking everyone's engine is awfully slow, never recognising that hardware is a limited resource.

Just to pre-empt how this discussion usually goes: now someone's going to shift the goalposts and talk about some random bug or some quirk that we fixed, or some other problem they had at some point, or start listing their personal laundry list of things they want changed. That has nothing to do with GPU performance. On this specific point, C2 is as good as a native engine, and I stand by that.

I wish I could spend the time to help find the source of slowdown, lag and jank in C2/C3 and all its Third Party wrappers, I really do, because I love what you and Tom have made on the editor side of things, both in layout and events.

However, I don't have that time. I can only tell you that I experienced much better performance and compatibility in Unity when remaking the same game we had prototyped in C2 (actually, with better special FX and a higher output resolution thanks to upscaling a deferred renderer/render texture), and that I also find both Unity and Construct Classic make "smoother" running games that don't feel janky (even if the native runs at maybe 30fps, it doesn't jerk like C2 can at 59fps).

I'd really like to recommend again that you use your own tool to make (and release/troubleshoot) a full sized platformer game (on at least Steam for Windows) and experience the issues that others like myself have reported here. I'd even subscribe/pay for a C3 subscription just to see some work on that happening/it release over the next 2-3 years.

And if you prove me wrong? Great! Share your knowledge with us on how to best make large games!

If I prove you wrong? That's still good, because now you know best how to debug and optimize C2/C3.

Plus one to what digitalsoapbox said.

Looking at the PROS only we saw:

Construct 2(/3) - Nice editor and events

Unity and custom coded C# - The game actually runs, plus consoles support, plus compatible with a lot more PC's

Seems a good comparison now then would be Unity particles and also optimizing the Construct 2, Godot, and Unity sprite benchmarks for retesting

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)

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"> )

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

Oh I fully understand and agree with you. We were left pretty high-and-dry when we were promised Mac OSX, Linux, and WiiU when we purchased our business licenses and then barely managed to make our Windows version of the game work (we had to downgrade our C2 and NodeWebkit just to export working exes and support Steam). It sucks even more when you have to answer to investors / clients / crowdfunding backers.

But I have learned two things talking here about it:

1. Nobody here saying "just give your source" seems to understand the legal NDA and copyright issues of doing that. It's not like we can ask Scirra to give us their C2 source when Construct crashes.

2. This stalemate between people who actually make games and encounter issues and people who think thats entirely the fault of the game creators seems to never end. Even when other engines actually demonstrate better performance.