I'm just pointing out that the less layers involved above DirectX/OpenGL, the better the performance and control over his own program that Ashley will have.
Yes, but at the cost of development speed. Also I think "control over his own program" is a bit of a dubious statement. By giving up on code provided by browser vendors to work around limitations, bugs and incompatibilities between different configurations/hardware setups, you're absorbing responsibility for overcoming those problems yourself, polluting your codebase with patches. The way I see it, you lose even more control over your own codebase, since you keep having to put dirty hacks to make it work with another set of "third parties".
Of course going down anywhere below C++ and a graphics API is entering into layers that I would never expect a lone developer to code for, but pretending that HTML5 works how it was supposed to at the export side of things has to stop.
Maybe if there was one console that could actually run REAL games (made in HTML5/WebGL from C2) well then we'd all be happy, but as long as everyone is using a million different devices and platforms, the ability to have my game work badly across all of them is no good compared to just one export platform running perfectly across the majority of my customer/userbase
That's the whole point. Everyone wants that. Your choices are:
- Haxe - broken spec, outdated/wrong docs, small community, not production-ready
- Java - they haven't delivered on their promise of "write once - run everywhere" yet, why should they start?
- Air/Silverlight/whatever - so, like, wrappers? Also, as you can see, they're all dead by now
- HTML5 - big performance leaps every year, growing capabilities, multi-billion dollar investments, humongous community, and we already have dedicated HTML5 devices
I can do enough in Construct 2 to make my games, the bug fixing and runtime performance is all I need to be happy. Editor-side C2 works way better than any engine as-is for 2D games. I see no reason to update the editor aside from making it easier for plugins like Quazi's Q3D to control more of the GUI.
The runtime already does nearly everything I want it to do, it's the editor that gets in the way. Developer time is much more valuable than machine time! When I making/use external tools to simplify development I feel like it's a huge waste of time, that I'm fighting the IDE more than being aided by it, especially considering there's no easy way to integrate tools to the IDE (without going through ashley, a la spriter) so you're forced to close the editor before using them (since they modify the XML directly). The interface is the biggest hindrance for gamemaking for the kinds of games I like to make.
Performance on the desktop, at least for me, is great. Mobile games have good performance as well, even on my comparatively ancient Galaxy Note 2, provided you keep in mind that mobile devices are basically toys
Pictured: a modern mobile device compared to a modern desktop computer
Most mobile games are a joke, the top selling games rarely have more than 50 sprites on-screen at a time, and yet you see people here wanting to create mobile games with 1000 sprites, all with physics enabled and two/three effects, and hand-painted full-hd rotating backgrounds. Native isn't going to get you there, and even if you were a programmer god and could create and engine entirely in handwritten ASM, I doubt it would do it either.
If only people would publish their games for others like me (or Ashley) to pick apart, we could point out the problem and optimize them. Heck, I might even sell that as a service.