Regarding that C2 is a "product which is supposed to do what it says on the box" I must disagree a bit. Software is not a bike. You can say that about an easy accountant software which needs just one update a year to adjust new tax rules, but not about an engine which is made to make other software. Thinking this ways you should have the version of C2 which you downloaded as first, and use only wrappers and everything around with the version which was available the time you downloaded that first C2. Then it would be what was on the box (at that time).
Perhaps some more background to why I feel C2 doesn't live up to its promise would help.
As a Construct Classic user, I had been fine with the issues of the native engine crashing and editor bugs, because I had understood it was a project made open source by students in their spare time. It still produced amazing Windows games in both 2D and 2.5D that worked excellently (rarely crashing during runtime) on then-average (today low-end and ancient) DirectX 9 hardware, and even 3D ones if you knew the math.
When Construct 2 was in early development there was a great deal of excitement: Scirra was going to make a serious go of it/a professional game dev tool and an improvement to CC starting all over from scratch.
Around this time we were also told "desktop export would be a given", which many assumed to mean native export, and other ideas were being put out by Scirra (like having multiple exporter options rather than just the HTML5+Wrappers option. That's why the html5 engine is inside a folder called "exporters" eg: C:\Program Files\Construct 2\exporters\html5). Information about that is all here on the Scirra forums (possibly also on the old forums which should still be online right now) somewhere but you'll have to search to find the posts sadly as they've been buried over time.
Then over time Scirra dropped down to just pure HTML5, promising that the technology would catch up and work out better for all. They pushed out reports of near-native performance tests (when what they really meant is that the code is more optimized than CC, but if those same optimizations were applied to a native exporter it would obviously perform better in most situations), and many other reasons why this is the best choice for us, the developers of games using their tool.
It's 2016, 5 years after development started of C2, and I still find CC exported games to perform smoother on my Windows computers.
I switched to CC from Clickteam KnP/TGF/MMF, so the "graphical coding" was not novel, just better. The editor in Construct tools is also way better to me too, but again the complaint isn't about the editor but the actual games, the products I get from this tool.
In a way, C2 is exactly like "an easy accountant software", it's not an end product or a source of entertainment in itself, it's what I do with it that matters because it's a tool. I'm not even mad at the price because I agree it's relatively inexpensive (even considering that Unity and other big engines are now free for general use or low monthly fees for commercial titles), and Scirra should charge business customers more if they put native export into it.
I'm mad because I believed in Construct 2, worked together with a friend to make over 50% of a game, which was then funded on Kickstarter with the dreams of "Win, Mac, Linux + WiiU" that hence became an expectation from the backers (read: customers), and had to turn up with the same excuse Ashley gives us: "We're sorry, issues with a third party (C2 -> Node Webkit -> Chrome -> HTML5 + WebGL) prevented this from working on anything but high-end Windows desktops".
We were lucky enough to release to Steam, but there's still plenty of devices that should have no problems with the game suffering from frame skipping, missed collision detections, and etc. Especially in screencapture/let's play footage. And ultimately we can't port without totally re-writing the game.
Even a method to quickly export games into something easier imported into other engines would make Construct 2 100% more useful for developers who want to make more than lightweight or mobile games.
There's less layers (points of failure) in native export:
The driver issues Ashley mentioned were almost always AMD related, which is hilarious because WebGL still has issues on AMD devices too, and the solution changes from "wait for AMD to fix it" to "wait for NodeJS to update chrome, but if that doesn't fix it then wait for Chrome to make sure it's not their fault, then if it isn't hopefully Google will push AMD to fix it".
And why is WebGL worse on AMD? Because it's already bad at OpenGL anyway, which WebGL is pretty much based on:
https://www.gamingonlinux.com/articles/ ... hmark.3806
For these next two links Vendor A is NVIDIA, B is AMD, and C is Intel.
http://richg42.blogspot.ca/2014/05/the- ... ality.html
http://www.extremetech.com/gaming/18234 ... -of-opengl
Also a relevant link for how CC and C2 compared at the time when C2 started claiming to be "as fast as native": is-webgl-slow-on-some-machines_t75194